DMARC record has a syntax error
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
The record at _dmarc cannot be read as a valid DMARC policy, so receivers discard it and treat your domain as having no policy.
Why it matters
The record exists, so everything looks configured, but no protection is in force and no reports are generated.
When the check passes, your report says: “The DMARC record parses as a valid policy”.
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
Rebuild the record so it parses, keeping v=DMARC1 first and p second.
An invalid record is discarded, leaving your domain with no DMARC policy at all.
Rebuild the record in the generator, which will not emit anything that fails this check.
Publish it as a single TXT record at
_dmarc.‹domain›.
How to confirm it worked
dig +short TXT _dmarc.‹domain› — the record must parse in the DMARC checker
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
Parsing _dmarc.‹domain› failed: ‹parse error›. RFC 9989 §4.7 requires v=DMARC1 to be the first tag and p to be the second, and defines the permitted values for each tag; a record failing either constraint is ignored. Frequent causes are a missing p tag, a p value other than none/quarantine/reject, and a semicolon-separated list broken across records.
Standards and references
Test this on your domain
Run the check that produces this finding, on its own, against any domain.