Email Deliverability


Common mistakes when setting up & publishing an SPF record

Tackling pitfalls of one of the basic email authentication methods

Nick van Dijk

Business Developer



When you're sending out emails from a domain (, an SPF record is a crucial part of making sure no one outside your organization can send emails on your behalf. But setting up a valid SPF record can be harder than it looks. We've listed the most common mistakes when working with the Sender Policy Framework.

Published in:

May 2022


A lot of questions we get about the Sender Policy Framework involve the setup of the record itself. Existing SPF records return a fail, cannot be read by SPF record checks, or people don't see their changes after they saved them.


You can only have one SPF record per domain

The SPF RFC is very clear about this: the receiving mail server should only look at one SPF record - and thus disregard a potential second one. Every change or addition that you want to make should happen inside of this one record.

Start with v=spf1, end with [x]all

The receiving mail server will recognize the SPF record by the opening tag 'v=spf1' and it will stop analyzing the SPF record after the all-mechanism. The record checker will read the SPF record from left-to-right, but mechanisms inbetween the v=spf1 and all can be in random order. Read more about mechanisms here.

Don't forget your Time-To-Live (TTL)

The moment you have made changes to your DNS, it depends on your provider how fast your record is actually active. Usually, this happens within a few minutes. In addition, you have to deal with TTL (Time to Live) in your DNS, defining the amount of seconds it takes for your new record to become active. Usually this is set to 300 - 5 minutes - but sometimes is set to 86400 - 1 day.

We highly recommend ~all

Though -all is officially the strictest SPF policy, we will always recommend to qualify your SPF record with ~all:

  1. -all could lead to problems with the SPF record itself;
  2. -all does not add additional safety to the record (compared to ~all)

Let's take a deeper dive into how that works.

Why -all could lead to problems with the SPF record

Forwarding and replying to messages is often done without rewriting the Return-Path. This causes the receiving server to perform an SPF check on the wrong (intermediate) host. Obviously, this leads to unexpected 'rejected' messages. Although this is just a configuration error, there are much riskier situations where -all can lead to problems.

Why -all isn't safer than ~all, considering DMARC

SPF itself only checks the Return-Path (MAIL FROM), not the header From (the one that is visible to your recipient). This makes SPF non-effective without a proper DMARC policy. Spammers can easily use an SPF validated Return-Path and still use a spoofed header From. This is why SPF needs a DMARC policy. However, DMARC treats -all and ~all equally, according to its RFC. So if you take into account the problems that arise with an -all qualifier, using ~all is the better option.

Although -all should be better, the result is this policy is extra bounces. For these bounces, we (as a sender) are held accountable. So, how tempting the -all policy may be, there are close to zero scenarios where this provides extra security.

Size of the SPF record

An SPF record may contain a maximum of 10 lookups, otherwise the check fails. This maximum number also counts so-called nested lookups - includes within a record that you included. The mechanisms that count towards this number are: a, include, and mx.

How do I prevent too many lookups in my record?

You can prevent your SPF record from exceeding the maximum number of lookups by taking a few things into consideration:

  1. Avoid include-statements, when they are not needed, but rather use ip4 or ip6;
  2. Avoid using ptr;
  3. Remove duplicate and unused mechanisms;
  4. Don't refer to domains that send little to no email.

Looking for errors in the wrong places?

Sometimes, you'll find oddities in your SPF record. Not all of them are harmful to your SPF validity, though. We've listed a few things that might look odd, but don't have an impact on how receiving mail servers view your SPF record.

Multiple strings

An SPF record usually consists of a single string of mechanisms: v=spf1 mx -all

However, you are allowed to use multiple strings in one record. The RFC clarifies that v=spf1 .... first" "second string..." is equivalent to: v=spf1 .... firstsecond string.... Though it's not the most logical practice, it shouldn't affect the SPF record check.

Have another question about the Sender Policy Framework?

Feel like this article misses some information about the Sender Policy Framework or does it not answer your specific question? Read our explanation of SPF, our dissection of the SPF record, or reach out to us to discuss your situation.

Nick van Dijk

Business Developer



Like a true Business Developer, Nick knows what is going on in customer projects, analyzes pitfalls, and writes about what he sees happening with (potential) customers - so you don't make the same mistakes.

Want to stay up to date on Flowmailer resources?