DMARC Checker Guide: Read a DMARC Record's Policy

SPF and DKIM each answer part of the email authentication question, but neither, on its own, tells a receiving system what to do when authentication fails. SPF says which servers may send for a domain. DKIM says whether a message was signed by the domain's key holder. A message can fail both and still arrive, because the receiving system has no instruction from the domain owner about failure. DMARC, which stands for Domain-based Message Authentication, Reporting, and Conformance, supplies that instruction. It is a DNS record published by the domain owner that says: when mail claiming to be from me fails authentication, do this, and send me reports about it. That policy statement is what turns authentication from a set of signals into an enforceable rule.

The DMARC Checker tool pastes a DMARC record and checks its version, policy, and reporting tags. It works on pasted text, not on a live DNS lookup, so it validates the record you give it, not the record the world sees. That boundary matters, because a well-formed record sitting in a draft protects nobody; only a published record in the domain's DNS has effect, and a published record with a typo has the wrong effect. The checker is the format gate before publication, and the live DNS confirmation after publication is a separate step that must not be skipped.

A DMARC record is a single DNS TXT record at the name _dmarc followed by the domain, and its value is a list of tags separated by semicolons. The v tag must read DMARC1, and it must come first. The p tag states the policy for the domain itself, and it has three values: none, which means take no special action but send reports, quarantine, which means treat failing mail as suspicious, and reject, which means refuse failing mail outright. The sp tag, when present, states the policy for subdomains, and if it is absent, subdomains inherit the p policy. The rua tag gives the address for aggregate reports, which summarise authentication results in bulk, and the ruf tag gives the address for forensic reports about individual failures, though forensic reports are rarely sent by large receivers for privacy reasons. The pct tag states the percentage of failing mail to which the policy applies, from 0 to 100, which allows a phased rollout. The adkim and aspf tags state how strictly DKIM and SPF alignment are judged, relaxed or strict. Reading a record means reading each of these tags, because each one changes what receivers do.

The policy ladder deserves emphasis, because the cost of climbing it too fast is real mail lost. Starting at p=none with reporting enabled lets the domain owner see, from aggregate reports, which legitimate senders fail authentication, such as a newsletter service or a CRM tool that was never configured for the domain. Fixing those senders first, then moving to quarantine with a percentage, then to full reject, is the rollout that protects the domain without blocking its own mail. Jumping straight to p=reject on day one blocks every legitimate sender that was not yet aligned, and the damage is discovered through missing mail, which is a poor monitoring system. The pct tag makes the climb gradual: a policy of quarantine at pct=50 applies quarantine to half of failing mail, which is a way to test enforcement on a sample before committing fully.

A worked example you can follow

Take a sample record: v=DMARC1; p=none; rua=mailto:reports@example.com; pct=100. Count the tags: 4. Check each: v reads DMARC1 and comes first, which passes. P reads none, which is the monitoring value, correct for a first rollout. Rua gives a reporting address, which is present, so reports will arrive. Pct reads 100, which means the policy, such as it is, applies to 100 percent of failing mail, but since the policy is none, the practical effect is monitoring of all mail, which is exactly what a first rollout wants. The record is well-formed, and its meaning is: watch everything, block nothing, learn who sends for this domain.

Now advance the same domain to a second sample: v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:reports@example.com; pct=50. Count the tags: 5. The policy is now quarantine for the domain and its subdomains, but pct=50 means it applies to only half of failing mail. If the domain receives 1,000 failing messages in a day, then 1,000 multiplied by 50, divided by 100, is 500 messages quarantined, while the other 500 are delivered as before, giving a measurable sample of enforcement without full commitment. If no legitimate mail appears among the 500 quarantined, the next step is pct=100, which quarantines all 1,000, an increase of 500 messages under enforcement. If legitimate mail does appear, the fix is to align that sender before raising the percentage, not to raise it and hope. The percentage arithmetic turns a vague sense of caution into a counted sample.

Take a third, broken sample: p=reject; v=DMARC1; rua=mailto:reports@example.com. Count the tags: 3, but the order is wrong, because v must come first and here p comes first. A record with v in the wrong position may be ignored by receivers, which means a domain that believes it enforces reject is in fact enforcing nothing. The fix is to reorder the tags so v=DMARC1 leads, then re-check the full record and confirm 3 tags in the correct order. A second broken sample reads pct=150, which exceeds the maximum of 100 by 50, and is therefore invalid; percentages above 100 have no meaning, and the value must be corrected to a number between 0 and 100 before publication.

Mistakes to avoid

The first mistake is jumping to p=reject before reports show legitimate senders are aligned, which blocks the domain's own mail. The second mistake is publishing a record with v in the wrong position or a pct above 100, which receivers may ignore, leaving the domain unprotected while believing otherwise. The third mistake is omitting the rua reporting address, which removes the feedback loop that makes the rollout safe. The fourth mistake is treating a pasted-record pass as proof of publication. A format check validates the draft; only a live DNS check confirms the record the world sees, and the two must agree before the policy is claimed.

The DKIM Checker tool covers the DKIM half of authentication, and the SPF Checker tool covers the SPF half. For background on checking all three methods together, see Email Security in One View: SPF, DKIM and DMARC Together.

Checking the result before you publish it

Treat a clean format result as a draft approval, not a publication verdict. Before publishing, confirm the tag order with v first, confirm the policy matches the rollout stage, confirm the reporting address is monitored by someone who will read the reports, and after publishing, confirm the live record matches the draft exactly. Keep a note of the policy stage and the date it changed, because a DMARC rollout is a sequence of stages, and the note is what keeps the sequence moving forward instead of stalling at none forever. A record that is well-formed, correctly staged, reported on, and confirmed live is a policy doing real work.