On this page
Understanding SPF records
An SPF record tells receiving mail servers which servers are allowed to send email on behalf of your domain.
An SPF (Sender Policy Framework) record is a single line of text in your domain's DNS that lists which mail servers are allowed to send email using your domain name. When a receiving mail server gets a message claiming to be from you, it checks your SPF record to decide whether the sending server is authorised. If it is not, the message may be rejected or treated as spam.
This guide explains what the parts of an SPF record mean, so you can understand and safely adjust your own. For the step-by-step of editing DNS, see our guide to the Zone Editor in cPanel.
The one-record rule
A domain must have exactly one SPF record. This is the single most common mistake people make: adding a second SPF record - for example when setting up a new newsletter service - rather than extending the existing one. Two SPF records is an error that can cause all your mail to fail authentication. Always add new senders to the record you already have.
Anatomy of a record
A typical SPF record on our hosting looks like this:
v=spf1 +a +mx +ip4:203.0.113.10 +include:spf.filteredmx.net ~all
203.0.113.10 is a dummy stand-in for your own server's IP address which should have been set automatically.
Reading it left to right:
v=spf1- declares this as an SPF version 1 record. Every SPF record starts this way.+a- authorises the server that your domain's own A record points to.+mx- authorises the servers listed in your domain's MX (mail exchanger) records.+ip4:203.0.113.10- authorises a specific IPv4 address, in this case your hosting server.+include:spf.filteredmx.net- authorises all the servers covered by another domain's SPF record. This is how one service vouches for another; here it brings in our outbound filtering gateway, which your mail is routed through.~all- the catch-all at the end, covering any server not matched by the entries before it. The qualifier in front of it (~here) decides how those non-matching messages are treated.
The + in front of a, mx, ip4 and include means "pass" - these sources are allowed. A + is the default, so you will often see these written without it (a, mx, and so on); the two forms mean the same thing.
Adding another sender
To authorise an additional service - a newsletter platform, CRM, or any other system that sends mail as your domain - add its include value (found in that service's own documentation) to the record, before the all at the end:
v=spf1 +a +mx +ip4:203.0.113.10 +include:spf.filteredmx.net include:newsletter.example.com ~all
You can chain as many includes as you need, but be aware SPF has a limit of ten DNS lookups per record. Each include, a and mx counts towards that limit, so a domain sending through many services can hit it, at which point SPF stops evaluating and can fail. If you reach that point, contact us and we can help consolidate the record.
The qualifier on all: ~all versus -all
The final all term covers any server not listed earlier in the record. The character in front of it controls how strict that treatment is:
| Qualifier | Name | Effect |
|---|---|---|
~all |
Softfail | Mail from an unlisted server is allowed through but marked as suspicious. |
-all |
Hardfail | Mail from an unlisted server should be rejected outright. |
?all |
Neutral | Makes no statement either way; offers almost no protection. |
We use ~all by default, and it is the safest choice for most people. If you forget to add a sender, its mail is likely to still arrive (often in the spam folder) rather than being rejected outright.
-all is stricter and offers stronger protection against forgery, but it is unforgiving: if your record is missing even one legitimate sender, that sender's mail will be rejected entirely. It is tempting to assume -all is simply "better" because it is stricter, but it should only be used once you are completely confident your record lists every service that sends mail as your domain. A -all record with a forgotten sender is a common cause of "some of our email just stopped being delivered". If you are not sure, ~all is the right choice.
Do not remove the entries that authorise your own hosting - the +ip4 and +include:spf.filteredmx.net parts in our default record. These are what allow your normal outbound mail to pass authentication. Removing them will cause your own email to fail.
When changes take effect
SPF records, like all DNS, are cached according to their TTL (time to live). Our records use a four-hour TTL, so after editing your record allow up to a few hours before testing, as receiving servers may still be using the previous version until the cache expires.
If you would like us to review your SPF record or help add a third-party sender safely, open a support ticket and we will be glad to help.