An SPF (Sender Policy Framework) record is a TXT record that tells receiving mail servers which IP addresses are allowed to sent mail for your domain.

If you bought a hosting package from us and use our name servers then you already have an SPF record, as they are automatically created when an account is set up. However, there might be a good reason why you want to change the existing SPF record.

Why does your domain need an SPF record?

SPF records are useful for two reasons:

  • The records helps prevent email spoofing and phishing
  • It makes it more likely that your email isn’t marked as spam by receiving servers

What is email spoofing and phishing?

Email spoofing is a way to send emails from a forged email address. It is surprisingly easy to spoof an email’s “From:” address, and it is commonly used for phishing emails. Often these emails are made to look like they were sent from a bank or a company like Paypal.

The emails typically urge you to click on a link to sort out a problem with your account. The link will of course go to a fake website which collects the user names and passwords of people who fall victim to the scam.


The term phishing is a play on the word fishing. The criminals are using a bait (such as an urgent email from what appears to be your bank) to catch a victim.


Receiving mail servers know from which IP address an incoming email was sent. Because SPF records define which IP addresses are allowed to sent emails for your domain the receiving server can check if the email is authorised. If the sending IP address hasn’t been whitelisted the server may mark the email as spam.

Similarly, when a receiving server sees that the sending IP address is allowed to sent mail for your domain then the email is unlikely to be marked as spam. In other words, SPF records help prevent spam and make sure 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 value of 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 sending IP address isn’t whitelisted (“~all”).

SOFTFAIL vs HARDFAIL

As said, the “~all” part at the end of the SPF records instructs receiving 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” we could also have used “-all”. The dash (-) asks mail servers to reject emails if the sending IP address isn’t whitelisted. This is the HARDFAIL mechanism.

By default we use the SOFTFAIL mechanism. This still helps with the delivery of genuine emails but it prevents many 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)

Our SPF record whitelists the IP address of our domain’s mail server. Most SPF records also allow the website’s IP address to sent emails. In our case that isn’t really necessary, as the MX and A record point to the same IP address. However, it is still common to add the A record:

example.net.                 TXT       v=spf1 mx a ~all

If 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.

example.net.                 TXT       v=spf1 mx a:mail.example.com ~all

Using a:mail.<your-domain> is commonly used when the MX record points to mail.<your-domain>. It is usually not necessary to explicitly allow the ‘mail’ subdomain. In the above example we have already allowed the MX record for example.com, and if the MX record is mail.example.com then we don’t have to allow the subdomain’s A record. In effect we have allowed the same IP address twice! This won’t cause an error, but it makes the record more complicated than it needs to be.

Allowing mail from another mail server (MX record)

If you are using 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 if your MX records are pointing to G Suite:

example.net.                 TXT       v=spf1 mx a a:otherdomain.com include:_spf.google.com ~all

If you also use MailChimp (to send newsletters) you could add a second “include” mechanism to also whitelist mail from MailChimp sent on behalf of your domain:

example.net.                 TXT       v=spf1 mx a a:otherdomain.com 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 whitelists all our servers, 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 another domain.

Useful online tools

  • If you need to create an SPF record from scratch, there is an online SPF Wizard that will guide you through the various 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 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.