DMARC Analyzer
Read the DMARC record and assess policy, alignment and reporting addresses.
DMARC (Domain-based Message Authentication, Reporting and Conformance) builds on SPF and
DKIM and states what a receiver should do with mail that passes neither check in the name
of the visible sender domain. The record is a TXT entry at
_dmarc.<domain>. DMARC closes the gap that SPF and DKIM leave open: only
DMARC brings in the From address shown in the mail client and gives the domain owner
reports about who is sending in their name.
What this tool checks
It reads the record, checks the syntax of every tag per RFC 9989 section 4.7
(v, p, sp, np, rua,
ruf, fo, rf, ri, adkim,
aspf) and explains in plain words what each effective
setting does, including the defaults that apply even without being stated (such as
adkim=r, aspf=r, fo=0). If a pct is
still present in the record, it is reported as what it has been since RFC 9989: without
effect. If a
subdomain has no record of its own, the tool resolves the organisational domain via the
Public Suffix List and shows that sp applies there. If rua or
ruf point to a foreign domain, it also checks whether that domain authorises
reception through a <domain>._report._dmarc.<foreign> record.
Reading the result
Green stands for a syntactically clean record with an enforced policy
(p=quarantine or p=reject) and at least one valid
rua address. p=none is monitoring only, without enforcement: a
sensible starting point but not a target state, and it is flagged as a note. Warnings
appear for a missing rua address (without it you never learn who sends in your
name), for invalid URI formats and for an external report address without an
authorisation record. An error stands for a missing
v=DMARC1 start, a duplicate tag or a second record.
Background
The reference is RFC 9989, which superseded RFC 7489 in 2026. The tag list is in
section 4.7, the formal syntax in section 4.8, the alignment concept in section 4.4, and
finding the applicable policy through the tree walk in section 4.10. Two changes from
RFC 7489 matter in practice: np (policy for non-existent subdomains) is now
part of the standard, and pct was removed outright.
Common problems and how to fix them
- No DMARC record. Start with a monitoring record:
v=DMARC1; p=none; rua=mailto:dmarc@your-domain.example. Collect reports for a few weeks, map every legitimate sending path cleanly in SPF and DKIM, then move up top=quarantineand finallyp=reject. - Stuck at
p=none. Monitoring alone prevents no spoofing. Once the aggregate reports show only known, correctly authenticated sources, tighten the policy. - External reports do not arrive. If the
ruadomain is outside the checked domain, it needs a TXT record<your-domain>._report._dmarc.<report-domain>with the contentv=DMARC1. Without it, many senders discard the reports silently. - Legitimate mail is filed away or rejected after tightening. Almost
always a sending path lacks either SPF alignment or a DKIM signature with a matching
d=domain. Identify the affected service in the reports and set up DKIM signing for your own domain there. - Strict alignment without a reason.
adkim=soraspf=srequires an exact domain match and often breaks with subdomains of service providers. Stay onrelaxed(the default) unless you have a concrete need.
Common questions
- What do p=none, p=quarantine, p=reject mean?
- The enforcement level: none = observe only and collect reports, quarantine = put unauthenticated mail into the spam folder, reject = refuse it already during the SMTP dialogue. The recommended path is step by step from none through quarantine to reject, each time only after evaluating the reports.
- What exactly does p=none mean, is that enough protection?
- p=none changes nothing about delivery for the receiver, it only activates reporting. As spoofing protection it is not enough: only p=quarantine or p=reject makes sure that forged mail with your domain in the From is actually filtered out or rejected.
- Why do I see a record even though my subdomain has none?
- DMARC falls back to the organisational domain for subdomains without their own record. The sp tag (subdomain policy) then applies there, or p as a fallback. You set a dedicated subdomain policy on purpose through sp in the record of the main domain.
- What is the _report._dmarc record for?
- If rua or ruf point to a foreign domain, that domain must allow reception: through a TXT record <your-domain>._report._dmarc.<foreign-domain> with the content v=DMARC1. Without it, the reports are not delivered by many senders.
- What is DMARC alignment?
- DMARC only counts as passed if a passing SPF or DKIM check matches the visible From domain. With relaxed (the default) the same organisational domain is enough, with strict it must match exactly. This is exactly where SPF-only setups fail after a forward.
- Do I need both SPF and DKIM for DMARC?
- Technically one of the two aligned checks is enough. In practice both should be in place: SPF does not survive forwarding, DKIM does; only together does DMARC stay stable across mailing lists and forwarders.
- My record contains pct, what does that mean today?
- Nothing any more. RFC 9989 removed the tag from DMARC, and receivers must ignore unknown tags. It used to limit the policy to a share of the mail; today the policy applies to every message regardless. The tag does no harm, but it belongs out of the record because it suggests a state that no longer exists.