Sender Policy Framework (SPF), is an email-validation system which is designed to allow spoofed mails to be identified.
In brief SPF allows you to specify, via a DNS-record, which hosts are allowed to send email on behalf of a particular domain.
Because SPF involves the use of DNS there is not anything to actually configure on your mail-server, when sending outgoing mail. Instead you must merely be able to identify all the hosts which might send email with a particular domain - these are the hosts which must be included in the DNS-record.
The SPF record is a simple text string, in a TXT, record which contains a v=spf1 prefix, and a number of additional components. For example:
| Component | Meaning |
|---|---|
| A | If the domain name has an address record (A or AAAA) that can be resolved to the sender's address, it will match. |
| MX | If the domain name has an MX record resolving to the sender's address, it will match (i.e. the mail comes from one of the domain's incoming mail servers). |
| IP4 | If the sender is in the given IPv4 address range, match. |
| IP6 | If the sender is in the given IPv6 address range, match. |
The domain-administrator may also decide whether violations should be regarded as hard-failure “FAIL” or soft-failures “SOFTFAIL”. This is usually specified via “-all”, and “~all” respectively.
| Rejection Type | Detail |
|---|---|
| -all | Reject or fail them - don't deliver the email if anything does not match. |
| ~all | Soft-fail them - accept them, but mark it as 'suspicious'. |
| +all | Pass regardless of match - accept anything from the domain. |
| ?all | Neutral - accept it, nothing can be said about the validity if there isn't an IP match. |
Most records will have a “~all” listed in the SPF record because the domain owner leaves room for the possibility of a new server getting created and might forget to update the SPF record with the new IP address of that server. This also allows for regular machines to send email without causing too much of an interruption.
Very large domains such as gmail.com have “?all” in their records to leave it up to the recipient to determine what to do with the email when received.
If we pretend that mail from the host example.com can only come from the IPv4 address 1.2.3.4 we would create this record:
v=spf1 ip4:1.2.3.4 -all
This record lists a single IP-address, but CIDR-formatted ranges are also supported. The -all suffix means that any mail coming from different IP addresses should be treated as bogus/spoofed/droppable.
A more complex record looks like this:
v=spf1 a mx p4:5.42.134.35/27 ip6:2001:41c8:10b:102::/64 ip6:2001:41c8:10b:103::/64 -all
That record shows that mail may come from a small IPv4 range, a pair of IPv6 ranges, and mail should also be accepted if it comes from the MX-host of the domain, along with the host having the IP address which matches the hostname (i.e. sharewiz.net).
Finally this record shows that mail can only be sent from hosts listed as the MX-machine(s) for the domain, but it is configured with a soft-fail, because the domain-owner isn't 100% sure that that is sufficient:
v=spf1 mx ~all
To publish a policy you must merely define a TXT-record, in DNS, for the domain you're sending from. To test that the policy is visible you can query that record, like so:
dig -t txt +short sharewiz.net
From a Windows machine use:
nslookup -type=txt sharewiz.net
Returns
Non-authoritative answer:
sharewiz.net text =
"v=spf1 a ip4:5.42.134.35 -all"
Result
v=spf1 mx a ptr ip4:5.42.134.35/27 ip6:2001:41c8:10b:102::/64 ip6:2001:41c8:10b:103::/64 -all
An SPF record may also include a “redirect” in the record, such as gmail's:
v=spf1 redirect=_spf.google.com
This tells the receiving server to check the SPF record of google.com instead of gmail.com. An “include” in the record tells the receiving server to also consider the IP addresses listed in the SPF record of another domain to make a match for which servers can send email. This is commonly set up with multi-domain organizations. Those SPF records will be listed as such:
v=spf1 ip4:123.123.123.0/19 include:example.com include:other.com -all
The single biggest problem with SPF is that testing records at SMTP-time can fail if your mail is handled via a forward.
There are several online sites which allow mail to be received at a vanity-domain, then redirected to the real location, such as iki.fi. If these vanity-forwarders do not rewrite the sender-addresses, when forwarding the mail, then testing any SPF-policy present will fail, since the forwarding host will not be included as a valid-source of email for the sender's domain.