Multiple SPF Records on One Domain: How to Find Them by Auditing Your Zone File

If your domain publishes two SPF records, SPF does not pick one: it fails with a permerror. RFC 7208, section 4.5, says that when the record set includes more than one SPF record, check_host() produces the permerror result. We read that section for this post on 9 November 2026. A permerror is a permanent error, so a receiver that checks SPF cannot reach a pass for your domain until the duplicate is gone.

It happens in the most ordinary way. You start with one record for your mailbox provider. A year later you add a marketing platform, it tells you to "add this TXT record", and you do, next to the old one.

The free DNS zone file email audit finds this in seconds. Paste the zone, and it lists every mail-related record and flags the problems, with line numbers. This post shows what it looks for and how to fix each finding.

Audit a zone file →

What the audit reads

It parses the zone file format from RFC 1035, section 5.1: comments after a semicolon, records wrapped across lines in brackets, $ORIGIN, @ for the origin, and a blank owner name meaning the previous owner. Then it checks the mail records at your domain:

Record	What the audit looks for	Result
MX	Any MX record at the domain	Listed. If none, a note that only receiving mail needs MX.
SPF	TXT values starting with exactly v=spf1	One is fine; more than one is a problem.
DMARC	TXT values at _dmarc starting with v=DMARC1	One is fine; none or several is flagged to check.
DKIM	TXT records under ._domainkey	Each key is measured; a key under 1024 bits is a problem.
Long strings	Any TXT string over 255 octets	A problem: split it into shorter strings.

You get a table sorted with problems first, a second table of every record it read, and a CSV to download. The first sample in the tool is built to show a duplicate SPF record and a short DKIM key, so you can see what a failing audit looks like.

Finding duplicate SPF records by hand

1. Open the zone as text, or look up the TXT records at the root of the domain. How to look up a domain's TXT records shows how.
2. Pick out the values that begin with v=spf1. Verification tokens for other services, such as a site-ownership code, are not SPF and can stay.
3. If you count two or more, you have the problem.

The audit does step 2 for you and reports the line number of each, which matters in a long zone where the two records are screens apart.

Merging them

Each SPF record is a list of mechanisms that say who may send, ending in an all that says what to do with everyone else. To merge two, put the mechanisms together in one record and keep a single all:

Before:
@  TXT  "v=spf1 include:_spf.provider-a.example ~all"
@  TXT  "v=spf1 include:mail.provider-b.example ~all"

After:
@  TXT  "v=spf1 include:_spf.provider-a.example include:mail.provider-b.example ~all"

The example host names above are placeholders; use the ones your services give you. Delete the old records, publish the merged one, and recheck. How to add several email services to one SPF record covers this in more detail, and the free SPF record merger does the combining for you.

The catch: the 10-lookup limit

Merging can create a second failure. Section 4.6.4 of RFC 7208 says SPF implementations must limit the number of terms that cause DNS queries (include, a, mx, ptr, exists and the redirect modifier) to 10 during evaluation, and the result is permerror if it is exceeded. Each include can itself contain more includes, and they all count.

After merging, count the lookups with the bulk SPF lookup counter. If you are over, fixing "SPF PermError: too many DNS lookups" walks through a worked example.

The other findings, briefly

• DKIM key under 1024 bits. RFC 8301 says verifiers must not treat these signatures as valid. Replace the key. DKIM 1024 vs 2048 bit explains the sizes.
• TXT string over 255 octets. One DNS string holds at most 255 octets, so a long record has to be published as several strings. DKIM TXT record too long shows how, and the TXT splitter writes it.
• No DMARC record, or several. Check the record with the DMARC record validator. RFC 7489 says that with multiple records at the name, DMARC is not applied to the message.
• No MX. Fine for a domain that only sends. Needed if it must receive replies.

Audit every sending domain, not just the main one

Cold email and agency setups often run many domains. The same duplicate appears on each when someone applied the same instructions to all of them. Export each zone and paste them one at a time; a clean main domain tells you nothing about the others. Monitoring SPF, DKIM and DMARC across sending domains covers keeping watch as you add them.

A clean zone is not a clean list

Once the audit shows no problems, mail from your domain can authenticate. It says nothing about the recipients. Dead addresses bounce on a perfectly configured domain, and receivers measure bounces whatever your SPF says. That is a list problem, so it needs a list tool.

1. Audit the zone and fix problems.
2. Verify the list at /verify and suppress invalid rows permanently.
3. Send valid rows first, then risky rows slowly after.
4. Re-verify old lists before reuse. How often to verify an email list gives a schedule.

Try it on your own list

Upload a sample at /verify. The first 100 checks are free with a Google sign-in, no card.

Pro, $39 a month: Unlimited email verification.* Never metered, never cut off. See pricing.

*Fair use: the first 100,000 checks a month at full speed, then slower, never cut off.