DMARC record checker.
Parse every tag, grade the policy, and flag monitoring-only enforcement, missing reporting, and subdomain gaps. See exactly what a client domain tells receivers to do with failed mail.
More than a TXT lookup.
A DMARC record can exist and still protect nothing. The checker parses the record the way a receiving mail server does and grades what it actually enforces.
record presence & uniqueness
A domain must publish exactly one v=DMARC1 TXT record at the _dmarc subdomain. Zero means no policy; two or more can make receivers ignore DMARC entirely.
policy strength
p=none only monitors — spoofed mail still lands in inboxes. We grade your policy and tell you whether it actually instructs receivers to quarantine or reject failures.
tag syntax
Every tag is parsed per RFC 7489: invalid policies, out-of-range pct values, bad alignment modes, malformed reporting URIs, and duplicate tags.
aggregate reporting
Without a rua= address, no one is told when DMARC fails — you are enforcing blind. We flag records that have no aggregate reporting destination.
subdomain coverage
The sp= tag can quietly leave every subdomain at a weaker policy than the domain itself. We compare the two and flag the gap.
percentage rollouts
pct below 100 applies your policy to only a fraction of failing mail. Useful during rollout, a hole if it is left behind — we surface it either way.
The DMARC mistakes we see most.
stuck at p=none
p=none is meant as a temporary monitoring step, but most domains never leave it. Receivers get no instruction to do anything with spoofed mail, so the record protects nothing.
no reporting address
Without rua=, receivers have nowhere to send aggregate reports. You cannot see who is sending as your domain, which failures are legitimate senders, or when something breaks.
weak subdomain policy
sp=none next to p=reject means the main domain is protected but invoices.yourdomain.com is not. Spoofers target subdomains precisely because of this gap.
record at the wrong name
DMARC lives at _dmarc.yourdomain.com, not at the root. A perfectly valid record published in the wrong place is invisible to every receiver.
leftover pct from rollout
pct=10 was sensible while testing quarantine, but left in place it exempts 90% of failing mail from your policy — silently, forever.
DMARC questions, answered.
DMARC (Domain-based Message Authentication, Reporting & Conformance) is a DNS TXT record published at _dmarc.yourdomain.com. It tells receiving mail servers what to do with messages that fail SPF and DKIM alignment — deliver, quarantine, or reject them — and where to send reports about those failures. It is the policy layer that makes SPF and DKIM actually stop spoofing.
p=none asks receivers to take no action and just send reports — spoofed mail is still delivered. p=quarantine asks them to treat failures with suspicion, typically sending them to spam. p=reject asks them to refuse failing mail outright. Only quarantine and reject actually enforce; none is a monitoring mode meant to be temporary.
As a starting point, no — it is the recommended first step so you can watch reports and find legitimate senders that fail alignment before enforcing. As a destination, yes: a domain that stays at p=none indefinitely gets the reporting benefits of DMARC but none of the protection. Plan to move to p=quarantine and then p=reject.
rua= is the address receivers send aggregate reports to — daily XML summaries of which servers sent mail as your domain and whether it passed SPF and DKIM. Without it you are blind: you cannot see spoofing attempts or catch a legitimate sender you forgot to authorize before moving to an enforcing policy. Every DMARC record should have one.
By default, yes — subdomains inherit the p= policy of the organizational domain. But the sp= tag overrides that inheritance, and sp=none next to p=reject leaves every subdomain unprotected. If you use sp=, make sure it is at least as strong as p=.
You need at least one of them, and in practice you want both. DMARC passes only when SPF or DKIM passes and aligns with the From address your recipients see. Publishing DMARC without working, aligned SPF or DKIM means all your mail fails — which is exactly why you start at p=none with rua= reporting and verify before enforcing.
A valid DMARC policy is one part of the client domain.
The free scan checks email auth & DMARC, SSL & domain expiry, look-alikes, and blacklists together from public records. Monitoring adds daily DMARC reports with one DNS record.
Keep checking the same failure point.
Use the related tools one at a time, or run all four posture checks together.
DNS lookup →
Query A, AAAA, CNAME, MX, NS, SOA, TXT, and CAA records in parallel and share one result.
SPF record checker →
Follow every include, count the 10-lookup limit, and flag syntax errors or unsafe policies.
DKIM record checker →
Probe common selectors, validate each public key, and flag weak, revoked, or broken records.