Free DMARC checker — no account, no card

Is your DMARC policy protecting anything?

We read the record at _dmarc, grade the policy, and check how strictly it asks receivers to align SPF and DKIM — because a record that says p=none enforces nothing. SPF, DKIM, MX and 39 blacklists come with it, in the same run.

~40 seconds · you get a report link you can send to anyone

What we read at _dmarc

A record is not a policy.

THE RECORD Published at _dmarc.yourdomain.com, syntactically valid, and only one of them.
p= none observes, quarantine files under spam, reject refuses. Only two of those protect you.
ALIGNMENT DMARC only passes if SPF or DKIM aligns with the From: domain your recipients read.
rua= Without a report address you are enforcing blind — and you will never reach reject safely.
sp= Subdomains inherit your policy unless sp= says otherwise. Spoofers go for the subdomains.

DMARC in one minute

What receivers should do when SPF and DKIM say no.

SPF and DKIM produce a verdict. DMARC is the instruction that turns that verdict into an action — and the reports that tell you who is sending as you.

A record that enforces something

v=DMARC1; p=quarantine; rua=mailto:[email protected]; sp=quarantine; adkim=s

p=none is a microphone, not a shield. It asks receivers to report what they see and do nothing about it. That is the right place to start and the wrong place to stay: a domain that has been sitting on p=none for a year is a domain anyone can still spoof. The ladder is none → quarantine → reject, and most domains never climb it because nobody is reading the reports.

Alignment is where it quietly breaks. A newsletter tool can pass its own SPF while sending From: your domain — SPF says pass, DMARC says fail, because the domain that authenticated is not the domain your reader sees. From your DNS we read how strictly your record demands alignment; seeing which of your senders actually meets it takes the DMARC reports receivers send back — the thing monitoring collects, and the reason you move to reject without losing mail.

Climbing to enforcement

none → quarantine → reject, one rung at a time.

Enforcement is not a switch you flip. It is a ramp you walk, watching your reports at every step so the only mail you ever block is mail that was never yours.

Ramping a policy into force

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

The three policies do very different things. p=none tells receivers to report and act on nothing. p=quarantine files failing mail under spam, where a recipient can still fish it out. p=reject refuses it at the SMTP handshake — it never arrives, and the forger gets a bounce. Only the last two cost a spoofer anything.

pct= is how you climb without falling. p=quarantine; pct=25 applies the policy to a quarter of failing mail and treats the rest as none. You watch the reports, confirm that only forgeries are being caught, then step 25 → 50 → 100 and finally to p=reject. Each rung is reversible in the time DNS takes to propagate.

Most domains stall on the first rung. Since February 2024, Google and Yahoo have required anyone sending bulk mail to them to publish a DMARC record at all — and p=none satisfies the letter of that requirement. So millions of domains published none, ticked the box, and stopped. The record exists. The protection does not.

Where DMARC actually passes

An SPF pass and a DKIM pass are not a DMARC pass.

DMARC does not care that a check passed. It cares that the domain which passed it is the domain your reader sees. That single condition is where almost every legitimate sender trips.

Alignment is a comparison, not a check. DMARC needs at least one of two things to line up with your From: domain. SPF alignment compares the hidden Return-Path — the envelope your mail server bounces to — against your From:. DKIM alignment compares the d= domain in the signature against your From:. Pass either, and DMARC passes. Pass neither, and it fails no matter how green SPF and DKIM looked on their own.

Relaxed or strict decides how close is close enough. The default, adkim=r and aspf=r, accepts an organisational match: mail.yourdomain.com aligns with yourdomain.com. Strict — adkim=s, aspf=s — demands an exact string match and will fail a subdomain you legitimately sign from. Start relaxed. Reach for strict only when you control every host that signs your mail.

This is why your newsletter tool fails. It sends with a Return-Path like bounces.themailer.com, so it passes its own SPF — but that is the mailer's domain, not yours, and SPF alignment fails. The only rescue is DKIM: if the vendor signs with d=yourdomain.com because you added the CNAME records they asked for, DKIM aligns and DMARC passes. Most alignment failures are simply a sender whose DKIM you never finished setting up.

Reading versus seeing

A lookup shows the record. Only reports show the senders.

