auth.spf.multiple_records

Multiple SPF Records

What we check

We count the TXT records at the domain apex that begin with v=spf1. RFC 7208 §3.2 requires exactly one. More than one causes SPF evaluation to fail outright (PermError) at every receiver, regardless of what the records contain.

What this finding means

The domain publishes more than one v=spf1 record. Receivers cannot choose between them, so the specification requires them to treat the result as a permanent error — the same outcome as an invalid record. The fix is to merge, not to add.

Why it matters

• SPF fails for everyone. Two records mean no working SPF at all — every receiver returns PermError, and your legitimate mail loses its SPF pass.
• A common accident. Each provider's setup wizard ("add this SPF record") tends to publish its own v=spf1 record. Two onboarding flows leave you with two records and broken SPF.
• DMARC impact. With SPF in PermError, DMARC alignment via SPF is lost. If DKIM isn't aligned too, DMARC fails.

How to fix

1. Merge every mechanism into a single record. Combine the include:, ip4:, and ip6: terms from all records into one, with a single all at the end:

   example.com.  IN  TXT  "v=spf1 include:_spf.provider-a.example include:_spf.provider-b.example -all"
   

2. Delete the extra records so exactly one v=spf1 TXT record remains at the apex.

3. Re-check the lookup count after merging — combining includes can push you toward the 10-lookup limit.

How it's graded

Multiple SPF records carry a 10-point deduction in the Authentication category. See Grading Methodology for the full scoring model.

Evidence example

$ dig +short TXT example.com
"v=spf1 include:_spf.provider-a.example -all"
"v=spf1 include:_spf.provider-b.example ~all"

Two v=spf1 records → receivers return permerror (RFC 7208 §3.2)

References

• RFC 7208 — Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1