DMARC (RFC 7489) ties SPF and DKIM to the address people actually see in the From line. It tells receiving servers what to do when a message claiming to be from your domain fails authentication, and it asks them to send you reports about every source using your domain.
Since February 2024 Google and Yahoo require a DMARC record for anyone sending more than 5,000 messages a day to their users, and Microsoft applied similar rules to Outlook.com in May 2025. A missing record is now a reason for bulk mail to be rejected.
What the checker does
- Looks up the TXT record at
_dmarc.yourdomain.com. - If none exists and you entered a subdomain, falls back to the organisational domain and shows which policy applies.
- Validates syntax and flags multiple records.
- Grades the policy (
p=), the percentage it applies to (pct=) and whether reporting (rua=) is configured. - Shows the subdomain policy (
sp=) and alignment modes (adkim=,aspf=). - Lists every tag in a table with its value and meaning.
How DMARC decides pass or fail
A message passes DMARC when at least one of these is true:
- SPF passes and aligns: the Return-Path domain matches the From domain.
- DKIM passes and aligns: the DKIM
d=domain matches the From domain.
Alignment is relaxed by default, which means the organisational domains must match. bounce.example.com aligns with example.com under relaxed mode. Strict mode (adkim=s or aspf=s) requires an exact match.
Only one of the two needs to align. In practice DKIM is the more reliable path, because SPF breaks when mail is forwarded while a DKIM signature usually survives.
How we grade your policy
| Setting | Grade | Why |
|---|---|---|
p=reject, pct=100, rua set |
Strong | Spoofed mail is refused and you have visibility |
p=quarantine, pct=100, rua set |
Good | Failing mail goes to spam; one step from full enforcement |
p=quarantine or reject with pct below 100 |
Partial | Only part of failing mail is acted on |
p=none with rua |
Monitoring | Meets the bulk sender minimum, no protection yet |
p=none without rua |
Weak | No protection and no data to improve with |
| No record, or multiple records | Missing | Receivers apply no DMARC policy at all |
DMARC tags explained
| Tag | Required | What it does | Example |
|---|---|---|---|
v |
Yes | Version, must be first | v=DMARC1 |
p |
Yes | Policy for the domain | p=quarantine |
rua |
Recommended | Address for aggregate reports | rua=mailto:dmarc@example.com |
ruf |
Optional | Address for forensic reports | ruf=mailto:dmarc-f@example.com |
sp |
Optional | Policy for subdomains, defaults to p |
sp=reject |
pct |
Optional | Share of failing mail the policy applies to, default 100 | pct=50 |
adkim |
Optional | DKIM alignment, r relaxed or s strict |
adkim=r |
aspf |
Optional | SPF alignment, r or s |
aspf=r |
fo |
Optional | When to send forensic reports | fo=1 |
ri |
Optional | Requested report interval in seconds | ri=86400 |
If your rua address is on a different domain (for example a reporting service), that domain must publish an authorisation record, or receivers will not send the reports. Most DMARC reporting services handle this for you.
Common DMARC problems
Policy stuck at none. The most common finding. It often stays there for years because nobody reviews the reports. Set a date to review and tighten.
No rua address. Without reports you cannot tell whether moving to reject would block your own invoices or newsletters.
Syntax errors. Missing semicolons, v=DMARC1 not first, or a mailto without the mailto: prefix. Receivers may ignore the whole record.
Record on the wrong host. Publishing at the root domain instead of _dmarc means receivers never find it.
Subdomains left open. p=reject with sp=none leaves every subdomain spoofable. Unless you have a reason, let sp inherit or set it to match.
Reading aggregate reports
Once rua is set, large receivers such as Google, Microsoft and Yahoo send a zipped XML file roughly once a day. Each file lists the IPs that sent mail claiming your From domain, how many messages each sent and the SPF, DKIM and DMARC result for each group.
Sort the sources into three buckets:
- Yours and passing. Your mailbox provider and properly configured ESPs. Nothing to do.
- Yours and failing. A CRM, billing tool or website form that sends as your domain without aligned DKIM or SPF. Fix these before you enforce, or their mail will go to spam or bounce.
- Not yours. Unknown IPs, often in countries you do not operate in. This is spoofing, and it is exactly what
p=rejectstops.
Raw XML is tedious to read, so most teams route reports to a parsing service that turns them into charts. A small domain can get by with a free tier; a busy domain can receive hundreds of reports a day. Keep at least a month of history so you can compare before and after each policy change.
Rolling out enforcement safely
- Monitor. Publish
p=nonewithrua. Collect two to four weeks of reports. - Fix sources. For every legitimate service that fails, set up aligned DKIM or a custom Return-Path. The SPF checker and DKIM checker confirm each fix.
- Quarantine. Move to
p=quarantine. Optionally start withpct=25and raise it over a few weeks. - Reject. Once reports show only unknown or malicious sources failing, move to
p=reject.
A typical final record:
v=DMARC1; p=reject; rua=mailto:dmarc@example.com; adkim=r; aspf=rThe DMARC generator builds each stage for you, and the email authentication guide explains how DMARC, SPF and DKIM work together.