Multiple SPF records found: why it causes PermError and how to merge them

Your SPF checker says "multiple SPF records found", or a header shows spf=permerror. The cause is almost always the same: someone added a new SPF record for a new service instead of editing the one that was already there. The fix takes a few minutes once you know what to merge.

Why can a domain have only one SPF record?

Because the SPF standard says so, and receivers stop when they see more than one.

RFC 7208, section 3.2 says: "A domain name MUST NOT have multiple records that would cause an authorization check to select more than one record." Section 4.5 explains what happens when a receiver checks:

1. It fetches all TXT records at the domain.
2. It discards any that don't begin with exactly v=spf1.
3. If none are left, the result is none.
4. If more than one is left, the result is permerror.

The receiver doesn't try to pick the "right" record or merge them for you. Microsoft's SPF guide gives the reason in plain terms: multiple records cause PermError because "the receiving system can't determine which record to evaluate."

Only records that start with v=spf1 count. Your domain can have as many other TXT records as you like, such as Google or Microsoft verification codes. A record starting v=spf10 doesn't count either; the RFC uses it as an example of a version that doesn't match.

Google says the same thing in its own words. Its About SPF records page says "Each domain can have one SPF record," and its SPF troubleshooting guide says that with multiple records, "your email might end up in a recipient's spam folder."

What happens to your mail when SPF returns PermError?

Section 8.7 defines PermError as meaning "the domain's published records could not be correctly interpreted," a condition that "definitely requires DNS operator intervention." What happens next depends on the receiver.

The DMARC effect matters most. RFC 9989 uses the SPF identity only when there's an SPF "pass". With PermError, DMARC depends entirely on DKIM. If a service sends as your domain without aligned DKIM, its mail now fails DMARC, and with p=quarantine or p=reject it may be junked or refused. Our guide to why DMARC fails covers the knock-on symptoms.

The error is easy to miss because nothing breaks on the day it happens. Mail from services with aligned DKIM keeps passing DMARC. The damage shows up later, at a receiver that rejects on PermError, or for a sender that only had SPF.

It isn't rare even on large sites. In our scan of the Tranco top 1,000 domains in October 2026, 4 domains published more than one SPF record.

Why do domains end up with two SPF records?

Nearly every case starts with a setup screen telling someone to "add this TXT record".

• A new sending service. A newsletter, CRM, help desk or invoicing tool shows a full record such as v=spf1 include:service.example -all. Whoever sets it up adds it as a new record, next to the existing one.
• An email migration. Moving from one provider to another, a domain ends up with the old provider's record and the new one.
• Registrar defaults. Some registrars and hosts publish a default SPF record for their own mail or web hosting. When you set up Microsoft 365 or Google Workspace, you add a second one. Our GoDaddy DNS guide shows where to look for this.
• A misguided split. Someone hits the 255-character limit for a single string and creates a second TXT record for the overflow. That's two records, not one long one. See the section on long records below.
• Copying the old SPF type. RFC 7208 section 3.1 says SPF must be published as TXT "only." Old setups sometimes have a type 99 SPF record as well. Receivers following RFC 7208 query TXT only, so the type 99 record doesn't cause PermError, but it's a sign the zone hasn't been cleaned up.

How do you merge two SPF records into one?

Follow these steps in your DNS host's editor.

1. List what you have. Run the SPF Checker or look at all TXT records at your root domain (@). Copy every record that starts with v=spf1.
2. Collect the terms. From each record, write down every include:, ip4:, ip6:, a, mx and exists: term. Ignore the v=spf1 at the start and the all term at the end.
3. Remove what you don't need. Drop exact duplicates. Drop services you no longer use, and providers you've migrated away from. Every include, a and mx costs a DNS lookup, and SPF allows at most 10 per check.
4. Choose one ending. Use one all term, at the very end. Pick ~all or -all; our guide on softfail vs hardfail explains the trade-off. If one record had -all and the other ~all, don't keep both.
5. Build the merged record. Start with v=spf1, add your terms separated by single spaces, and end with your all. The SPF Record Generator builds it for you.
6. Edit, don't add. Edit the existing record and replace its value with the merged one. Then delete the other v=spf1 record. Don't leave both while you "test".
7. Check it. Run the SPF Checker again after the change has propagated. It should show one record, a valid syntax and 10 lookups or fewer.
8. Send a test. Send from each service to an outside mailbox and check the headers in the Email Header Analyzer. Look for spf=pass.

A merge example

Here's a typical before and after for a business on Microsoft 365 that added a marketing tool:

The merged record keeps both include terms and one ending. mail.marketing.example is a placeholder; use the exact include your provider documents. Our SPF records by provider pages list the includes for common services, such as Microsoft 365 and Google Workspace.

Watch the lookup limit while merging

Merging can push you over 10 DNS lookups, because each include counts, plus every lookup inside it. If the checker reports more than 10 after merging, you've swapped one PermError for another. Our guide to too many DNS lookups covers the fixes, such as moving bulk senders to a subdomain.

What about records that are too long?

A single string inside a TXT record can hold at most 255 characters. That's a DNS limit, not an SPF one. The fix is several strings in one TXT record, never two records.

RFC 7208, section 3.3 says a record with multiple strings "MUST be treated as if those strings are concatenated together without adding spaces":

example.com.  TXT  "v=spf1 include:spf.protection.outlook.com include:mail.marketing.example "
                   "include:helpdesk.example -all"

Note the space at the end of the first string. Without it, the two terms would join into one invalid term. Many DNS hosts split long values for you; check how yours displays them before adding quotes by hand.

Section 3.4 also asks you to keep the whole record small enough that a DNS answer fits in 512 octets. If a merged record is that long, you probably have senders that belong on a subdomain.

Can subdomains and included domains cause the same error?

Subdomains are separate. SPF is checked against the exact domain in the envelope sender (MAIL FROM). news.example.com can have its own single SPF record without clashing with example.com. It doesn't inherit the parent's record.

Included domains can break you too. Section 5.2 says that if an include target returns PermError, the include returns PermError. So if a vendor publishes two SPF records on the domain you include, your check fails as well. Our SPF Checker follows includes and reports an included domain that has more than one record. If that happens, tell the vendor, and remove the include until they've fixed it if your mail is affected.

Next steps

• Run the SPF Checker on every domain you own, including the ones you don't send from. Parked domains should have exactly one record: v=spf1 -all.
• Merge any duplicates using the steps above, and keep a list of which service each include belongs to.
• Make sure every service also signs with aligned DKIM, so a future SPF mistake doesn't turn into DMARC failures. Check with the DMARC Checker and our DKIM records by provider pages.
• Catch the next accidental duplicate early. iBlockSpam's domain monitoring alerts you when your SPF record changes: weekly on Protect, daily on Protect Plus.

Browse our other SPF, DKIM and DMARC guides.