Fix: Multiple SPF Records Detected (One Record Rule)

If an email diagnostic tool reports "Multiple SPF records detected" or outbound messages bounce with 550 5.7.26 PermError: duplicate SPF records, your domain has published more than one SPF TXT record in DNS. Under internet email standards, a domain may have only one valid SPF record. Publishing multiple records breaks SPF validation entirely, causing receiving mail servers to treat authentication as a hard failure and potentially reject your email under DMARC enforcement.

Quick Answer

RFC 7208 forbids publishing more than one SPF record per domain. If multiple v=spf1 TXT records exist, receiving mail servers stop evaluating and return a PermError, causing DMARC to fail. To fix this, merge all authorized IP addresses and include: mechanisms into a single DNS TXT record and delete the extras.

---

The One Record Rule Explained

The Sender Policy Framework is defined by RFC 7208. Section 3.2 explicitly states:

“A domain name MUST NOT have multiple records that would cause an SPF check to find more than one record.”

When an incoming mail transfer agent (MTA) receives a message, it queries DNS for all TXT records associated with the sender’s envelope domain (Return-Path). If the DNS response contains more than one record beginning with v=spf1, the receiving server does not try to combine them, guess which one is active, or test them sequentially.

Instead, the protocol requires the receiver to halt evaluation immediately and return an SPF permanent error: PermError.

[Incoming Message Arrives]
            │
Queries DNS for TXT records starting with "v=spf1"
            │
   How many records returned?
     ┌──────┴──────┐
  Exactly 1      2 or more
     │             │
Evaluates IPs   IMMEDIATE PermError
and includes    SPF Fails
                 │
                 ▼
     Did DKIM pass and align?
        ┌──────────┴──────────┐
       YES                    NO
        │                     │
   DMARC Passes        DMARC FAILS
                    (Message Rejected or
                     Sent to Spam)

If your domain also publishes a DMARC policy of p=quarantine or p=reject, and the message lacks a passing, aligned DKIM signature, the PermError translates directly into an undelivered message. For more details on this failure state, review “Message rejected due to DMARC policy”.

---

How Multiple Records Get Created

Most administrators do not intentionally publish duplicate SPF strings. They usually appear during routine IT operations:

1. SaaS Onboarding: A new sales, marketing, or helpdesk platform (such as HubSpot, Zendesk, or Google Workspace) provides setup instructions saying: “Add this TXT record to your DNS: v=spf1 include:service.com ~all“. Instead of editing the existing record, an administrator adds a brand-new TXT record.
2. Default Registrar Placeholders: Domain registrars (e.g., GoDaddy, Namecheap) often inject a default parked-domain SPF record upon registration (such as v=spf1 include:secureserver.net ~all). Later, IT adds their company’s Google or Microsoft record without removing the registrar’s default entry.
3. Legacy SPF-Type Records vs. TXT Records: In the early days of SPF, DNS included a dedicated resource record type called “SPF” (RR type 99). That record type was formally deprecated by RFC 7208 in 2014. If your DNS zone publishes both a legacy SPF record and a standard TXT record, modern resolvers may flag a conflicting duplicate.

---

Diagnostic Steps: Finding the Duplicate Records

You can detect duplicate records via the command line using dig or nslookup.

Using dig (macOS/Linux)

dig example.com TXT +short

Look for lines beginning with "v=spf1". If you see more than one entry, you have a duplicate conflict:

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

Using nslookup (Windows)

nslookup -type=TXT example.com

Examine the output under Non-authoritative answer:. If multiple strings start with v=spf1, they must be unified.

---

Technical Fix: Merging Into a Single Record

To resolve the error, consolidate every authorized sending service and IP address into a single string, apply it to one TXT record, and delete the others.

Step 1: Inventory All Senders

Review the contents of each existing record. For example, suppose your DNS currently returns:

• Record A: v=spf1 include:_spf.google.com ~all
• Record B: v=spf1 ip4:198.51.100.14 include:mailgun.org -all

Step 2: Combine Mechanisms into a Single String

Create a unified string starting with v=spf1 and ending with your chosen qualifier (usually ~all or -all). For guidance on choosing between them, see Resolving SPF “Softfail” vs. “Hardfail”.

• Merged Record: v=spf1 ip4:198.51.100.14 include:_spf.google.com include:mailgun.org ~all

Step 3: Update and Purge in DNS

1. Log in to your authoritative DNS management console.
2. Locate the existing SPF TXT records for your root domain (@ or blank host).
3. Update one record to the newly merged string.
4. Delete all other records starting with v=spf1.
5. Check if your DNS provider lists a record of type SPF. If found, delete it; use only type TXT.

Step 4: The 10-Lookup Limit Safeguard

When merging records, be careful not to trigger a secondary error: the RFC 10-DNS-lookup limit. Each include, a, mx, ptr, or exists mechanism in your SPF record forces the receiving server to execute a DNS query.

If your combined record requires more than 10 total lookups, receiving servers will throw an SPF PermError: Too many DNS lookups. To avoid this condition, inspect the limits and mitigation steps in Troubleshooting “Too many lookups” in SPF.

Once you have verified that only one merged TXT record exists, confirm that your overall authentication meets current mail delivery baselines using The Workspace Email Authentication Master Checklist.