DMARC Record Checker

What DMARC adds to SPF and DKIM

SPF and DKIM answer technical questions: is this server allowed, and was the message altered. Neither tells the receiver what to do when a check fails. DMARC is exactly that instruction, and it adds one more requirement: the authenticated domain has to match the address the recipient sees in the From field.

The second reason to deploy it is reporting. Once a day mailbox providers send a summary: how much mail claimed to be from you, from which addresses, and how much passed authentication. Without that data you know nothing about spoofing, or about your own campaigns quietly failing authentication.

Three stages of rollout

1. p=none — monitoring. Delivery is unchanged, reports accumulate. Usually kept for two to four weeks.
2. p=quarantine — failing mail goes to spam. Enable once no legitimate senders show up as failing in the reports.
3. p=reject — failing mail is rejected outright. The end goal, and what Gmail and Yahoo expect from bulk senders.

Example record

v=DMARC1; p=quarantine; sp=quarantine; pct=100; rua=mailto:dmarc@example.com; adkim=r; aspf=r

Published as a TXT record at _dmarc.example.com. The v tag must come first and p second; the rest can be in any order. A record on the organisational domain also covers subdomains that have none of their own.

What usually goes wrong

• The record sits at p=none for years. Nobody reads the reports, nothing is protected, but the compliance box is ticked.
• rua on an external domain without authorisation. Reports never arrive, and nothing indicates why, just silence.
• p=reject with active subdomains. Mail from subdomains starts being rejected if they have no authentication of their own.
• sp=none under a strict p. Subdomains stay wide open to spoofing.

How to read the reports

Aggregate reports arrive once a day as a compressed XML file. Reading them by eye is unpleasant, but the structure is simple: for every IP address that sent mail claiming to be your domain, you get a message count and the SPF and DKIM outcomes.

The point of the first few weeks is inventory, not catching attackers. Almost always two or three legitimate senders turn up that everyone had forgotten: an invoicing service, the contact form on the website, the finance team's CRM. Those need to pass authentication before you tighten anything.

Forensic reports (ruf=) contain fragments of the messages themselves and are therefore sent by almost nobody, and providers will not forward personal data. Do not build a process around them.

The order to tighten the policy

Jumping straight to p=reject is the single most common way to lose mail. The sequence that works takes a couple of months:

1. p=none with a reporting address. Nothing is blocked; you are simply watching who sends as you.
2. Two or three weeks bringing every one of your own senders to dkim=pass with aligned domains.
3. p=quarantine with pct=10, then gradually up to 100. Suspect mail lands in spam rather than disappearing.
4. p=reject. By this point the reports should show no legitimate source still failing.

About domain alignment

DMARC checks not only that a signature is valid but that the domain in it matches the domain in the visible From field. Hence the classic situation where SPF and DKIM both technically pass and DMARC still fails: the sending service signs with its own domain while From shows yours.

The fix is to connect your own domain inside the sending service: a dedicated DKIM selector on your domain and, where SPF is involved, your own subdomain for the envelope. The default adkim/aspf mode is relaxed and accepts a match on the organisational domain: news.example.com satisfies example.com. Strict mode s demands an exact match and is rarely what you want.

Why DMARC fails when SPF and DKIM both pass

The most common complaint runs like this: both checks are green on their own and DMARC is red. The answer is alignment, because DMARC looks not only at the result of a check but at whose domain took part in it.

A sending service signs with its own domain by default and uses its own envelope. SPF technically passes: the envelope belongs to the service and it authorised itself. DKIM passes too: the signature is valid. But the From field shows your domain, matching neither, and DMARC counts that combination as a failure.

The fix is connecting your own domain inside the service: a dedicated DKIM selector on your domain and a subdomain for the envelope. After that at least one of the checks aligns with From, which is all DMARC asks for: one is enough, it does not need both.

How long to wait between steps

A full run to p=reject takes roughly two months, and there is no point compressing it: the time goes not into the technical work but into accumulating enough reporting history to cover every sender. Infrequent sources such as annual notices and seasonal campaigns, otherwise never appear in the sample and break at the worst possible moment.