← Frankys Web GitHub Contact
Frankys Web Mailtools

Check and understand email configurations

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 7489 section 6.3 (v, p, sp, np, rua, ruf, fo, rf, ri, adkim, aspf, pct) 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, pct=100, fo=0). 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 pct below 100 in steady operation, 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 7489. The tag list and syntax are in section 6.3, the interplay with the organisational domain and the Public Suffix List in section 3.2, external report authorisation in section 7.1, the alignment concept in section 3.1. The np tag (policy for non-existent subdomains) and the common practice around BIMI round out the picture but are not part of the original RFC.

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.
What does the pct tag do?
pct sets which percentage of failing mail the policy is applied to, the rest is handled one step more leniently. pct is only meant as a short ramp while tightening; in steady operation it belongs at 100 or removed entirely.