More than one DMARC record published
Updated
Fewer than 1% of the 866 domains we could check fail this. Sample: the first 1,000 domains by rank in the Majestic Million, checked on 2026-10-12. How we measured
What this check looks for
Two or more DMARC records exist at the same name. The rules tell receivers to ignore all of them, so your domain effectively has no DMARC policy.
Why it matters
You have a policy configured and none of it is in force — the worst kind of misconfiguration, because everything looks set up.
When the check passes, your report says: “Exactly one DMARC record is published”.
What it costs your score
When this check fails it removes 20 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.dmarc family ceiling of 40 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
- 20 points
- Family cap
- email-auth.dmarc · 40
- Category
- Email authentication
- Module
- Email dmarc
- Fix owned by
- dns host
- In the ruleset since
- 2026.09
How to fix it
Keep one DMARC record and delete the rest.
With more than one record, receivers apply no DMARC policy at all.
List every record with
dig +short TXT _dmarc.‹domain›and note each one'sp=,sp=,rua=andruf=values.Decide which policy and report addresses you want; merge the rua addresses into one record if both were wanted.
Publish the result as one record, and delete the other
_dmarcTXT records.If a reporting service asked you to add its own record, put its address in your record's
rua=instead — one tag can list several addresses, separated by commas. An address at another domain also needs that domain to authorise it.
How to confirm it worked
dig +short TXT _dmarc.‹domain› | grep -c v=DMARC1 — expect 1
Once the old records' TTL has passed, confirm that aggregate reports arrive at the address you kept.
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 starting v=DMARC1 were returned for _dmarc.‹domain›. RFC 9989 §4.10.1 states that if more than one record remains after filtering, the domain is treated as having no DMARC record at all.
Receivers keep only the TXT records at that name that begin with v=DMARC1, and use the result only if exactly one is left. Two records that are each valid on their own — even two that differ only in spacing or tag order — therefore produce no policy: no quarantine or reject decision for mail that spoofs the domain, and no aggregate reports either, because the rua address sits in a record nobody applied.
The second record almost always comes from an onboarding step. An email provider, a DMARC reporting service or a security tool asked for a DMARC record, one was added, and the existing record was left in place. Some DNS hosts show all the TXT values for a name as one entry, which makes the duplicate easy to miss. A TXT record at _dmarc that does not begin with v=DMARC1 is ignored rather than counted, so it does not cause this finding, but it is worth removing at the same time.
When you merge, keep the stricter policy only if your reports show every legitimate sender passing with alignment. Our DMARC generator starts at p=quarantine with a reporting address; p=none is a monitoring stage that protects nothing while it is in force.
Standards and references
Test this on your domain
Run the check that produces this finding, on its own, against any domain.