Multiple SPF records and too many DNS lookups: how to fix

How an SPF record is structured

An SPF record is a TXT record on the domain that starts with v=spf1, lists the servers allowed to send mail for the domain, and ends with an all mechanism saying what to do with everything else. For example: v=spf1 ip4:203.0.113.10 include:_spf.google.com -all.

The include mechanism pulls in another domain's SPF record, which is how email services publish their sending servers. The ending -all says other servers should fail; ~all asks for a soft fail. Records for subdomains are separate: example.com and mail.example.com each have their own SPF record, and that is allowed.

Why domains end up with multiple SPF records

Almost always, a new email service's setup guide said "add this TXT record", and someone created a second record starting with v=spf1 instead of adding the service to the existing one. After a few tools, a domain can carry three or four.

Under RFC 7208, when a receiver finds more than one SPF record for the same name, the result is permerror, so the domain is worse off than with either record alone. Note what does not count as multiple records: one TXT record split into several quoted strings, which is how long records are stored, and TXT records for other purposes such as site verification codes. The DNS check reads the domain's TXT records from several resolvers and warns when it finds more than one SPF record.

How to merge multiple SPF records

Combine every authorised sender into a single record, then delete the extras:

1. 1List every SPF record on the domain and every service that actually sends mail as it: the mailbox provider, newsletter tools, the website's contact form, invoicing and helpdesk software.
2. 2Start the new record with v=spf1, then add each needed mechanism once: every include, ip4 and ip6 from the old records. Drop duplicates and services no longer in use.
3. 3End with a single all mechanism, matching your policy, such as ~all or -all. An all anywhere except the end makes the mechanisms after it ignored.
4. 4Publish the merged record, for example: v=spf1 include:_spf.google.com include:spf.protection.outlook.com ip4:203.0.113.10 ~all.
5. 5Delete the old SPF records so only the merged one remains.
6. 6Run the DNS check to confirm every resolver returns a single SPF record, allowing for the old records' TTL to expire.

The 10 DNS lookup limit

To stop SPF from being used to flood DNS servers, RFC 7208 caps evaluation at 10 terms that require DNS queries. These count: include, a, mx, ptr and exists mechanisms, and the redirect modifier. These do not: ip4, ip6 and all, because they need no lookup.

Lookups inside included records count too. A single include can cost several lookups if the provider's record contains includes of its own. Exceeding 10 produces permerror, even if the sending server would have matched an early mechanism, so a record that looks short can still fail. The specification also limits void lookups, queries that return no answer, to two before evaluation fails.

The mx mechanism carries one more rule of its own: if the domain's MX lookup returns more than 10 mail server names, the mx mechanism produces a permerror too. Domains with large mail clusters are better served by ip4 and ip6 entries.

How to get back under 10 lookups

Reduce the lookup count with the safest options first:

• Remove includes for services you no longer use. Old records often outlive the tools they were added for.
• Replace a and mx mechanisms with ip4 or ip6 entries when the addresses are servers you control and know will not change.
• Remove ptr. RFC 7208 says it should not be used, and it costs a lookup.
• Move senders to subdomains. Marketing or transactional email sent from a subdomain, such as news.example.com, checks SPF against that subdomain's own record and its own 10-lookup budget.
• Flatten with care. Replacing an include with the provider's current IP addresses removes lookups, but the provider can change those addresses without warning, so flattened records need automated upkeep or they silently break.

Other SPF mistakes to check while you are there

While editing the record, look for these common problems as well:

• +all at the end, which authorises every server on the internet to send as your domain and defeats the purpose of SPF.
• No all mechanism at all, which leaves unlisted servers with a neutral result.
• A record of the old SPF DNS type instead of TXT. RFC 7208 deprecated the separate SPF record type, so publish SPF as TXT only.
• The record on the wrong domain. SPF checks the envelope sender (the Return-Path address), not the From address people see. Many email services use their own domain as the envelope sender unless you set up a custom return path, in which case their SPF include belongs on that custom domain.
• Typos such as a missing space between mechanisms, curly quotes pasted from a document, or include targets copied with a typo.

Checking the fix

After publishing, confirm the change at the DNS level and at the mail level. The DNS check compares the TXT records returned by Google, Cloudflare, DNS.SB and AdGuard with the authoritative nameserver, so you can see when the merged record has replaced the old ones everywhere and what TTL is still being honoured.

Then send a test message from each sending service to a mailbox you can inspect, and read the Authentication-Results header in the received message. It should show spf=pass. If it shows permerror, count the lookups again, including those inside each include.