Multiple SPF records on one domain: why it causes permerror and how to fix it

Quick answer

A domain must publish exactly one SPF record — one TXT record beginning with v=spf1. If your domain has two or more, RFC 7208 §3.2 requires receivers to return permerror, which means SPF does not pass for any message from that domain. The fix is to merge every legitimate sender's mechanisms into one record and delete the duplicates.

What counts as a duplicate SPF record — and what does not

A domain is allowed to publish many TXT records at the same name. A domain-ownership verification string from Google Search Console, a DMARC record, a DKIM public key — none of these create a conflict. Having several TXT records at your apex or a subdomain is normal and expected.

The problem is specific: two or more of those TXT records each begin with v=spf1. That prefix is the signal receivers use to identify an SPF record. If they find it more than once on the same name, RFC 7208 §3.2 does not leave the result ambiguous — the check_host() function must return permerror. Receivers apply permerror and stop; they do not merge the records, use the longer one, or fall back to any other result.

SPF is also evaluated per DNS name, not per domain. Your apex (example.com) and a subdomain (mail.example.com) each carry their own SPF record independently. "Multiple records" means multiple v=spf1 entries at the same queried name, not across different names in your zone.

Why duplicate SPF records happen

The most common cause is organisational, not technical. Different teams or vendors each add their own SPF record over time, each unaware that one already exists.

A typical sequence looks like this: someone sets up Google Workspace and follows the Google SPF guide, which tells them to add a TXT record beginning v=spf1 include:_spf.google.com. A year later, a marketing team adds a newsletter platform and the platform's setup wizard tells them to add another TXT record beginning v=spf1 include:sendgrid.net. The previous record is never mentioned in that wizard, so now there are two. Later still, someone migrates away from an older email provider but never removes the SPF record that was published for it, leaving a third.

Each of those additions was individually correct. The mistake is that each one was added as a new record rather than merged into the existing one. The DNS zone accumulates SPF records silently, and the problem stays invisible until a receiver runs SPF evaluation and returns permerror.

This pattern is especially common after an ESP migration, after adding a CRM with its own outbound mail feature, or after absorbing another company's domain into your infrastructure.

How permerror affects your authentication stack

When a receiver encounters multiple v=spf1 records, SPF evaluation returns permerror. That result means SPF does not contribute a pass. No mechanism in the record is evaluated. The sending IP is never checked. The whole SPF path for that message is dead.

For DMARC, this matters in a specific way. DMARC can still pass if DKIM is aligned — RFC 7489 requires only one of the two authentication paths to produce an aligned pass. So if your domain has a valid, aligned DKIM setup, a duplicate-SPF permerror may not cause immediate delivery failures at receivers that enforce DMARC. DMARC will pass via DKIM, and SPF's failure will show in aggregate reports as a failed SPF path.

However, relying on DKIM alone to carry DMARC is a narrower stack than you want. Forwarded messages commonly break DKIM signatures because intermediate servers modify headers or body content. If SPF is broken and a forwarded message also breaks DKIM, DMARC has nothing left to align against. At a p=reject policy, that message is refused. At p=quarantine, it routes to spam. The duplicate-SPF defect may be latent in normal conditions and surface only in edge-case delivery paths, which is exactly the kind of failure that is hard to diagnose after the fact.

Outside DMARC, some receivers evaluate SPF in isolation and may treat permerror as a failure signal on its own terms, independently of DMARC policy.

How to diagnose duplicate SPF records

Query every TXT record published at the domain name you want to check. You can do this from any command line with nslookup -q=TXT example.com on Windows, or dig TXT example.com on macOS or Linux. The output lists all TXT records at that name. Count how many of them start with v=spf1. If the answer is more than one, you have the defect.

A few things to confirm as you read the output:

• You are querying the right name. If the bounce or error refers to a subdomain like mail.example.com or send.example.com, query that name, not the apex. SPF is name-specific.
• All the records are fully visible. Some DNS management tools paginate or truncate results. If you see one record in a UI but two in a command-line query, the UI is hiding one.
• The records are at the same name. An SPF record at example.com and a separate SPF record at mail.example.com are independent and not in conflict with each other.

Once you confirm two or more v=spf1 records at the same name, proceed to the fix.

How to fix multiple SPF records

1. List every v=spf1 TXT record published at the affected name. Copy the full text of each one.

2. Collect every mechanism from every record: all include: references, all ip4: and ip6: addresses, and any a: or mx: mechanisms that represent real outbound senders. Discard mechanisms from providers you no longer use.

3. Write one new v=spf1 record that contains all the legitimate mechanisms from step 2, followed by a single all qualifier. A typical merged record looks like this:

   v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.45 -all
   

4. Before publishing, count the DNS lookups your merged record will trigger. Each include:, a, mx, ptr, and exists mechanism counts toward the 10-lookup limit defined in RFC 7208. If your old records had many include: references spread across two records, merging them into one may push you past that limit and cause a different kind of permerror. Check the lookup count before publishing; if you are close to or over 10, review the SPF DNS lookup limit problem page before proceeding.

5. In your DNS management interface, update one of the existing v=spf1 records to contain the merged record from step 3.

6. Delete every other v=spf1 record at the same name until exactly one remains.

7. Note the TTL of the record. Wait for at least one full TTL cycle — often between one and twenty-four hours — before testing. Receivers may still be serving the old, conflicting records from cache until the TTL expires.

8. After the TTL has passed, re-query the domain and confirm that exactly one v=spf1 record is visible. Send a test message to a Gmail or Outlook personal account and inspect the Authentication-Results header in the original message. It should show spf=pass.

For Google Workspace specifically, Google's SPF setup guide describes the correct record for their infrastructure. For Microsoft 365, Microsoft's SPF configuration guide covers the correct include: mechanism and any co-existence requirements. If you use both providers, both include: references go into the single merged record, not as separate records.

What this does not prove

Relaymetry reads the publicly visible TXT records for your domain and counts how many begin with v=spf1. If there is more than one, the duplicate is confirmed and the mechanism content of each is shown so you can plan the merge.

What a public DNS check cannot determine: whether the merged record you publish will authorize the right set of sending IPs for your specific outbound mail streams, whether SPF evaluation for a specific past delivery attempt returned permerror for this reason or a different one, whether DKIM is passing or aligned, and whether DMARC aggregate reports show the fix has taken effect in practice. For those answers, you need message headers from a real delivery attempt, access to your DMARC aggregate report feed, and knowledge of every platform that sends on your domain's behalf.

Resolving duplicate SPF records closes one failure mode. It does not guarantee that SPF will pass after the merge — a merged record can still fail if the real outbound platform is not listed, if the lookup limit is exceeded, or if a syntax error is introduced during editing.

Related guides

• Email authentication explained
• SPF too many DNS lookups: fix the PermError
• DKIM record not found: how to diagnose and fix it