Merging multiple SPF records into one
If we flagged multiple SPF records on your domain, that's RFC 7208 §3.2 territory: 'A domain name MUST NOT have multiple records that would cause an authorization check to select more than one record.' Receivers respond with permerror, which means every sender - including your legitimate ones - gets treated as unauthorized. Here's how it usually happens and the safe merge path.
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.
The merge safely, step by step
- 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. - Catalog the unique mechanisms. Walk each record's mechanisms (the
include:,ip4:,a:,mxbits) and write down each unique one. Don't include duplicates - if both records haveinclude:_spf.google.com, you only need it once. - Pick a single qualifier on `all`. Each existing record probably ends with
-allor~all. Pick whichever is more conservative (default to-allif you're confident your sender list is complete;~allif you want a softer fallback). - Build the merged record. Combine:
v=spf1+ space-separated unique mechanisms + space + your chosenallqualifier. - Watch the lookup count. Each
include:and mosta:/mxmechanisms count toward the10-lookup cap. Merging records doesn't reduce lookups - if the combined list crosses 10, you'll trip a different anomaly. See the lookup-counting article for how to come back under. - 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 - the original record is still there until the last second.)
- 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.
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 - getting it wrong means accidentally dropping a verification token or other unrelated TXT. For now, merging stays manual.
Keep reading
Counting your SPF lookups (and why you might be at 11)
SPF caps DNS lookups at 10. Cross it and mailbox providers return permerror. What counts, what doesn't, and how to come back under.
Why 1024-bit DKIM keys are being phased out
NIST deprecated 1024-bit RSA in 2013, Google now warns about it. Here's the rotation playbook to 2048-bit without breaking current mail.
Removing a revoked DKIM selector
When a DKIM selector publishes p= with an empty value it's signaling revocation per RFC 6376. Receivers will keep failing your mail until you delete the record (or republish the key). Here's how to tell which.
Free for one domain. Set up in five minutes. We parse the reports; you read plain-English summaries.