Look Up a Domain's DMARC Record — and What Its Policy Actually Does
Check whether a domain publishes a DMARC record, read the policy it sets, and see whether that policy tells mailbox providers to act on forged mail — or only to watch it go by. Free, no signup.
Enter a domain to look up its DMARC record and policy
Checking syntax, MX, SMTP, trust, gateway, and domain profile…
Enter a domain above and click Check to see results.
DMARC — Domain-based Message Authentication, Reporting and Conformance — is a TXT record published at _dmarc.yourdomain.com. It does one job: it tells receiving mail servers what to do with a message that claims to come from your domain but fails authentication.
On its own, DMARC checks nothing. It sits on top of SPF and DKIM and decides the consequence when those fail. That layering is why a domain can publish all three and still be trivially spoofable — the record can be present and the policy can be set to do nothing at all.
A DMARC lookup should therefore answer two questions, not one: is a record published, and what does it instruct receivers to do? A checker that returns only "DMARC found" has answered the easy half.
The p= tag is the whole record in miniature. These are the only three values it can take, and the difference between them is the difference between protection and paperwork.
| Policy | What receivers do | Protects you? |
|---|---|---|
| p=none |
Nothing. Forged mail is delivered exactly as it would be with no DMARC record at all. Receivers send aggregate reports to the address in the rua= tag, and that is the entire effect.
|
No |
| p=quarantine | Mail that fails authentication is treated as suspicious — in practice, delivered to the spam folder rather than the inbox. | Mostly |
| p=reject | Mail that fails authentication is refused at the SMTP conversation. It never reaches a mailbox, spam folder included. | Yes |
p=none is the default nearly everyone stops at. It is the correct place to start — you publish it, collect reports for a few weeks, find the legitimate senders you had forgotten about, and only then tighten. The failure is not choosing p=none; it is choosing it in 2019 and never coming back. A domain sitting on p=none has the paperwork of DMARC and none of the protection, and every checker that reports "DMARC: present" for it is telling the truth in a way that misleads.
This is why the result above shows the policy value rather than a green tick. A domain on p=none is reported as published-but-not-enforcing, because that is what it is.
"We have DMARC, so we're protected." Only if the policy enforces. See the table above — this is the single most common misreading, and it accounts for most domains that get spoofed despite a valid record.
"DMARC passed, so the sender is legitimate." DMARC authenticates the domain, not the person or the intent. A phisher who registers c0mpany.com and configures it properly will pass DMARC on their own lookalike domain every time. Authentication and trustworthiness are different questions — which is what a full email check and a domain trust score are for.
"No DMARC record means the domain is fake." It does not. Plenty of legitimate small domains have never published one. Missing DMARC raises the risk that mail claiming to be from that domain is forged; it says nothing about whether the domain itself is real. To answer that, check whether the domain is disposable or look at its mail server and MX records.
"The subdomain is covered." Not necessarily. The sp= tag sets the subdomain policy separately, and if it is absent the parent policy applies. A domain with p=reject; sp=none has left every subdomain wide open, which is exactly where lookalike sending tends to happen.
SPF lists the servers allowed to send as your domain. It validates the hidden envelope sender, not the From: address a recipient reads — so on its own it does not stop display-name spoofing. Check it with the free SPF checker.
DKIM cryptographically signs the message so a receiver can confirm it was not altered and did come from a host holding your key.
DMARC ties either of those results to the visible From: domain — this is called alignment — and states the consequence when neither aligns. That last part is the bit only DMARC provides, and the bit that p=none declines to use.
MailRook records SPF and DMARC state for every domain in its catalogue as part of scoring signup and list quality. You can see the same authentication read on any individual domain profile — for example the disposable email provider catalogue links through to a per-domain report for each one. For programmatic access to these fields across a whole list, see the domain enrichment API.
Enter the domain in the box above. The checker queries the TXT record at _dmarc.<domain> and reports whether a record exists and what policy it sets. You can also query it yourself with dig TXT _dmarc.example.com.
p=reject is the goal. Start at p=none to collect reports, move to p=quarantine once you have identified every legitimate sender, then to p=reject. Staying on p=none indefinitely gives you reporting and no protection.
No. It stops mail that forges your exact domain. It does nothing about lookalike domains, compromised accounts on your own domain, or display names that read like your brand from an unrelated address.
Because those are different answers. If MailRook has not yet inspected a domain's DNS, reporting "no DMARC record" would be a claim about that domain we have not verified. Run the lookup and the result fills in.
Yes, with no signup. An account raises the daily limit and unlocks bulk checks and API access.
One domain at a time is the free tier. The API returns SPF, DMARC policy, MX, catch-all and a domain trust score for every address you send it — at signup, or across an existing list.
What you unlock