Multiple SPF Records: Why You Can Only Have One (And How to Fix It)

If a mail server rejects your messages with something like permerror (SPF: multiple DNS records found), the cause is almost always the same: your domain publishes more than one SPF TXT record. Unlike DKIM, which allows multiple selectors, SPF has a hard rule — a domain may have exactly one v=spf1 record. This article explains why the duplicate happens, how to find it, and how to merge two SPF records into one without breaking either source’s authorization.

Why “more SPF records” doesn’t mean “more protection”

It’s a common misconception that adding a second SPF record will authorize an additional sending service, similar to how you’d add another DKIM selector. SPF doesn’t work that way. RFC 7208 is explicit: if a domain has more than one record that starts with v=spf1, SPF evaluation must return permerror — a permanent, unrecoverable error. Receiving mail servers won’t try to figure out which record is “correct”; they treat the ambiguity itself as a failure, and depending on the receiver’s policy, that can mean outright rejection or heavy spam scoring.

This usually happens when:

• Your email marketing platform (e.g. Mailchimp, SendGrid) asks you to “add this SPF record,” and you add it as a new TXT entry instead of merging it into the existing one.
• Your hosting provider or domain registrar auto-generates a default SPF record when you set up mailboxes, on top of one you already had.
• Two teams (marketing and IT) independently configure SPF for different tools without checking what’s already published.

Step 1: Confirm you actually have duplicate records

Query your domain’s TXT records directly:

dig TXT yourdomain.com +short

Look for more than one line starting with "v=spf1". For example:

"v=spf1 include:_spf.google.com ~all"
"v=spf1 include:sendgrid.net ~all"

Both lines are valid SPF syntax individually, but published together on the same domain they trigger a permerror. Also check for near-duplicates that differ only in whitespace or capitalization — DNS treats those as separate records too.

A note on subdomains

SPF is evaluated per exact hostname. mail.yourdomain.com and yourdomain.com each need their own single SPF record if they send mail independently. Don’t confuse “I have SPF on the root domain” with “my subdomain is covered” — it isn’t, unless you explicitly publish a record there too.

Step 2: Merge the records into one

The fix is to combine every required include, ip4, ip6, or a/mx mechanism into a single v=spf1 line, then delete the extra TXT records entirely.

Given the two example records above, the merged version is:

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

1. List every sending source currently authorized across all your SPF-like TXT records (mail platform, CRM, helpdesk, transactional email API, on-prem mail server, etc.).
2. Write one new TXT record starting with v=spf1, adding one include: (or ip4:/ip6:) mechanism per source.
3. Keep exactly one all mechanism at the end — ~all (softfail, recommended while testing) or -all (hardfail, recommended once verified).
4. In your DNS provider’s dashboard, delete the old SPF TXT records and publish only the merged one.
5. Wait for your TXT record’s TTL to expire, then re-query with dig TXT yourdomain.com +short to confirm only one v=spf1 record remains.

Step 3: Watch the lookup count while merging

Every include, a, mx, ptr, and exists mechanism counts toward SPF’s 10-DNS-lookup limit, and merging records often surfaces this problem for the first time because you’re now looking at every source in one place. If your merged record is approaching or exceeding 10 lookups, resolve that separately before publishing — a record that fixes the duplicate-record permerror but introduces a lookup-limit permerror hasn’t actually solved anything.

Step 4: Validate before you rely on it

Don’t just eyeball the syntax. Use an SPF validation tool (or a full DNS health scan) to confirm:

• Exactly one v=spf1 TXT record exists on each hostname that sends mail.
• The record parses without syntax errors (missing colons, malformed IP ranges, and misplaced all mechanisms are common typos when merging by hand).
• The total DNS lookup count is 10 or fewer.
• Every legitimate sending source you rely on is actually represented in the merged record — it’s easy to drop one while copy-pasting.

Finally, send a real test message through each platform you authorized (your marketing tool, your transactional API, your primary mail server) and check the Authentication-Results header on the receiving end for spf=pass. A clean SPF result there confirms the merge worked end-to-end, not just in theory.

Preventing this from recurring

The root cause is almost always process, not DNS: someone adds a new SPF snippet without checking what’s already published. Before adding any SPF-related TXT record, always query the domain first, and treat “update the SPF record” as an edit to the existing single record rather than a new addition. If multiple people manage DNS for your organization, document the current SPF record and its authorized sources somewhere visible, so the next integration gets merged in rather than bolted on.