Multiple SPF Records: Why They Break and How to Fix

Multiple SPF records on the same domain are invalid: receivers that find two or more TXT records starting with v=spf1 return an SPF permerror, and SPF fails for all mail from that domain. A domain may publish only one SPF record. Fix it by merging every include:, ip4: and ip6: mechanism into a single record with one all at the end.

Why are multiple SPF records a problem?

SPF allows exactly one record per domain name. If a receiver queries your TXT records and finds more than one that begins with v=spf1, RFC 7208 says the result is a permanent error (permerror). The receiver does not pick one, and it does not combine them. The check simply fails to produce a pass.

The practical effects:

• SPF cannot pass for any of your senders, even ones listed correctly in one of the records.
• DMARC can still pass through DKIM, but only if DKIM is signed and aligned. If you rely on SPF alignment, DMARC fails too.
• Receivers treat the error differently, so the symptoms are inconsistent: some mail lands in spam, some is rejected, some is delivered.

You can read the details in RFC 7208, section 4.5.

How do multiple SPF records happen?

Almost always, they happen because someone follows a vendor's setup instructions without checking what already exists. Typical causes:

• A marketing, CRM or helpdesk platform tells you to "add this TXT record", and you add it as a new record instead of editing the current one.
• Two teams manage DNS separately, such as IT for Microsoft 365 and marketing for a newsletter tool.
• A migration leaves the old provider's record behind.
• A DNS host shows the same name twice, and nobody notices.

Here is a typical broken setup:

example.com.  IN  TXT  "v=spf1 include:spf.protection.outlook.com -all"
example.com.  IN  TXT  "v=spf1 include:mailer.example.net -all"

Each record looks fine on its own. Together they produce a permerror.

How do I check if my domain has multiple SPF records?

Query your domain's TXT records and count the entries that start with v=spf1. If there is more than one, you have duplicates. You can do this with dig, or use a free checker such as the domain scanner, which reports your SPF, DMARC and DKIM-related records.

From a terminal:

dig +short TXT example.com

On Windows:

nslookup -type=TXT example.com

Look only at the apex name (or the exact subdomain you are checking). Other TXT records, such as site verification strings, are fine. Only entries starting with v=spf1 count toward the limit.

Also check each sending subdomain separately. SPF is evaluated on the domain in the envelope sender (Return-Path), so bounce.example.com needs its own single record if it is used that way.

How do I fix multiple SPF records?

Merge them into one record. Keep a single v=spf1 at the start, combine all the mechanisms, and finish with one all qualifier.

Start by listing every sender that legitimately sends as your domain. For each duplicate record, copy the mechanisms (everything between v=spf1 and all). Then build one record:

example.com.  IN  TXT  "v=spf1 include:spf.protection.outlook.com include:mailer.example.net -all"

Then:

1. Delete the extra SPF TXT records in your DNS panel, leaving only the merged one.
2. Remove includes for services you no longer use.
3. Wait for the TTL to expire, then re-query the domain to confirm only one v=spf1 record is returned.
4. Send a test message and check the Authentication-Results header for spf=pass.

If you are unsure which all to use, -all (hard fail) is the strictest and ~all (soft fail) is more forgiving while you verify your sender list. Do not leave two different all terms; the merged record has just one.

Does a long SPF record count as multiple records?

No. A long record split into several quoted strings inside one TXT record is still one record. DNS limits each character string to 255 characters, but a TXT record can contain several strings, and receivers join them together before evaluating. Splitting strings is fine; publishing separate records is not.

This is how a single record with several strings looks:

example.com.  IN  TXT  "v=spf1 include:spf.protection.outlook.com include:mailer.example.net " "include:crm.example.org ip4:192.0.2.10 -all"

Most DNS providers handle the splitting automatically. If yours does not, check the provider's documentation on long TXT values.

What is the 10-lookup limit, and why does merging make it worse?

SPF allows at most 10 DNS-querying mechanisms and modifiers per evaluation: include, a, mx, ptr, exists and redirect. Exceeding 10 also causes a permerror. Merging duplicate records combines their lookups into one evaluation, so a merge can push you over the limit even though each old record was under it.

Nested includes count too. An include: that itself contains three more includes uses four lookups in total. The ip4:, ip6: and all mechanisms do not trigger lookups.

If your merged record is over the limit:

• Remove includes for vendors you no longer use.
• Replace a or mx mechanisms with ip4: or ip6: ranges where the addresses are stable.
• Move high-volume or third-party senders to their own subdomain, such as news.example.com, each with a single SPF record of its own.
• Check whether a vendor can send from a subdomain with its own return path, so it does not need to appear in your main record at all.

Subdomain separation is often the cleanest long-term fix because each sender's SPF record stays small and independent.

How do I stop duplicates from coming back?

The fix only holds if the process changes. A few habits help:

• Treat SPF as one shared record with a named owner. Anyone adding a sender edits that record, not DNS in general.
• Ask vendors whether they require an SPF change at all. Many only need DKIM and a CNAME for a custom return path.
• Keep a list of authorised senders and review it when contracts end.
• Monitor authentication results continuously. A new duplicate shows up as SPF permerrors in your DMARC aggregate reports, which is much earlier than a user complaining about missing mail. DMARC monitoring collects and visualises those reports for your domains, so a sudden change is easy to spot.

You can also run your domain through the DMARC lookup tool after changes to confirm your DMARC record is still published as expected. If SPF and DKIM problems are part of a larger effort to meet sender rules, the compliance page explains what Google, Yahoo and other requirements expect.

Key takeaways

• A domain must publish only one TXT record beginning with v=spf1. Two or more cause an SPF permerror.
• Receivers do not merge or choose between duplicates, so even correct senders fail SPF.
• Fix it by combining all mechanisms into a single record with one all at the end, then deleting the extras.
• A long record split into multiple quoted strings is still one record and is valid.
• Merging adds up DNS lookups; keep the total at or below the limit of 10, using subdomains or cleanup if needed.
• Verify with dig or a domain scanner, and watch DMARC aggregate reports to catch new duplicates early.