5 common mistakes with SPF

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.

Mistake 1: Multiple SPF records

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 v=spf1.

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.

Mistake 2: Double quoted TXT record

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.

Mistake 3: Permissive all mechanism

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 ~all or -all.

You usually start with ~all if you have just set up 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.

Mistake 4: The use of the ptr mechanism

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

So, when the original SPF standard RFC4408 was revised in RFC7208, the section on the ptr mechanism (section 5.5) was changed to discourage its use.

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 a mechanism.

Mistake 5: Use of the SPF record type

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.

Bonus mistake: Exceeding the DNS lookup limit

While technically it is not a mistake, but certainly an issue that can negatively impact email deliverability is an SPF policy that requires more than 10 DNS lookups to evaluate.

The SPF standard limits the number of allowed DNS lookups for a full evaluation to 10. If a receiver needs to perform more than additional DNS queries (on top of fetching the SPF policy), it will fail the SPF inspection with a permerror state. This can prevent the email from being delivered to the recipient inbox, and it can harm the domain reputation.

We have published an article dedicated to this issue here: SPF lookup limit explained.

To check the number of DNS lookups your policy requires you can use our free SPF validator tool.


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.

Further reading

See also

With Mailhardener you can configure, validate and monitor your domain for all aspects of email security. Mailhardener is free to use for a single domain.
Sign up now