DMARC Monitor
DMARC tells receiving mail servers what to do with email that fails SPF or DKIM alignment, and where to send aggregate reports. The most common failure mode isn't a missing record — it's a record stuck on p=none (monitor only) for years, which provides almost no protection. This check looks for that and other common misconfigurations.
What we check
We do a live TXT lookup at _dmarc.<domain> and parse the response into the standard DMARC tags (v, p, sp, pct, rua, ruf, aspf, adkim). The record must start with v=DMARC1 and have a policy tag.
Why it matters
A domain without a DMARC policy can be spoofed — receiving servers have no instruction on how to handle messages that claim to be from your domain but fail authentication. With p=none the situation is barely better: receivers report failures back to you but don't reject anything. p=quarantine and p=reject are the policies that actually protect the domain.
Status outcomes
A single valid DMARC record exists with p=quarantine or p=reject, the policy applies to 100% of messages, and an aggregate report URI (rua) is configured.
The record is otherwise valid but pct is below 100 (the policy is only enforced for some messages) or no rua reporting URI is configured.
No DMARC record exists, multiple records are published (RFC 7489 allows only one), the p tag is missing, the policy is none, or any tag (p, sp, pct, aspf, adkim) has an invalid value.
How to fix
Start with v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain to collect aggregate reports without affecting delivery. Use the reports to identify legitimate senders that aren't yet aligned (especially marketing platforms, transactional email services, support tools), align them, then ratchet the policy up through p=quarantine to p=reject.
If your monitor is showing p=none after months of operation, that's the signal to start ratcheting. The "monitor mode" is supposed to be temporary.