Antispam: Understanding SPF records

Email is an extremely powerful and valuable tool for netizen, but only when used in the right way. As such we fully support measures that aim to defend users from unwanted emails.

One way to do this is by participating in the Sender Policy Framework (SPF), which is an open standard method of allowing the senders of emails to verify that they are who they say they are. This is important as most abuse of emails (spam) is generated by people using false addresses.

The SPF record is managed at DNS level. This post is a quick overview of SPF syntax.

What’s SPF record?

It is simply a TXT record within the DNS server for the domain from which the email is sent. It represents a way to tell the receiving email server which servers are allowed to send email for that domain.

For example, if we are sending email from mail-sender@example.com and our mail server is mail.example.com, then we need to tell the receiving email server that the server mail.example.com is allowed to send email for the example.com.

SPF record syntax

All the SPF records start with an identification that the TXT record is an SPF, this means that they need to start with “v=spf1 …

Now that we have identified the record as an SPF, we must define what servers are allowed to send email. This is done with a series of directives:

a – Means that our example.com domain allows the own example.com host to send email for it, let’s see how it would be like in the record:

v=spf1 a ...

mx – Represents that the hosts identified by our example.com MX records are also allowed. At the record looks like this:

v=spf1 mx ...

or you can use “v=spf1 a mx …” to continue with the prior mechanism.

ptr – Allows any example.com’s sub domains to send email for example.com. It’s not recommended because it is not a safe rule, but in some cases is needed, so it could be like:

v=spf1 a mx ptr ...

a: mx: ptr: – These mechanisms are similar with the already described, but the ‘:’ means that we will pass a host name as an argument to it. Means that, instead of searching the DNS records at the current domain, the receiving email server will get the server records from the passed host name. An example would be:

v=spf1 a:mail3.other.com ...

meaning that the server with the host name mail3.other.com is allowed.

To allow the MX records of another server, we need the following:

v=spf1 mx:other.com ...

and if the MX record of the domain other.com defines mailnow.other.com as it’s receiving mail server, this same server will be allowed to send email for our example.com domain.

With the “ptr:” is the same. Imagine that we wanted to allow any host ending with “our-isp.com” to send email for example.com, the SPF record would be like:

v=spf1 ptr:our-isp.com ...

ip4: ip6: – If we need to specify IP addresses instead of domains, we would use these directives for IPv4 or IPv6 addresses. An example here:

v=spf1 ip4:10.0.0.1/24 ...

include: – This is a useful mechanism that allow us to include other domain SPF record as ours. With it we can configure that our mail will handle the same way as our ISP defines in its own SPF:

v=spf1 include:our-isp.com …

all – This rule represents what to do with all other domains not specified. Usually you want to define that all other domains are not allowed to send email for your domain, this is done with:

v=spf1 ... ~all

Identical result would be obtained with “v=spf1 … -all“. If you want to ignore the other domains and let the receiving email server decide for you, the record could be like:

"v=spf1 ... ?all"

Otherwise, if you don’t like this SPF thing and want to allow any server to send your email, here is a example:

"v=spf1 +all"

This should not be used as you easily understand. With this record you are telling spammers to use to send spam mails in your domain name.

redirect – This SPF directive is to replace the current set of directives with other domain’s SPF records. The expanded domain is also substituted for the current one in those lookups. For example, gmail.com’s current SPF record is:

"v=spf1 redirect=_spf.google.com"

It would use SPF records from _spf.google.com instead, it actually follows these rules:

[joseph@admon ~]$ dig -t txt _spf.google.com

;; QUESTION SECTION:
;_spf.google.com.               IN      TXT

;; ANSWER SECTION:
_spf.google.com.        255     IN      TXT     "v=spf1 ip4:216.239.32.0/19 ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:209.85.128.0/17 ip4:66.102.0.0/20 ip4:74.125.0.0/16 ip4:64.18.0.0/20 ip4:207.126.144.0/20 ip4:173.194.0.0/16 ?all"
...

Looking for for more information?

The Sender Policy Framework official website is http://www.openspf.org/, and it can help construct your SPF and do some tests with it.

For more detailed information on SPF mechanisms, please refer to this link:  http://www.openspf.org/Mechanisms

2 thoughts on “Antispam: Understanding SPF records

  1. I admire the valuable information you offer in your articles. Just thought you’d be interested to know that I have added you to my bookmarks You make 100% right points in a concise and pertinent fashion, This is a really good read for me, many thanks

Leave a comment

Your email address will not be published. Required fields are marked *