DMARC record checker

Know whether spoofed mail from your domain is rejected, quarantined or merely reported, and whether reports actually arrive.

How it measures

Policy discovery follows RFC 9989: the record at _dmarc.<domain> is read first; when none exists the DNS Tree Walk (Section 4.10) queries the parent names, at most eight queries, stopping at a record marked psd=y or psd=n, and determines the Organizational Domain from the records found (Section 4.10.2).
For a subdomain the inherited record's sp tag applies (np is shown for non-existent subdomains); without sp the p tag applies. A record without a valid p tag is treated as p=none only when it carries a rua address, exactly as receivers do.
Tags are parsed per the specification: p, sp, np, pct, rua, ruf, adkim, aspf, fo, rf, ri, psd. For rua/ruf destinations outside the Organizational Domain, the <policy domain>._report._dmarc.<destination> authorization record is checked.
Outcomes are kept apart: a usable record, no record anywhere on the walk, an unusable record (multiple records, or no p and no rua), a temporary DNS failure, or a name that cannot be evaluated. Lookups stop at eight queries and six seconds.

The obsolete RFC 7489 heuristic (a short list of two-label public suffixes) is displayed for comparison only and never decides the policy.
DKIM selectors are not discoverable from DNS alone, so DKIM itself is not checked.
Report delivery and content are not verified; only the DNS side.
One resolver (Cloudflare) is used; a temporary failure is reported as such, never as a missing record.

p=none for months: Review aggregate reports, authorize legitimate senders through SPF and DKIM, then move to p=quarantine with pct=10 and raise it gradually.
No reports arriving: Add a rua= address. If it is on another domain, that domain must publish the authorization record this tool checks.