At Mailhardener, we analyse many domains for email security on a daily basis. This puts us in a unique position to list the most commonly made mistakes.
Here are the 5 most common mistakes with SPF.
Update: we now have an SPF validator tool available that tests every aspect of your SPF record, including the 5 mistakes described in this article.
A (sub)domain can have no more than one SPF record.
A DNS query of type
TXT should result in 1
TXT record that starts with
If you have more than one SPF record, there is no guarantee which one will be used by the email system. As a result: it may happen that sometimes your mail is not delivered. This situation can be really tricky to track down.
If you need to add services to your SPF, you should add those to your existing SPF record, instead of adding an extra record.
You can test this yourself with the
dig tool (available on MacOS, Linux or Windows Subsystem for Linux (WSL))
dig example.com TXT +short
If you see more than one result that starts with
v=spf1 you should fix that.
You can use our SPF merge guide to learn how.
The content of a DNS
TXT type record is always displayed with double quotes, but those quotes are not part of the record content.
They are there for display purposes only, so you can distinguish the content start and end, since a
TXT type record is allowed to contain whitespace characters.
Therefore, it is common for email services which instruct you how to set up your SPF to show those quotes in the example. You should not include those quotes in the record.
The SPF standard states that the SPF record must begin with
v=spf1, so if your record starts with
"v=spf1 (note the quote) it will not be recognized.
Unfortunately, some DNS providers require you to add the quotes when pasting, and some don't. This leads to confusion, the most common advice we give: try to paste without the quotes and if that is not accepted, add the quotes.
You should always check your results with the
dig tool once you have set the SPF record (note that due to DNS propagation delays, it may take some time before your changes become visible).:
dig example.com TXT > example.com. 21599 IN TXT "v=spf1 mx -all" <-- correct > example.com. 21599 IN TXT "\"v=spf1 mx -all\"" <-- wrong!
In the example above, the first result is correct, and the second result is wrong.
An SPF record is constructed with one or more mechanisms to identify which senders are allowed to use your domain to send email. If you want to learn exactly how an SPF record is constructed, we recommend reading our SPF article in our knowledge base, or consult RFC7208.
An SPF record is interpreted from left to right, the
all mechanism will match all senders that did not match the preceding mechanisms.
Therefore, you should place the
all mechanism at the end of the SPF record, and use it with the
~ (softfail) or
- (fail) prefix.
Do note that if no prefix is set, the
+ (pass) is used by default.
It is easy to make mistakes in the SPF record, which will cause unintended permissions. Here are some examples:
v=spf1 mx +all <-- this allows everyone to send email with your domain v=spf1 mx ?all <-- this is a neutral prefix, which does the same as +all v=spf1 mx all <-- no prefix, so +all is used v=spf1 mx <-- no all mechanism, +all is assumed
In all 4 examples above, the result is that every sender on the planet is allowed to send email for your domain. This mistake basically disables SPF.
Your SPF record should always end with
You usually start with
~all if you have just setup SPF for the first time.
You can then use a monitoring service like Mailhardener to check if you didn't accidentally leave some legitimate sender out.
Once you are sure you have all authorized senders in your SPF policy, you should switch to
-all to start enforcing your policy.
ptr mechanism owes its name to the
PTR DNS record type, which is used for reverse DNS.
With a reverse DNS lookup you query an IP rather than a domain, and you'll get the domain(s) that this IP belongs to.
In practice, it turns out that reverse DNS has reliability issues and results in a higher burden on the reverse DNS servers and email systems that use it.
5.5. "ptr" (do not use) This mechanism tests whether the DNS reverse-mapping for <ip> exists and correctly points to a domain name within a particular domain. This mechanism SHOULD NOT be published.
In most cases, the
ptr mechanism can be replaced with the
When SPF was first standardized in RFC4408, a new DNS record type named
SPF was also specified.
To accommodate rapid adoption of SPF, RFC4408 also allowed the use of the common
TXT type record in case the
SPF type record wasn't supported by the involved systems.
The official recommendation (back then) was to publish both types.
But this dual record solution caused more issues than it was intended to solve, most notably situations where an administrator would accidentally update one type but not the other.
Adoption of the
SPF type record didn't pick up as hoped.
So, when the SPF standard was refreshed in RFC7208, it was decided that the use of the
SPF record type would be dropped in future versions.
To quote RFC7208 section 3.1:
Many alternatives were considered to resolve this issue, but ultimately the working group concluded that significant migration to the SPF RR type in the foreseeable future was very unlikely and that the best solution for resolving this interoperability issue was to drop support for the SPF RR type from SPF version 1.*
So, although the
SPF type DNS record is not deprecated just yet, you shouldn't rely on it.
And since it is always required to publish SPF as a
TXT type anyway, we recommend only using the
TXT type record to prevent accidental mismatches between the two.
As you can see, there are quite a few subtle configuration mistakes that can be made with SPF. We hope this article helps you to catch those mistakes in time.
When changing your SPF settings, always monitor your email carefully to catch problems before your customers do.