More than one SPF record published
What this check looks for
Two or more SPF records exist for your domain. The rules say a receiver must treat this as an error, so in practice none of them is applied and your SPF is effectively broken.
Why it matters
A permanent error means SPF neither passes nor fails cleanly — legitimate mail loses one of its two paths to a DMARC pass, and the second record you added is doing nothing.
When the check passes, your report says: “Exactly one SPF record is published”.
What it costs your score
When this check fails it removes 25 points from your Email authentication score, before the status, confidence and repeat multipliers are applied. Email authentication carries a weight of 15 in the overall score.
It shares the email-auth.spf family ceiling of 35 points: however many findings that family produces, together they cannot remove more than that from Email authentication. One underlying problem showing up in several places is still one problem.
- Severity
- high
- Default confidence
- confirmed
- Status when triggered
- fail
- Deduction
- 25 points
- Family cap
- email-auth.spf · 35
- Category
- Email authentication
- Module
- Email spf
- Fix owned by
- dns host
- In the ruleset since
- 2026.09
How to fix it
Merge every SPF record into one TXT record and delete the others.
Receivers return permerror while more than one record exists, so neither record protects you.
Collect the mechanisms from all ‹record count› records.
Merge them into a single
v=spf1 ...record, keeping oneallmechanism at the end.Check the merged record stays within 10 DNS lookups.
Publish the merged record, then delete the remaining SPF TXT records.
How to confirm it worked
dig +short TXT ‹domain› | grep -c v=spf1 — expect 1
Use "Test again" once the extra records are removed.
A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.
Technical detail
‹record count› TXT records beginning v=spf1 were returned for ‹domain›. RFC 7208 §4.5 requires a check_host() evaluation that finds more than one SPF record to return permerror. This almost always happens when a second mail provider is onboarded and adds its own record instead of merging into the existing one.
Standards and references
Test this on your domain
Run the check that produces this finding, on its own, against any domain.
Other email spf checks
- SPF authorises the whole internet through an address range
- SPF record lists the same sender twice
- SPF include chain contains a loop
- SPF include target has no SPF record
- SPF is close to the 10 DNS lookup limit
- SPF record has no all mechanism
- No SPF record published
- SPF authorises a very large block of addresses
- SPF ends in +all — anyone may send as your domain
- SPF uses the deprecated ptr mechanism
- SPF ends in ?all (neutral)
- SPF has both redirect= and an all mechanism