This site is now 100% read-only, and retired.

Avoiding mail-spoofing with SPF

Posted by Steve on Sat 1 Aug 2015 at 17:34

Tags: , ,

The Sender Policy Framework, or SPF, is an email-validation system which is designed to allow spoofed mails to be indentified. In this brief introduction we'll look at how you can configure your outgoing emails to take advantage of this validation.

Much like the DKIM system we recently documented the SPF system is mature, and widely supported, having been developed in the early 2000s.

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:




If the domain name has an address record (A or AAAA) that can be resolved to the sender's address, it will match.


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)..


If the sender is in the given IPv4 address range, match.


If the sender is in the given IPv6 address range, match.

In addition to these entries the domain-administrator may decide whether violations should be regarded as hard-failure "FAIL" or soft-failures "SOFTFAIL". This is specified via "-all", and "~all" respectively.


Example Records

If we pretend that mail from the host can only come from the IPv4 address we would create this record:

"v=spf1 ip4: -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, for the domain, looks like this:

"v=spf1 a mx p4: 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.

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"


Implementing SPF

We'll cover the checking of SPF-records, at SMTP-time, in the future, along with making it compulsory via DMARC.

But 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
"v=spf1 mx a ptr ip4: ip6:2001:41c8:10b:102::/64 ip6:2001:41c8:10b:103::/64 -all"


Drawbacks of SPF

The single biggest problem with SPF is that testing records at SMTP-time, which we'll document in the future, 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 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.

For the purposes of this article this failure case doesn't matter - people behind mail-forwarders should know they are, and they should exercise caution when testing SPF. From the point of view of the sender-domain this is perhaps a case there some casualties are expected though.

Further information on SPF may be found on wikipedia.



Re: Avoiding mail-spoofing with SPF
Posted by ajt (79.77.xx.xx) on Sun 2 Aug 2015 at 11:09
[ View Weblogs ]

Great article. My biggest problems in getting this to work were:

  • Finding out the all the possible forwarding IPs, which can sometimes be tedious if there are several
  • Formatting the line for the ByteMark DNS service, which requires a tweak relative to what you show here
  • DNS delay, which makes testing slow and tedious - and it's easy to shoot yourself in the foot!

As you say combined with DKIM, it's useful to have. I gather that some firms are more strict than others and can reject mail that is missing DKIM or if the SPF is not valid.

"It's Not Magic, It's Work"

[ Parent ]