Multiple SPF records: why a second one breaks both

A new provider tells you to add include:their-domain.com to your SPF record. There's already an SPF record in your DNS panel, so adding a second TXT record looks like the careful move. The old record stays as it was and the new provider gets its include. Every DNS panel lets you save it, and both records stop working the moment you do.

Which record wins? Neither. A receiver that finds two returns permerror, and every sender in both records loses its pass.

Two records on one name

Two SPF records on one name return permerror for both. The receiving server, at Gmail, Outlook or wherever you sent to, fetches the TXT records at your domain and keeps the ones starting with v=spf1. RFC 7208 section 4.5 says that if more than one comes back, the check returns permerror and stops. The receiver doesn't merge them and it doesn't pick one. It couldn't pick anyway, since DNS returns the two in whatever order it likes.

So the sender you just added doesn't pass, and neither does anything that passed yesterday:

The fix is one record holding both:

Mail after a permerror

Most receivers accept a message after a permerror, so nothing bounces and nobody notices. RFC 7208 leaves it to the receiver what to do with the result. So on the day you add the second record, mail still arrives and the panel still shows two tidy rows.

What you've lost is the SPF pass. DMARC needs SPF or DKIM to pass and align, and after a permerror it gets no SPF pass from any sender in either record. Under p=none that only shows up in your aggregate reports. Under p=reject, every message without a valid DKIM signature starts bouncing. The first to go are the tools that never signed anything, like the invoicing app or the contact form on the website.

Finding a second record

DNS panels list TXT records as unrelated rows, so two SPF records look like two ordinary entries. Query the name instead:

If two lines come back, you have two records. This works on any domain, so you can run it on a client's before a migration.

Merging the records

Take every mechanism from both records, drop the duplicates, and end with a single all. Order doesn't matter for include: and ip4: terms. You still have to choose the ending and check the lookup count.

If one record said -all and the other ~all, the merged record gets one of them. Pick ~all until you're sure the sender list is complete. Going to -all on a record that's missing a sender turns that sender's mail into bounces.

Each old record had its own ten lookups. The merged record has ten for both. Two records at six lookups each merge into one at twelve, which is a permerror for a different reason. The 10-lookup limit guide covers getting back under it.

Paste the merged record into the pre-flight before you publish it. It resolves the record against live DNS, counts the lookups it really costs, and lists any sender that passed under the old records and wouldn't under the new one. A DNS panel can't run that check, because there's nothing to read until you publish.

Subdomains

Each subdomain gets its own record, because different names get different records. A subdomain doesn't inherit its parent's SPF, so a domain sending from example.com and mail.example.com publishes one record at each name. That's two records on two names, and it's correct:

It's also a good answer when a bulk sender pushes you past ten lookups. Give it a subdomain with its own record and your main domain keeps its own budget. Mail from the subdomain aligns to the subdomain, which DMARC accepts under relaxed alignment and rejects under strict.

Once the merged record is live, check that it lists every server that sends as you. DMARC aggregate reports list the sources that actually sent mail as your domain. We read those reports and send you a weekly digest of what's in them, free for your first domain.