What Is SPF – And Why It Is Essential If Your Server Handles Email

One of the biggest issues with email has always been how vulnerable it is to spoofing, with the mail client and server trusting the input given by the user for identification of the sender. Spammers often abused this to send email giving the impression that it came from a reputable source. A solution was needed to ensure that email was only accepted from the rightful sender to reduce the amount of spam sent and to make it harder for a spammer to make the email appear to be coming from a reputable domain.

SPF Solution

This is where SPF, or Sender Policy Framework, comes in. This is a method by which the owner of a domain can use a special DNS record to specify which servers should be sending email on behalf of the domain. Servers receiving email will check for SPF records for the domain that the email purports to come from; if the sending server doesn’t match any record then the email will be discarded, and if there is a match it will be delivered. If the domain lacks an SPF record, some servers may deliver the email, some may flag it as spam, and others may discard it depending on their configuration.
So now we’ve established how SPF works, let’s look at how we can create an SPF record for a particular domain. An SPF record is a specially formatted TXT record that specifies the details of any servers that can and can’t send mail for the domain. Here’s an easy example using the SPF record for example.com:
example.com.        60    IN    TXT    “v=spf1 -all”
To show that the DNS TXT record is for SPF, the record starts with “v=spf1”. This is then followed by the rules of where it can and can’t send email separated by spaces. In this instance, there is only one rule which is “-all”, which tells a mail server reading the record that nowhere should be sending mail for that domain.

Understanding SPF Rules

As with everything else, the rules need to be formatted in a specific way to be understood.
Here’s a list of the options:
   all    Matches any domain.
   a      Matches any domain whose DNS A or AAAA records match the sending IP.
   MX     Matches any domain whose DNS MX records match the sending IP.
   PTR    Matches if the domain in the IPs PTR record matches the sender’s domain.
   EXISTS Matches if the domain name resolves to any address.
   INCLUDE References another domains SPF record and matches any domains that match settings for that record.
   IP4    Match a specific IPv4 address or range of addresses specified in CIDR notation, eg IP4:xxx.xxx.xxx.xxx/xx.
   IP6    Match a specific IPv6 address or range similarly to the above.
There are also modifiers that dictate how these matches should be handled:
   +   Mail received that matches this rule should pass; this is the default action and as such the + is optional.
   –   Mail received that matches this rule should be rejected.
   ~   Mail received that matches this rule should pass but be flagged.
   ?   Mail received that matches this rule should have no policy set (would be handled the same as a domain without SPF).
In real-world use, the only modifier you will likely use would be the – one.
Now let’s look at a simple example SPF record that will work as a base for most domains:
   v=spf1 a mx -all
In this case, the rule allows for acceptance of email from servers where the A or AAAA records for the domain match the sending server’s IP, or where the server sending the mail is in the domain’s MX records. In all other cases the email should be rejected. If you have servers that also send email, such as status and monitoring email that you find are rejected, you can also specify their IPs individually in your SPF record to ensure they come through to you. For example:
   v=spf1 a mx ip:192.168.1.23 -all
That’s pretty much all there is to it – quite simple for something that initially can look quite confusing. From here you should be able to put together what you need for an SPF record for your domain and hopefully avoid any future email bounced as spam.