Why you can only have one SPF record, and how to merge duplicates

DNS has no rule against publishing two TXT records that both start with v=spf1 on the same domain. The SPF specification does have a rule against it, and most receiving mail servers follow that rule strictly: a domain with more than one SPF record is treated as a permanent error (permerror), and that is scored the same as, or worse than, having no SPF record at all.

How this happens

It almost never happens on purpose. The common sequence:

1. You set up SPF for your first ESP: v=spf1 include:sendgrid.net ~all
2. Months later you add a second sender and, following that provider's own setup instructions in isolation, you add a *second* TXT record: v=spf1 include:mailgun.org ~all
3. Both now exist in DNS simultaneously. Neither sender's instructions warned you to check for an existing record first.

Check whether you have this problem

$ dig yourdomain.com TXT +short
"v=spf1 include:sendgrid.net ~all"
"v=spf1 include:mailgun.org ~all"
"google-site-verification=abc123..."

Any line starting with v=spf1 counts. If dig returns more than one, you have multiple SPF records. Note that other TXT records (site verification, DKIM, anything else) are unrelated and do not conflict - the rule is specifically about records that begin with v=spf1.

Merge them into one

Take every mechanism from every v=spf1 record and combine them into a single record:

v=spf1 include:sendgrid.net include:mailgun.org ~all

A general merge pattern:

1. List every `include:`, `ip4:`, `ip6:`, `a`, and `mx` mechanism across all existing SPF records.
2. Combine them into one record, keeping each mechanism only once even if it appeared in more than one original record.
3. Keep a single qualifier at the end - ~all (soft fail) or -all (hard fail), never both, and never more than one all mechanism.
4. Replace both old TXT records with the single merged one in your DNS panel - delete, don't just add.

Watch the lookup budget while merging

Each include: costs at least one DNS lookup during evaluation, and SPF evaluation fails outright past 10 total lookups. Merging two records that were each already close to the limit on their own can push the combined record over it. If you're merging four or more include: mechanisms, count the nested lookups each one triggers before publishing - a provider's own include often nests several more lookups inside it.

Verify after merging

$ dig yourdomain.com TXT +short
"v=spf1 include:sendgrid.net include:mailgun.org ~all"

Exactly one line starting with v=spf1. Then re-send a test message through each sender and confirm spf=pass for all of them in the delivered message's headers.

What not to do

• Don't add a new sender's SPF instructions as a fresh TXT record without first checking for an existing one - this is the single most common cause of this failure.
• Don't assume ~all (soft fail) protects you from the multiple-record problem - soft fail only changes what happens when none of the mechanisms match; a permerror from having two records is evaluated before mechanisms are even checked.
• Don't forget to delete the old records in your DNS panel - some panels let you add a new TXT without clearly surfacing the old one still sitting there.

Single vs multiple SPF records

FAQ

If I have two SPF records and one of them alone would pass, does the passing one count? No. Receivers that correctly implement the SPF specification stop at the duplicate-record check before evaluating either record's mechanisms - a permerror is returned before any IP matching happens, so which record "would have passed" is irrelevant.

Can my DNS provider warn me if I have duplicate SPF records? Most registrar and DNS panels will let you create the second record without any warning, because DNS itself has no rule against multiple TXT records with the same prefix - this is a mail-specific rule, not a DNS-level one, so the panel has no reason to flag it.

How often should I audit for this? Any time you or a teammate adds a new sending service following that service's own setup instructions in isolation, re-check with dig yourdomain.com TXT +short immediately afterward - this is the single highest-risk moment for creating a duplicate.

MailPilot's deliverability checks flag SPF errors including duplicate records as part of the authentication status it reports per domain, so a merge mistake shows up before it costs you inbox placement.