Guide

A DMARC checker reads the TXT record at _dmarc.yourdomain.com and tells you what policy receiving mail servers will apply to messages that fail SPF or DKIM.

What DMARC actually does

DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) sits on top of SPF and DKIM. It does not replace either - it tells receiving mail servers what to do when a message fails those checks, and gives the domain owner a way to receive reports about the mail claiming to come from their domain.

The record lives at a fixed location: a TXT record on _dmarc.example.com. A minimal record looks like this:

v=DMARC1 - the version tag, always exactly this value
p=none - the policy applied to the root domain
rua=mailto:dmarc@example.com - where aggregate reports get sent

The policy (p=) tag

The policy tag is the part of the record that changes what happens to spoofed mail. It takes one of three values, and the difference between them is the entire point of deploying DMARC.

Policy	Effect on failing mail	Typical use
p=none	No effect on delivery - mail flows as it would without DMARC	Monitoring phase, before enforcement
p=quarantine	Receivers should route failing mail to spam/junk	Mid-rollout, once reports look clean
p=reject	Receivers should refuse the message outright	Full enforcement, after a monitoring period

Reporting: rua and ruf

DMARC reporting is what makes it possible to deploy a strict policy without flying blind. Two separate report types exist, and most domains only need one of them.

rua (aggregate reports) - daily XML summaries from each receiving mail provider: which servers sent mail as your domain, and whether they passed SPF/DKIM alignment. This is the report that actually matters for day-to-day monitoring.
ruf (forensic reports) - per-message failure reports containing headers and sometimes message content. Support has dropped sharply across major providers over privacy concerns, so an absent ruf tag is normal and not a problem to fix.
A domain with p=quarantine or p=reject but no rua address is flying blind: legitimate mail can start failing with no visibility into why.

Alignment: aspf and adkim

A message passes DMARC if it passes SPF or DKIM and the domain in that check aligns with the visible From: address. Alignment mode controls how strict that match has to be.

r (relaxed, the default) - a subdomain match counts. mail.example.com aligns with example.com.
s (strict) - the domains must match exactly. mail.example.com does not align with example.com under adkim=s.
Set with aspf=s and adkim=s independently; most domains run relaxed alignment because it tolerates subdomain-based sending infrastructure without extra configuration.

Reading the checker output

This checker groups its findings under a DMARC category, alongside SPF, DKIM, MX and blacklist checks run in the same pass. Each result carries a status:

DMARC Record Found (or missing) - whether _dmarc.example.com resolves to a TXT record starting with v=DMARC1
DMARC Version - flags any v= value other than DMARC1
DMARC Syntax - confirms the tag=value pairs parse correctly
DMARC Policy - reports the p= value found and rates none as a warning, quarantine and reject as passing
DMARC Reporting - warns when neither rua nor ruf is present
DMARC Alignment - reports the effective aspf/adkim mode
DMARC Percentage - flags a pct= value under 100, meaning the policy only applies to a fraction of mail

A staged rollout, worked example

Deploying DMARC by jumping straight to p=reject is the most common way to break legitimate mail. The standard path moves through three records over time, watching aggregate reports at each stage:

Stage 1 - v=DMARC1; p=none; rua=mailto:dmarc@example.com (observe only, fix any legitimate sender that shows up failing)
Stage 2 - v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc@example.com (partial enforcement, half of failing mail affected)
Stage 3 - v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:dmarc-forensic@example.com (full enforcement)

FAQ

What happens if a domain has no DMARC record at all?

Receiving mail servers fall back to their own default handling of SPF/DKIM failures, which varies by provider and gives the domain owner no visibility into spoofing attempts. A domain that sends mail from a fixed set of servers gets no downside from publishing at least a p=none record with rua reporting.

Can a subdomain have a different DMARC policy than the parent domain?

Yes. A record published at _dmarc.mail.example.com overrides the organizational policy at _dmarc.example.com for that subdomain. Without a subdomain-specific record, the sp= tag (or the main p= tag if sp= is absent) on the organizational record applies.

Does DMARC stop spam?

No. DMARC only affects mail that fails SPF or DKIM alignment while claiming to be from your domain. Spam sent from unrelated domains, or mail that legitimately passes both checks, is untouched by DMARC entirely - that is a spam filter's job, not DMARC's.

Why does my aggregate report show a legitimate service failing DMARC?

This usually means the service sends mail through its own infrastructure using your domain in the From: address but is not covered by your SPF record or does not sign with DKIM using an aligned domain. Marketing platforms, helpdesk tools and CRM systems are the most common culprits - each needs its own SPF include or DKIM setup.

Is there a minimum time to wait between DMARC rollout stages?

RFC 7489 sets no fixed interval. In practice, a week or two per stage is enough to capture a full reporting cycle from major mailbox providers and catch any legitimate sender still failing before moving pct= higher or tightening the policy.

What is the difference between the pct tag and the policy tag?

p= sets which action applies (none, quarantine, or reject); pct= sets what fraction of failing mail that action applies to, as a percentage from 1 to 100. pct=100 (or an absent pct tag, since 100 is the default) applies the policy to all failing mail; a lower value staggers enforcement during rollout.

Active Tools

DMARC Checker