SPF records and why you should use them

SPF records are one way for store owners to address the perennial problem that emails sent to their customers never reach their inbox and instead end up in their spam bins.

This is a pain for any number of reasons - the customer doesn't get confirmation that the order has been placed successfully, leading to the 'did my payment go through?' email, or the confirmation of dispatch and tracking number, leading inevitably to the 'where's my stuff?'' email, and an annoying amount of admin time in dealing with the emails. SPF records can help reduce the likelihood of this

What are SPF records?

SPF records are 'Sender Policy Framework' records - a posh name for what is, essentially, an list of who is allowed to send email on behalf of a particular domain (if your online store is at www.mystore.com, the domain is the 'mystore.com' bit). They're a standard administered by the Open SPF Project, and an example SPF record (for hummingbirduk.com) looks like this :

v=spf1 ip4:54.76.57.82 include:servers.mcsv.net include:_spf.google.com -all

What do SPF records contain?

The list is kept as a TXT record in the DNS for the domain - the DNS is the public record of various bits of information about the domain. At the very least, the DNS will hold a record (called, confusingly, an A record) which will say whereabouts on the internet your site can be found - on top of that there can be any number of other records of various different types, of which SPF records are just one. The record will start with a declaration that it is an SPF record :

v=spf1

The SPF record may be made up of a number of different elements - there's no limit - depending on who, precisely, is authorised to send emails on behalf of a domain. At the very least, it will need to have the IP address of the server that the domain is hosted on, so that outgoing emails from that server are authenticated. The IP address will in the IPv4 format (the traditional way) but if the server also has an IPv6 address, that should be included too, for the sake of future-proofing.

ip4:10.20.41.209 ip6:FE80:0000:0000:0000:0202:B3FF

If the server's IP address is the same as the A record, which it will be in most instances, then you can just include it as follows :

a

In the same way, if the MX records (the mail server) records for the domain are different to the A records, then they can be included easily enough by :

mx

What about email being sent from other servers?

A lot of site owners use Mailchimp or other providers for sending out newsletters, and since those come from different IP addresses, then they will need to be covered off. Rather than have to find out and include every single one of Mailchimp's IP addresses (and remember to update them when they change) there is an easy mechanism to include them by proxy - simply include the address where Mailchimp stores its SPF records, and they will be included in your domain's SPF records.

include:servers.mcsv.net

Likewise, if emails are being run through the same server, then that's as far as most SPF records will need to go. A lot of site owners, however, use Google Apps or some other provider for their email - that being the case, then they will also want the SPF record to show that emails that come from Google's IP addresses will also be valid. They can be included via the same mechanism, but with a slightly different syntax :

include:_spf.google.com

Finally one includes a note on the record to indicate how receiving email programmes should treat emails that come from an address which isn't in this list - so should they automatically consider the email to be spam? Or allow it anyway? In essence, this is an instruction on how to weight the email - saying to it that if the email is sent from an address that is in this list, then the chances are that it's not spam, so weight it accordingly, but if it's from another address, then it's not necessarily spam...we might just not have covered all possible senders.

-all (Fail - indicates that all mail from all other sources should be treated as spam)
+all (Pass - indicates that all mail from all other sources should be treated as not spam)

Once the records have been published, each incoming email will be checked against the record and weighted accordingly. In conjunction with DKIM records (on which we will have a separate post shortly) they're a powerful tool in keeping your emails out of your customers' spam bins and in their inboxes.

We'd be happy to help you set up your SPF records - just get in touch for more information. Incidentally (and although we don't like to brag), if you're one of our hosting clients, you really don't have to worry about all this - as part of the little extras we offer our hosting clients, we'll set up your SPF records for you, for free.