An SPF (Sender Policy Framework) record specifies which IP addresses are allowed to sent mail for your domain. This article looks at how SPF records work and why they are important. I will also gives examples of common SPF records.
SPF records are useful for two reasons:
Email spoofing is a way to send emails from a forged email address. The technique is commonly used for phishing emails. This are scam emails that look like they were sent from a legitimate company, such as a bank. They typically urge you to click on a link to sort out a problem with your account. The link takes you to a fake website which collects the victim’s account details.
The term phishing is a play on the word fishing. The criminals use a bait (such as an urgent email from what appears to be your bank) to catch a victim.
As said, an SPF record lists IP addresses that are allowed to sent mail for a domain. Mail servers can see the sender’s IP address, and they can therefore use the SPF record to check if the sender’s IP address is on the allow list. If the IP address isn’t allowed then the server may mark the email as spam.
Similarly, if the IP address is allowed then the email is unlikely to be marked as spam. In other words, SPF records not only help prevent email spoofing, they also make it more likely that genuine emails are delivered correctly.
Let’s start with a basic SPF record and then gradually add more IP addresses to it. The most basic SPF record looks like this:
example.net. TXT v=spf1 mx ~all
The record tells receiving mail servers three things:
The “~all” part at the end of the SPF records instructs mail servers to notice any SPF failures but to not reject the email if there is an IP address mismatch. This is known as the SOFTFAIL mechanism.
Instead of “~all” you can use “-all”. The dash (-) asks mail servers to reject emails if the sending IP address isn’t allowed. This is the HARDFAIL mechanism.
We recommend using the SOFTFAIL mechanism. This still helps with the delivery of genuine emails but it prevents many accidental delivery errors. One particular problem with SPF is that it doesn’t work well with email forwarding. If you forward an email to, say, a Gmail account then the SPF check is likely to fail.
Most SPF records also include the domain’s A record. This is useful if your website relays emails (such as form submissions):
example.net. TXT v=spf1 mx a ~all
Receiving mail servers will now look up the IP address for both the MX and A record. It is also possible to allow another website to send mail for your domain. In that case you need to specify the other domain name after the “a:” mechanism. For instance, the below record allows the MX record for example.net and the A record for example.com:
example.net. TXT v=spf1 mx a:example.com ~all
If you use an external service for your email, such as G Suite or Exchange, then you can use the “include” mechanism. For instance, you can use the following SPF record if you use G Suite:
example.net. TXT v=spf1 mx a include:_spf.google.com ~all
You can use multiple include mechanism. For instance, if you also use MailChimp (to send newsletters) then you can add include them as well:
example.net. TXT v=spf1 mx a include:_spf.google.com include:servers.mcsv.net ~all
When a hosting package is created we add a so-called global SPF record. The value of the record is
v=spf1 mx a include:spf.active-ns.com.
The included domain (spf.active-ns.com) effectively allows all our IP addresses, including our Exchange servers. If you are hosting your email with us then the global SPF record only needs to be changed if you need to include an external domain.
SPF is one of two anti-spam/spoofing records that is enabled by default on our servers. The second DNS record that is used for this purpose is DKIM, which we will look at next.
Both SPF and DKIM records are used by DMARC to give receiving mail servers explicit instructions on what to do with an email that doesn’t pass SPF and/or DKIM checks.