SPF records

Last updated: 5 April 2021

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.

Why does your domain need an SPF record?

SPF records are useful for two reasons:

• The record helps prevent email spoofing and phishing.
• It makes it less likely that emails you sent are marked as spam.

What is email spoofing and phishing?

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.

How SPF checks work

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.

The anatomy of an SPF record

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 version of SPF we are using (“spf1”).
• That the IP address of the MX record for example.net is allowed to send emails on behalf of example.net.
• That we don’t want the server to reject emails if the sender’s IP address isn’t whitelisted (“~all”).

SOFTFAIL vs HARDFAIL

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.

Allowing mail from a website (A record)

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

Allowing mail from another mail server (MX record)

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

Catalyst2 global SPF record

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.

Useful online tools

• If you need to create an SPF record from scratch, there is an online SPF Wizard that guides you through the various SPF options one step at a time.
• Vamsoft has a useful online SPF syntax validator. Before you change your domain’s SPF record, it is always a good idea to check if the validator reports any syntax errors.
• Of course, we are also happy to answer your DNS queries! Please submit a ticket if you need any help.

SPF in relation to DKIM and DMARC

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.