DMARC Checker

Three stages of a typical policy for example.com, all published at _dmarc.example.com, and what the checker shows for each.

Monitoring only

v=DMARC1; p=none; rua=mailto:[email protected]

Policy None (badge: Monitor), coverage 100%, alignment Relaxed, reporting On. Six checks pass and two need review: the policy takes no action, and there is no sp= tag. This is the normal starting point.

Partial enforcement

v=DMARC1; p=quarantine; pct=25; sp=quarantine; rua=mailto:[email protected]

Policy Quarantine (badge: Partial) with coverage 25%: a quarter of failing mail is quarantined, and the other 75% falls back to p=none. The policy and coverage checks ask for review until you reach p=reject and pct=100.

Full enforcement

v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:[email protected]; ruf=mailto:[email protected]

Policy Reject (badge: Enforcing), coverage 100%, alignment Strict, and all eight checks pass. The Reporting destinations card lists both addresses, and the ladder footer reads "rua + ruf".

• Policy and the enforcement ladder — the p= value, highlighted on a None / Quarantine / Reject scale.
• Coverage — the pct= value: the share of failing mail the policy applies to. It is 100% when the tag is absent, and values outside 0–100 are clamped. Below 100%, the coverage check explains what happens to the remaining mail: under p=reject it is quarantined instead, under p=quarantine it gets p=none (RFC 7489, section 6.6.4).
• Alignment — Relaxed when both adkim and aspf are r (the default when the tags are missing), Strict when both are s, and Mixed otherwise.
• Reporting — On when at least one rua address is present. The Reporting destinations card lists every rua and ruf address with the mailto: prefix and any size limit such as !10m removed.
• Validation — eight checks: record found, version tag, policy, coverage, aggregate reporting, alignment mode, subdomain policy, and a single DMARC record. p=none, p=quarantine, coverage below 100%, a missing rua and a missing sp are flagged for review; a missing p= tag or more than one DMARC record fails.
• Record tags and Raw TXT record — each tag with its name, with v and p marked Required, and the record as a zone-file line.

1. Publish p=none with a rua address. Receivers that send aggregate reports start mailing them, usually once a day.
2. Find every sender in the reports. Each service that sends as your domain must pass SPF or DKIM with an aligned domain. Fix sender lists with the SPF lookup-limit checker and confirm each provider's signing key with the DKIM key checker.
3. Move to p=quarantine gradually. Raise pct in steps (for example 25, 50, 100) and watch the reports between steps. Failing mail outside the percentage gets the next lower policy: quarantine falls back to none, reject falls back to quarantine.
4. Finish at p=reject and set sp=. An explicit subdomain policy makes it clear how mail from names like news.example.com is treated.

Alignment in practice

For a message with From: [email protected]:

• A DKIM signature with d=mail.example.com aligns in relaxed mode (same organizational domain) but not with adkim=s.
• An envelope sender of [email protected] passes SPF alignment only in relaxed mode.
• A newsletter service that signs with d=example.net and uses its own bounce domain passes SPF and DKIM for example.net, yet fails DMARC for example.com. Ask the provider for a custom DKIM domain or custom return path.

Keep relaxed alignment unless every source signs and bounces with the exact From: domain.

The checker finds no record

DMARC must be a TXT record on the _dmarc host, such as _dmarc.example.com, not on the domain itself; in DNS panels that append the zone name, enter only _dmarc. The record must have v=DMARC1 as its first tag, or receivers ignore it. DNS errors and timeouts are reported the same way as a missing record.

A subdomain has no record

Checking mail.example.com queries only _dmarc.mail.example.com and nothing above it. Receivers that find nothing there fall back to the organizational domain's record and apply its sp= (or p=) policy, so check example.com as well.

Multiple DMARC records or no p= tag

With two v=DMARC1 records, receivers skip DMARC for the domain; merge them into one (the checker shows the first one it receives). Without a valid p= tag, receivers either ignore the record or, when a valid rua is present, treat it as p=none. Always state the policy explicitly.

Aggregate reports are not arriving

Check the address in the Reporting destinations card and the mailto: prefix in the raw record. When reports go to another domain, for example rua=mailto:[email protected] on example.com, the receiving domain must publish an authorization record at example.com._report._dmarc.example.net containing v=DMARC1. This checker does not query that name — look it up with the DNS lookup tool. Not every mailbox provider sends reports.

• It reads the published policy only. Whether your mail actually passes SPF, DKIM and alignment shows up in real message headers and aggregate reports, which this tool does not collect or parse.
• It queries the exact _dmarc name for the domain you enter, with no organizational-domain fallback. A leading www. or _dmarc. is removed, and internationalized names are converted to punycode.
• fo, ri and rf are listed but not evaluated; the "Daily XML" label on rua addresses describes the default report interval, not your ri value. Tags the tool does not recognise are shown with their raw key.
• Answers come from the DNS resolver used by the helpers.work server, so a just-published change can still show the cached value. For the full picture of how the three records interact, read SPF, DKIM and DMARC explained.