Merging multiple SPF records into one

Why multiple records exist (it's almost always accidental)

Most of the time, multiple SPF records show up because two different teams or tools each published their own version without checking what was already there. Common culprits:

• You added a new sender via your DNS provider's UI and it created a NEW TXT record instead of editing the existing one.
• An ESP automation (the "click here to set up SPF" button in a marketing platform) published its own record without merging.
• You migrated DNS providers and the export/import duplicated the SPF entry instead of replacing it.

What a single merged record looks like

Suppose you currently have these two records at the apex:

v=spf1 include:_spf.google.com -all
v=spf1 include:mailgun.org -all

The merged version concatenates the mechanism lists into a single record:

v=spf1 include:_spf.google.com include:mailgun.org -all

Then delete the second record entirely. Only the merged one stays.

Merging safely, step by step

1. List every existing SPF record. Open your DNS provider's dashboard and find every TXT record at the apex of your domain that starts with v=spf1.
2. Catalog the unique mechanisms. Walk each record's mechanisms (the include:, ip4:, a:,mx bits) and write down each unique one. Don't include duplicates. If both records have include:_spf.google.com, you only need it once.
3. Pick a single qualifier on `all`. Each existing record probably ends with -all or ~all. Pick whichever is more conservative (default to -all if you're confident your sender list is complete; ~all if you want a softer fallback).
4. Build the merged record. Combine: v=spf1 + space-separated unique mechanisms + space + your chosen all qualifier.
5. Watch the lookup count. Each include: and mosta: /mx mechanisms count toward the10-lookup cap. Merging records doesn't reduce lookups. If the combined list crosses 10, you'll trip a different warning. See the lookup-counting article for how to come back under.
6. Update one record, then delete the other. Most DNS providers let you edit a record in place. Update record #1 with the merged value, save, THEN delete record #2. (Doing it in this order means you're never without SPF coverage, because the original record is still there until the last second.)
7. Verify. Open the SPF tab and run a fresh scan. The multi-record warning should clear, and the lookup count and final qualifier should reflect your merged record.

If the warning does not clear

Three things account for almost every case, in order of likelihood:

• A resolver is still serving the old pair. Your records carry a TTL, and caches honor it. Wait out the TTL on the records you edited, then scan again.
• The delete did not apply. Some panels save an edit and silently drop a delete. Count the records yourself with dig +short TXT yourdomain.com | grep spf1 , which should return exactly one line.
• The second record is somewhere else. SPF only applies at the exact name it is published on, so a leftover at a subdomain does not trip an apex warning, but a stale zone at a previous DNS host that is still authoritative will. Re-check which nameservers actually answer for the domain with dig +short NS yourdomain.com.

Why we don't auto-fix this

Merging two SPF records means deleting one, and our V1 DNS-fixer apply path doesn't currently support record deletion (only TXT create/update). We could add it, but it's higher-stakes than create/update, because getting it wrong means accidentally dropping a verification token or other unrelated TXT. For now, merging stays manual.