What the aggregate reports contain. Every receiver that honours your rua= address sends back an XML summary, usually once a day. It lists each source IP that sent mail using your From: domain, how many messages, whether SPF and DKIM passed, whether each one aligned, and which disposition your policy caused. Not the content of anyone's mail — the verdicts. Read across a week of them from Google, Microsoft 365 and Yahoo and you have the full census of who sends as you.

Reading DNS is not the same as ingesting reports. A checker resolves your record in under a second and tells you the policy, the syntax, the alignment mode. What it cannot tell you — because it is not in DNS — is whether your CRM, your invoicing system or your support desk actually aligns in the wild. That answer lives only in the aggregate reports, which is why you cannot reach p=reject blind: without ingesting them you are guessing which of your own senders you are about to refuse.

The subdomain is the door left open. A subdomain with no record of its own inherits your organisational policy — but only as far as sp= allows. Set p=reject on the apex and leave sp=none, and news.yourdomain.com is wide open while the domain looks locked. Spoofers know this. They rarely forge the name you defend; they forge the subdomain you forgot to cover.

Five ways enforcement quietly fails

The record looks fine. It still protects nothing.

TWO RECORDS Two TXT records at _dmarc is a permerror. Receivers apply neither, and you are back to no policy at all.
p=none FOREVER Published to satisfy Google and Yahoo, never advanced. The reports pile up unread while spoofing stays free.
pct= LEFT LOW A pct=25 you set to ramp and forgot. Three-quarters of forged mail still sails past your own policy.
NO rua No report address means no visibility and no safe path to reject. Enforcement becomes a coin flip with your mail.
rua NOBODY READS Raw XML landing in a shared inbox is the same as no reports. Something has to parse them, or they are noise.

Common questions

About DMARC, specifically.

Is p=none useless? Not at first — it is how you learn who sends as you. It becomes useless the day you stop reading the reports, which is usually week two.
What does alignment mean? The domain that passed SPF or signed with DKIM must match the From: domain your recipient sees. Same domain, or DMARC fails even though both checks passed.
What is the difference between p=quarantine and p=reject? Quarantine sends failing mail to spam, where a recipient can still recover it. Reject refuses it at the SMTP handshake, so it never arrives and the sender bounces. Reject is the destination; quarantine is the safe rung before it.
How long should I stay on p=none? Long enough to see every legitimate sender aligning in your reports — usually two to four weeks. Then move to quarantine with pct= and ramp. Beyond that you are only collecting data, not protection.
Should I use relaxed or strict alignment? Relaxed accepts an organisational match, so subdomains count; strict demands an exact match. Start relaxed. Move to strict only once you control every host that signs mail as you.
Will p=reject break my newsletters? It will, if they are not aligned yet. Publish reject only once your reports show every legitimate sender passing — that is the whole reason to start at none.
Do I need a report address? Yes. Without rua= you have no idea what you would be blocking, and enforcement becomes a coin flip with your own mail.
Do I need DMARC for Google and Yahoo? If you send in bulk, yes. Since February 2024 both require senders of large volumes to publish a DMARC record; p=none meets the rule but not your security. Any sender benefits from having one.

How it works

Real DNS queries, not a cached database.

We query your records live, the way Gmail or Outlook would at the moment of delivery. What you see is what receivers see.

  1. 1 You enter a domain. No verification needed — the records we read are public DNS, the same ones every mail server reads.
  2. 2 We run ~90 live queries. DNS records, selector probes, and one lookup per blacklist — about 40 seconds in total.
  3. 3 Every finding is scored and explained. Problems that cost you deliverability today, watches that will — each with numbered steps to fix it.
  4. 4 The report gets its own link. It stays at that URL: send it to your host, your IT provider or your client instead of a screenshot. Public DNS only — we store the answers, never your mail.

The other free checks

Same run, different question.

Full domain check → Everything at once: SPF, DKIM, DMARC, MX and the blacklists, scored out of 100. SPF checker → Syntax, the 10-lookup limit, and the mechanisms that let anyone spoof you. Blacklist checker → Your domain and your sending IPs against every major RBL, with delisting links. Email tester → Send a real message and see SPF, DKIM and DMARC as a receiver does — with true alignment.