← Frankys Web GitHub Contact

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 to p=quarantine and finally p=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 rua domain is outside the checked domain, it needs a TXT record <your-domain>._report._dmarc.<report-domain> with the content v=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=s or aspf=s requires an exact domain match and often breaks with subdomains of service providers. Stay on relaxed (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.