auth.dmarc.multiple_records
Multiple DMARC Records
What we check
We count the TXT records at _dmarc.<domain> that begin with v=DMARC1. RFC 7489 §6.6.3 requires receivers to stop DMARC processing when more than one exists — the effective result is no policy at all. The fix is to delete, not to add.
What this finding means
The domain publishes more than one DMARC record at _dmarc.<domain>. Receivers can't pick between them, so per the specification they discard them all and apply no DMARC policy — exactly as if none were published. Whatever the records declare (p=reject included) provides no protection.
The usual cause is two setups each adding their own _dmarc record, or an old record left behind when a new one was created.
Why it matters
- No DMARC at all. Two records mean receivers apply no policy — your domain is unprotected against spoofing even if one of the records says
p=reject. - Silently defeats enforcement. You may believe DMARC is enforcing at
reject, while receivers are ignoring it entirely because of the duplicate. - Reporting stops too. With DMARC processing halted, aggregate reports also stop, so you lose visibility.
How to fix
Keep exactly one record. Decide which policy you want and delete every other
_dmarcTXT record so a singlev=DMARC1record remains:_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"Merge intent, not records. If the two records reflect different goals (one reporting, one enforcing), combine the tags you actually want into the single surviving record.
How it's graded
Multiple DMARC records drive the Authentication category's DMARC-policy baseline to 0 — the effective policy is absent, whatever the records declare. See Grading Methodology for the full scoring model.
Evidence example
$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"
"v=DMARC1; p=none"
Two DMARC records → receivers discard all, no policy applies (RFC 7489 §6.6.3)