DMARC Record Not Working

A "DMARC Record Not Working" problem almost always means one thing in practice: receiving mail servers either can't find your record where they look for it, or they find it but discard it because the syntax is invalid. In both cases DMARC processing is silently skipped — the policy you think you published has no effect on your mail.

What causes "DMARC Record Not Working"?

DMARC is published as a DNS TXT record at the _dmarc subdomain of your domain (RFC 9989 §4.5). A receiver looks up _dmarc.example.com, expects exactly one valid record, and parses it. Any of the following breaks that:

• Wrong location or record type. The record must live at _dmarc.yourdomain.com, not at the root domain or dmarc.yourdomain.com (no underscore), and it must be type TXT, not CNAME or SPF. A record at the wrong host is invisible to receivers.
• Missing or misplaced v=DMARC1 tag. RFC 9989 §4.7 requires the v= tag to be first and to equal exactly DMARC1. Records that do not start with a v= tag identifying the current version of DMARC are discarded. V=DMARC1 casing of the value matters; v=dmarc1 or a leading space will be rejected by strict parsers.
• Invalid policy value. The p= tag accepts only none, quarantine, or reject (RFC 9989 §4.7). Typos like p=block, p=deny, or p=quarantined are not valid policy values and cause the record to be treated as having no usable policy.
• Duplicate DMARC records. RFC 9989: if the remaining set at _dmarc contains multiple records or no records, policy discovery terminates and DMARC processing is not applied. Two TXT records at _dmarc cancel each other out.
• Malformed report URIs. rua/ruf values must be valid URIs — in practice always mailto: since it's the only scheme every receiver is required to support (RFC 9989 §4.7). A bare email address without the mailto: prefix is not a valid URI and will be rejected.
• DNS not propagated yet, or split TXT strings. DNS changes typically propagate within minutes to a few hours based on your previous record's TTL, but can take up to 48 hours in rare cases with long-cached TTLs. Long records split across multiple character-strings must also be concatenated correctly by the DNS host.

A separate, very common case worth ruling out: the record is published and valid, but mail still fails DMARC. That is an alignment problem, not a "record not working" problem — see below.

How do I fix a DMARC record that isn't working?

1. Confirm SPF and DKIM exist first. DMARC builds on them. Google Workspace recommends having SPF and DKIM live for at least 48 hours before enabling DMARC; otherwise legitimate mail fails authentication.
2. Query the exact hostname. Run dig +short TXT _dmarc.example.com (or nslookup -type=txt _dmarc.example.com). You should get back exactly one string beginning with v=DMARC1.
3. Validate the syntax. A minimal correct record:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

• v=DMARC1 must be first.
• p= must be none, quarantine, or reject.
• Report addresses use mailto:.
• No stray quotes, semicolons, or trailing characters.
• Remove any duplicate TXT record at _dmarc — keep only one.
• Republish and wait for propagation (typically minutes to a few hours, occasionally up to 48 hours), then re-query.
• If the record is valid but mail still fails DMARC, check alignment, not the record. DMARC passes only if SPF or DKIM passes and that passing mechanism aligns with the From: header domain. SPF can show "pass" yet fail DMARC because the SPF-authenticated (Return-Path) domain doesn't match the visible From: domain — a classic forwarding and third-party-sender issue. Inspect message headers (e.g. Google's Messageheader tool) and your aggregate (rua) reports to find the offending source.

Note on the old example

The previous version of this page used p=block as the "wrong" example — that part is correct (block is not a valid value). But the underlying point is broader: most "not working" cases are placement and duplicate-record problems that pass a casual eyeball check, so always query _dmarc directly rather than trusting your DNS provider's UI.