6 March 2017

A Sender Policy Framework (SPF) primer

The SPF is one of the many solutions nowadays used for avoiding unsolicited bulk email (also known as ‘spam’, although this actually means excessively multiposted Netnews articles). SPF works by determining whether the purported sender address matches the IP address from which mail is arriving. This is possible because domain owners publish SPF records that list the systems from which users may send mail. As junk mail usually carry falsified sender addresses, SPF can be effective in distinguishing legitimate messages from junk mail.

SPF records

You can find out the SPF record for your domain name by doing a DNS lookup, e.g. using the dig, host or nslookup tools. (nslookup is deprecated, and may be removed from future releases of whatever software you use. Consider using dig or host instead.) Here are fictitional example queries and responses for an example domain (some output lines have been wrapped for legibility):

dig

$ dig example.com txt

; <<>> DiG 9.3.3rc2 <<>> example.com txt
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38859
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;example.com.                      IN      TXT

;; ANSWER SECTION:
example.com.               1800    IN      TXT     "v=spf1 ip4:193.229.0.32/27 ip4:193.229.5.0/24 ptr ptr:elisa.fi
 ptr:elisa-laajakaista.fi ptr:elisa-mobile.fi ptr:kolumbus.fi include:elisa.fi include:kolumbus.fi ~all"

;; AUTHORITY SECTION:
example.com.               1800    IN      NS      ns.nebula.fi.
example.com.               1800    IN      NS      ns2.nebula.fi.

;; ADDITIONAL SECTION:
ns.nebula.fi.           11      IN      A       217.30.180.225
ns2.nebula.fi.          33      IN      A       217.30.182.225

;; Query time: 6 msec
;; SERVER: 217.30.180.230#53(217.30.180.230)
;; WHEN: Sun Dec 23 00:47:11 2007
;; MSG SIZE  rcvd: 280

host

$ host -t txt example.com
example.com descriptive text "v=spf1 ip4:193.229.0.32/27 ip4:193.229.5.0/24 ptr ptr:elisa.fi
 ptr:elisa-laajakaista.fi ptr:elisa-mobile.fi ptr:kolumbus.fi include:elisa.fi include:kolumbus.fi ~all"

nslookup

$ nslookup -q=txt example.com
Server:         217.30.180.230
Address:        217.30.180.230#53

Non-authoritative answer:
example.com        text = "v=spf1 ip4:193.229.0.32/27 ip4:193.229.5.0/24 ptr ptr:elisa.fi ptr:elisa-laajakaista.fi
 ptr:elisa-mobile.fi ptr:kolumbus.fi include:elisa.fi include:kolumbus.fi ~all"

Authoritative answers can be found from:
example.com        nameserver = ns2.nebula.fi.
example.com        nameserver = ns.nebula.fi.
ns.nebula.fi    internet address = 217.30.180.225
ns2.nebula.fi   internet address = 217.30.182.225
The record v=spf1 ip4:193.229.0.32/27 ip4:193.229.5.0/24 ptr ptr:elisa.fi ptr:elisa-laajakaista.fi ptr:elisa-mobile.fi ptr:kolumbus.fi include:elisa.fi include:kolumbus.fi ~all should be read as follows: ‘Mail with an example.com sender address may be received, without cause for concern…
  • from the IP address ranges 193.229.0.32–193.229.0.64 and 193.229.5.0–193.229.5.255
  • from any IP address that resolves into an example.com, elisa.fi, elisa-laajakaista.fi, elisa-mobile.fi or kolumbus.fi domain
  • from all the same IP addresses allowed in the SPF records for elisa.fi and kolumbus.fi.
Additionally, mail might be received from any other IP address; this is suspicious, but not necessarily malicious.’ Overwhelmed? Never mind – your domain name administrator should have taken care of this nitty-gritty. If, however, there is no SPF record for the domain name of your email address, I suggest that you ask your provider to publish such records, so that recipients may determine that your mail is legitimate.

Forwarded mail, a potential problem

One important issue regarding SPF is that of mail forwarding. Assume that you possess a second email address, from which you have all incoming mail automatically forwarded to your main address (so that you need to read only one mailbox). If I send mail to your secondary address, the message will pass the first SPF check with flying colors, because it comes from one of the IP addresses listed in the example.com SPF record. However, when the forwarded message arrives at the server for your main address, the check will likely fail, since the IP address of the server for your secondary address probably is not listed in that same example.com record. As noted above, ~all means a ‘soft fail’ for those IP addresses not explicitly listed, including your secondary mail server in the above example. This means that my example message might not have be flagged as junk after all. Would the record instead read -all, the message would have failed the SPF check. This is why SPF doesn’t work well with automatic forwarding. Apart from using the soft fail method mentioned above, another way to accommodate SPF in the case of forwarded messages is to rewrite the sender address when forwarding the message. If this is done, the SPF check at the message’s final destination will be done against the domain name of the forwarding party (i.e. your secondary mail address), not the one of the original sender. From the final server’s point of view, the message is sent from the forwarder’s email address, and should therefore pass SPF validation.

What does the future hold for SPF?

Although junk mailers have an enormous number of Internet-connected computers at their disposal, they still want to use those resources as efficiently as possible, in other word pump out as many messages per second as they can. As long as relatively few domains use SPF, junk mail senders can afford to disregard it – although they lose a small amount of mail, it is still worthwhile to “blindly” blast away mail using arbitrary sender addresses. However, should SPF one day be adopted by a large majority of providers, junk mail senders would themselves need to perform SPF lookups in order to find legitimate sender addresses. SPF would then no longer work as a junk mail filter, only as a means to slow down junk mailers.