Two SPF records or more than 10 lookups: the SPF that looks fine and doesn't work

Why it stops working

• Two SPF records: the SPF rules allow only one record starting with v=spf1 per domain. With two, the result is an error, and neither counts.
• More than 10 lookups: every include:, a, mx, ptr, exists and redirect= needs a DNS lookup, and the ones each include: brings with it count too. Above 10, the result is an error.

With SPF in error, your email is left with only DKIM to prove it's yours. If DKIM isn't on either, DMARC fails, and your genuine emails can go to spam, or be refused if DMARC is at quarantine or reject.

Step 1: see what you have

Run the check above. If you see “Your domain has two SPF records, so neither one counts” or “Your SPF record is too long for mail servers to check”, “Show the evidence” shows the records exactly as they are in DNS.

In your DNS panel, look among the main domain's TXT records (empty name or @) for the ones starting with v=spf1.

Step 2: merge two records into one

For example, you have these two, one for your email and one for newsletters:

• v=spf1 include:_spf.google.com ~all
• v=spf1 include:servers.mcsv.net ~all

Together they become a single record:

Type

TXT

Name (host)

@

Value

v=spf1 include:_spf.google.com include:servers.mcsv.net ~all

1. Edit one of the records and put every include: from both in it (and any ip4: or ip6:), once each.
2. End with a single all: ~all if you're not sure every service that sends for you is listed, -all if you are.
3. Delete the other record.

Never use +all: it allows any server in the world to send email as you.

Step 3: cut down the number of lookups

If the problem is more than 10 lookups, merging isn't enough: something has to go. In this order:

1. Remove services you no longer use. It's the most common cause: the newsletter provider you left two years ago is still in your SPF.
2. Check each service's help to see whether it really needs to be in your SPF. Many sending services use their own return address (or a subdomain of yours), and then your SPF isn't even checked for those emails: what counts is their DKIM signature with your domain.
3. Always remove ptr: the SPF rules themselves advise against it. Remove a and mx only if you're sure no email leaves from those servers.
4. Send newsletters from a subdomain (for example news.yourcompany.com), with its own SPF. Each subdomain has its own limit of 10.

Avoid replacing include: entries with lists of IP addresses copied by hand: services change IPs without warning, and SPF stops working without anyone noticing.

Step 4: confirm

After saving, wait for DNS to update (minutes to a few hours) and check again. Excubitor counts the lookups for you, including the ones each include: brings.

If you end up with 9 or 10 lookups, you'll see “Your SPF record is close to its limit”, as “Can wait”: it works, but the next service you add will break it. Tidy up before adding another.

Mistakes we see often

• Following a new service's instructions to the letter and creating a second SPF record, instead of adding its include: to the existing one.
• Two all terms in the same record, or an all in the middle: everything after it is ignored.
• The SPF record put on a subdomain by mistake (for example www) instead of the main domain.
• An old record of type “SPF” next to the TXT one. That type is no longer used: the TXT record is what counts.

What comes after SPF?

Make sure DKIM is on: without it, an SPF error leaves your email with no proof at all that it's yours.

DKIM in Google Workspace, step by step

DKIM in Microsoft 365, step by step

So you don't have to check again

SPF breaks on the day someone adds a new service, and nobody notices until emails start failing. Excubitor can watch the domain every week and email you only when something changes. Free for 1 domain: run the check and press “Notify me”.