DMARC Checker

DMARC closes a gap that SPF and DKIM leave open. Those two check technical identities, the envelope sender and a signing domain, which an attacker can set up freely. People read the From address. DMARC says: the domain in the From address must line up with a domain that passed SPF or DKIM, and if it does not, here is what to do with the message. This page reads a domain’s policy and judges how strong it is.

Finding the record

The record lives in a TXT record at _dmarc in front of the domain. If a receiver finds nothing at the exact domain of the From address, it tries the organisational domain above it. The page does the same: it asks for _dmarc.sub.example.com and then for _dmarc.example.com, and tells you which name it used. If neither has a record, it explains that receivers have no instruction for failing mail. The first tag must be v=DMARC1; anything else is ignored by receivers, and the page reports the error.

The tags

p is the policy for the domain: none (monitor only), quarantine (treat as suspicious, usually spam folder) or reject (refuse). sp sets a different policy for subdomains. pct applies the policy to a percentage of failing mail, for gradual rollout. rua lists mailto addresses for aggregate reports and ruf for failure reports. adkim and aspf choose relaxed (r) or strict (s) alignment. fo controls when failure reports are generated. The page explains each tag found, checks its format and flags unknown tags that receivers will ignore.

How the grade is calculated

The score is a rough guide, not a standard. A reject policy starts at 75 points, quarantine at 60, none at 20. A valid report address adds 10; a stated or inherited subdomain policy adds 5; strict alignment on DKIM or SPF adds 3 each; a pct under 100 subtracts a point for each ten percentage points missing. The grade is Strong from 80, Good from 55, Basic (monitoring only) from 25 and Weak below, and Invalid when the record has an error such as a bad p value. A policy of none can never reach Good, because monitoring protects no one yet.

The usual path

Start at p=none with a rua address and read the reports for a few weeks. They show every system that sends as your domain, such as the newsletter service, CRM and invoicing tool. Fix SPF and DKIM for each legitimate sender. Move to p=quarantine, perhaps with pct=25 rising to 100, then to p=reject. Review reports continuously, because new services appear. Skipping the monitoring phase is the usual cause of legitimate mail being blocked.

A worked example

Press Sample to check google.com. The page finds the record at _dmarc.google.com: v=DMARC1; p=reject; rua=mailto:[email protected]. The tags table lists version DMARC1, policy reject and the report address. The score is 75 for reject, plus 5 for the inherited subdomain policy, plus 10 for the report address: 90 out of 100, grade Strong. Findings read that reject is the strongest policy and that aggregate reports are requested. Policies change; the scoring does not.

Limits

The check reads the policy, not the results. It cannot tell whether reports are arriving, whether your mail passes alignment, or whether an external report address has authorised the domain to receive reports. The score is not a measure of inbox delivery. For the other half of the story see the SPF Record Checker and DKIM Record Checker.

Related tools

• SPF Record Checker tests the sender list DMARC relies on.
• DKIM Record Checker inspects the signing key.
• BIMI Checker needs an enforced DMARC policy before logos can show.
• Email Spoofing Test combines these checks into one score.