DMARC Record Checker

About the DMARC Record Checker

DMARC tells receiving mail servers what to do with messages that claim to come from your domain but fail authentication: deliver them anyway (p=none), send them to spam (p=quarantine) or refuse them (p=reject). It also asks receivers to send you reports, so you can see every service that sends mail as you.

This checker follows RFC 9989 — the DMARC standard, which replaced RFC 7489. It finds the record the way receivers do (including the new DNS “tree walk” for subdomains), validates every tag, explains historic tags such as pct that RFC 9989 removed, checks that report addresses on other domains have agreed to receive your reports (RFC 9990 §4), and shows the path from monitoring to full enforcement.

Common uses

• Setting up DMARC for the first time, or meeting Gmail’s and other providers’ requirements for bulk senders.
• Moving safely from p=none to quarantine and reject.
• Finding out why you receive no DMARC reports (no rua=, or an unauthorized external address).
• Checking which policy protects a subdomain that has no record of its own.

The tags, in short

• v=DMARC1 — must come first, exactly in this case, or the whole record is ignored.
• p — policy for the domain: none, quarantine or reject. sp — for existing subdomains; np — for subdomains that do not exist.
• rua — where daily aggregate reports go (mailto: addresses). ruf and fo — failure reports about single messages.
• adkim and aspf — alignment: relaxed r (default) or strict s.
• t=y — testing: receivers apply one level less (reject → quarantine, quarantine → none). New in RFC 9989.
• psd — for public suffix operators such as registries; normal domains leave it out.
• Removed in RFC 9989: pct, rf and ri. Receivers that follow RFC 9989 ignore them; some older receivers still apply pct.

How receivers find your record

For mail from news.shop.example.com, a receiver first looks for _dmarc.news.shop.example.com. If there is none, RFC 9989 §4.10 has it walk up the DNS tree — _dmarc.shop.example.com, _dmarc.example.com, _dmarc.com — and use the record of the organizational domain, normally the shortest name with a record (a psd=n or psd=y tag can change that). The parent’s sp= applies to existing subdomains and np= to non-existent ones. RFC 7489 used the Public Suffix List instead; the checker tells you when the two methods disagree.

Reports sent to another domain

If your rua points to a reporting service on another domain, that service must publish a TXT record v=DMARC1 at yourdomain._report._dmarc.theirdomain (RFC 9990 §4) — otherwise receivers will not send it your reports. Services that accept reports for anyone use a wildcard (*._report._dmarc.theirdomain). The checker queries exactly that name for every address.

Getting to p=reject safely

RFC 9989 §5.1 describes the path: make sure every legitimate sender passes SPF or DKIM with your domain aligned; publish p=none with rua; read the reports and fix every legitimate stream that fails (§5.1.6 makes this a must before enforcing); then move to quarantine and reject. §7.4 adds a caution for domains whose users post to mailing lists: keep p=none for at least a month and p=quarantine for as long before choosing reject, because lists can break authentication.

Sources

• RFC 9989 — DMARC (obsoletes RFC 7489 and RFC 9091).
• RFC 9990 — aggregate reporting and external destination verification.
• RFC 7489 — the previous DMARC specification, still followed by some receivers.
• Public Suffix List — used for the RFC 7489 comparison.

Limitations

• The checker shows what the policy asks for. Receivers decide for themselves: RFC 9989 §7.4 even tells them not to reject on a p=reject policy alone without other evidence.
• Whether your mail actually passes DMARC depends on SPF and DKIM alignment for each message; check those with the SPF and DKIM checkers, and read your aggregate reports.
• The RFC 7489 comparison uses an extract of the Public Suffix List that covers most, but not all, country-code domains; for others it is skipped.
• DNS answers can be cached for up to the record’s TTL, so a change you just made may not show yet.

Privacy

The domain is looked up from your browser through Cloudflare’s DNS-over-HTTPS resolver (Google’s as a fallback), together with its parent domains and the authorization records of external report addresses. MySmartCoPilot’s servers are not involved and store nothing.