Today, nearly all abusive e-mail messages carry fake sender addresses. The victims whose addresses are being abused often suffer from the consequences, because their reputation gets diminished and they have to disclaim liability for the abuse, or waste their time sorting out misdirected bounce messages.
You probably have experienced one kind of abuse or another of your e-mail address yourself in the past, e.g. when you received an error message saying that a message allegedly sent by you could not be delivered to the recipient, although you never sent a message to that address.
Sender address forgery is a threat to users and companies alike, and it even undermines the e-mail medium as a whole because it erodes people's confidence in its reliability. That is why your bank never sends you information about your account by e-mail and keeps making a point of that fact.
The Sender Policy Framework (SPF) is an open standard specifying a technical method to prevent sender address forgery. More precisely, the current version of SPF — called SPFv1 or SPF Classic — protects the envelope sender address, which is used for the delivery of messages.
Even more precisely, SPFv1 allows the owner of a domain to specify their mail sending policy, e.g. which mail servers they use to send mail from their domain. The technology requires two sides to play together: (1) the domain owner publishes this information in an SPF record in the domain's DNS zone, and when someone else's mail server receives a message claiming to come from that domain, then (2) the receiving server can check whether the message complies with the domain's stated policy. If, e.g., the message comes from an unknown server, it can be considered a fake.
Once you are confident about the authenticity of the sender address, you can finally "take it for real" and attach reputation to it. While IP-address-based reputation systems like Spamhaus or SpamCop have prevailed so far, reputation will increasingly be based on domains and even individual e-mail addresses in the future, too.
Let's look at an example to give you an idea of how SPF works. Bob owns the domain example.net. He decides to publish an SPF record in order to reduce the abuse of his domain in e-mail envelopes:
example.net. TXT "v=spf1 mx a:pluto.example.net include:aspmx.googlemail.com -all"
| v=spf1 | SPF version 1 |
| mx | The incoming mail servers (MXes) of the domain are authorized to also send mail for example.net |
| a:pluto.example.net | The machine pluto.example.net is authorized |
| include:aspmx.googlemail.com | Everything considered legitimate by googlemail.com is legitimate for example.net |
| -all | All other machines are not authorized |
This example demonstrates but a small part of SPF's expressiveness. Do not take it as a guideline for building your own record. Instead, learn more about the record syntax.