DMARC checker: blocking spoofing,
or just watching?
Enter a domain — we read your DMARC record, parse every tag, and grade what it actually does. The catch most checkers miss: p=none isn't protection — it just asks receivers to email you about the spoofing they let through.
Four records that protect nothing
A DMARC record can be syntactically perfect and operationally useless. Each of these four passes existence checkers and leaves an open door in practice.
The eternal p=none
Set to "monitoring" during rollout in 2023 — and still monitoring. p=none tells receivers to take no action: spoofed mail sails into inboxes wearing your name, while your dashboard shows DMARC ✓.
protection = 0Reports to nowhere
Your rua= points at a vendor or agency domain that never published the authorization record. Receivers check for it — and silently discard every report. No bounce, no error, no data. Ever.
RFC 7489 §7.1The pct= hole
p=reject; pct=50 — the rollout dial left mid-ramp. Half of the spoofed mail is rejected, the other half delivered, chosen per message. An attacker doesn't mind retrying.
a coin flip per messageThe subdomain back door
An explicit sp=none left over from rollout means your root rejects spoofing while invoices.yourdomain.com accepts it. Attackers read DNS too.
sp=none = open doorSix things a record can say
The p= tag is an instruction to every mail receiver on Earth. We grade it as a maturity ladder, not a pass/fail.
"Mail that fails alignment: refuse it at the gate." Full protection — the destination of the ladder. Only as strong as the SPF and DKIM feeding it, and only whole at pct=100.
"Treat failures with suspicion" — in practice, the spam folder. Real partial protection and the correct middle rung, especially ramped with pct=. Not the summit.
Monitoring: nothing is blocked, but reports flow, and you learn who sends as you. The correct first 90 days of every DMARC rollout — and the permanent state of far too many.
Nothing is blocked and nobody is watching. The record exists purely to satisfy checkers that only test existence. Compliance theater at its purest.
Receivers fall back to their own heuristics; your domain's spoofability depends on whoever is receiving. Increasingly also a deliverability problem: bulk senders to Gmail/Yahoo are required to publish DMARC.
Multiple v=DMARC1 records at _dmarc don't merge — discovery fails and receivers treat you as publishing nothing. Same for a mangled tag list.
Where your DMARC reports actually go
DMARC reporting is an agreement between three parties: you, the receivers, and whoever reads the reports. When rua= points at a different domain (a vendor dashboard, an agency inbox), RFC 7489 §7.1 requires that domain to consent:
- Before sending a report, the receiver queries yourdomain._report._dmarc.theirdomain for a v=DMARC1 record.
- No record → no report. Silently. No bounce reaches you, nothing logs it — your reporting simply never existed.
- Real vendors publish a wildcard (*._report._dmarc.example.com) — a typo'd vendor domain, a lapsed account or an agency's plain inbox won't have it.
- We resolve up to 5 rua=/ruf= destinations per tag and run this query for each — most checkers never do.
The maturity ladder
what each rung buys youWhat dig can tell you
The record is one dig away, and the authorization check is just DNS once you know it exists. Grading what the policy enforces takes more than a one-liner.
Common DMARC questions
Type your domain above. We fetch the TXT record at _dmarc.yourdomain, confirm there is exactly one v=DMARC1 (two means receivers see none at all), and parse every tag against RFC 7489 with the defaults spelled out (p=, sp=, pct=, adkim=/aspf=, rua=/ruf=, fo=). Then we grade the enforcement level and verify the report destinations we grade can receive reports. Free, no signup.
It tells every receiver: "when mail fails DMARC, take no action — deliver it, but send me a report." Nothing is quarantined and nothing is rejected. A spoofed invoice lands in your customer's inbox exactly as if you had no DMARC. What p=none buys you is visibility: the aggregate reports name every server sending as your domain, legitimate or not. That makes it the correct first rung of a rollout, and a terrible place to live. If your record has said p=none for more than 2 quarters, you're not "doing DMARC". You're watching other people impersonate you in high definition.
Ladder, not leap. First: p=none with rua= for one quarter. Read the reports, find every legitimate sender (the invoicing tool nobody mentioned), and fix their SPF/DKIM alignment. Then: p=quarantine; pct=10, and raise pct to 50 then 100 as reports stay clean. Then: p=reject. If one subdomain lags (a newsletter platform mid-migration), give it its own _dmarc.sub record rather than holding the whole domain at none. Gate every step on report data — the reports are the safety net that makes strictness safe.
rua= is aggregate reporting: daily XML summaries from each receiver — which IPs sent as you, how many passed or failed, under what policy. This is the one that matters; it's how you steer the ladder. ruf= is forensic reporting: per-message failure copies. Most large receivers, Gmail and Microsoft included, no longer send them for privacy reasons. Treat ruf= as a bonus from smaller receivers, not a data source you can rely on. Both take mailto: URIs only, and both are subject to the external-destination authorization check this tool runs.
The classic cause is the check this tool exists to run: your rua= points at a domain that isn't yours, and that domain never published the authorization record. RFC 7489 §7.1 makes receivers verify consent first: they query yourdomain._report._dmarc.destinationdomain and expect a v=DMARC1 answer. No answer → the report is silently discarded, with no bounce and no error you can see. It happens when the vendor domain is typo'd, or when you switch vendors but not the record. It also happens when reports go to an agency mailbox never set up for cross-domain reporting. We run the query for each destination we grade and show you the exact missing record.
Alignment is how DMARC connects SPF/DKIM to the From: line your reader sees. Relaxed (the default, r) accepts an organizational-domain match — mail signed by news.yourdomain.com aligns with yourdomain.com. Strict (s) demands an exact match. Relaxed is the right call for almost everyone; strict closes a narrow gap (a compromised or delegated subdomain vouching for your root) at the price of breaking every subdomain sender you forgot about. Tighten to strict only after your reports show a quarter of clean, exact-domain alignment.
It stops exact-domain spoofing at cooperating receivers — which is most of the internet's mailbox volume. Three gaps remain. DMARC only judges alignment, so it is exactly as strong as the SPF and DKIM underneath it. A permerror'd SPF or a revoked DKIM key quietly weakens reject. A pct<100 or a weaker sp= leaves deliberate holes. And lookalike domains (yourcompany-billing.com) are out of scope, because no DMARC record of yours can speak for a domain you don't own. Check the whole stack: our SPF and DKIM tools cover the first gap.
Free tools are just the start.
Uptimia keeps your sites healthy.
Uptime, SSL, domain expiry, page speed, transactions — monitored from 171+ locations worldwide. Free for 30 days.