DMARC Checker:
Read Your Policy the Way a Receiver Does
Enter a domain and this DMARC checker reads the published record, follows the same tree walk a receiving server follows, and shows the policy that actually applies — to your domain, to your subdomains, and to subdomains that were never created. Validated against RFC 9989, not the 2015 specification it replaced.
Quick Answer: How Do You Check a DMARC Record?
A DMARC record is a TXT record published at _dmarc.yourdomain.com. Enter a domain below and the tool fetches it over encrypted DNS, validates every tag against RFC 9989, checks whether your report addresses will actually receive anything, and shows three separate policies: one for the domain, one for subdomains that exist, and one for subdomains that do not. Nothing is sent to our servers.
The lookup runs from your browser over DNS-over-HTTPS. The domain you type is never sent to TrustMyIP.
Walking the DNS tree…
The policy that actually applies
One record, three different answers. This is where the gap usually is.
| Mail claiming to come from | Policy | Which tag decided it |
|---|
Record
Score breakdown
Our weighting, not an official DMARC score. There is no standard grade — the points below show exactly how this one was reached.
Where reports go
What needs attention
A corrected record
Built from what you already publish. It moves the policy up one step rather than jumping straight to reject, because a leap to enforcement without reading your reports first is how legitimate mail gets blocked.
Every DNS query this check made
Last verified 8 August 2026. Every rule here is checked against RFC 9989, RFC 9990 and RFC 9991, published 19 May 2026. The parser was tested against 96 assertions before this page was written, including a check that every record it generates is itself valid.
Robert Harrison
OSINT & Network Utility Expert
A client spent eight months at p=none waiting for enough report data to move to quarantine. The reports never came. Their record was syntactically perfect and every checker they tried said so, because the address in rua was on their monitoring vendor's domain and the vendor had never published the authorisation record. Eight months of a policy that protected nothing, waiting on a feed that was never going to arrive. That is why this tool checks the destination rather than only the record.
The honest limit: a checker reads what is published in DNS. It cannot tell you whether your legitimate mail actually passes, because that depends on every service that sends on your behalf and on alignment at the moment each message is sent. A green result here means the record is sound. Whether you can safely move to enforcement is a question your aggregate reports answer, not this page.
View all articles by Robert HarrisonWhat a DMARC Record Is and What It Decides
A DMARC record is one TXT record published in DNS at _dmarc.yourdomain.com. Running a DMARC record check means reading it the way a receiver reads it, which is what a DMARC validator or DMARC lookup tool does under whichever name it goes by. It answers a question receiving mail servers have no other way to settle: when a message claims to come from your domain but fails authentication, what should happen to it?
Your DMARC policy is the answer to that question. Without a record, the decision is left entirely to the receiver's own judgment. With one, you tell them. That is the whole mechanism, and it is why a record that exists but says p=none is not the same as protection.
DMARC sits on top of two other checks rather than replacing them. SPF says which servers may send for a domain. DKIM signs the message so tampering is detectable. DMARC adds the part neither of them covers: it requires that the domain those checks passed for is the same domain the reader sees in the From line. That requirement is called alignment, and it is where most confusing results come from.
The single most common misreading: spf=pass alongside dmarc=fail. It is not a contradiction. SPF checked the envelope sender, which is where bounces go, not the From address. If those are different domains, SPF can pass while DMARC refuses the alignment. Our email header analyzer computes that alignment on a real message so you can see it happen.
Before any of that matters, the record has to be readable, and that starts with where a receiver looks for it.
Three Policies From One Record: p, the sp Tag and np
A DMARC subdomain policy is not one setting but two, and any DMARC analyzer that reports a single policy line is hiding the distinction. That is where the real gaps live. One record produces three different outcomes depending on what the sender claims to be.
| Mail claims to come from | Tag that decides | If that tag is absent |
|---|---|---|
| The domain itself | p | The record is invalid without it |
| A subdomain that exists | sp | Falls back to p |
| A subdomain that does not exist | np | Falls back to sp, then to p |
The np tag is new in RFC 9989 and it closes a gap the 2015 specification left open. An attacker sends as invoices.yourcompany.example, a subdomain nobody ever created. Under the old rules that mail was handled by sp, so a domain running p=reject; sp=none was strict about itself and wide open to a subdomain that did not exist.
The combination worth checking for right now: a strict p with a permissive sp and no np. The domain looks protected in every summary, and mail from any invented subdomain sails through. The table at the top of this page shows all three policies side by side precisely so that pattern is visible rather than buried.
Adding np=reject costs nothing and blocks a category of spoofing outright, because no legitimate mail can come from a subdomain that was never created.
What Changed in May 2026: RFC 9989 Replaces RFC 7489
The update was known as DMARCbis through the seven years the working group spent on it, and on 19 May 2026 the IETF published three documents that together replace the original DMARC specification: RFC 9989 for the core protocol, RFC 9990 for aggregate reporting and RFC 9991 for failure reporting. They obsolete RFC 7489 from 2015 and RFC 9091, and they move DMARC from Informational status onto the IETF Standards Track.
Two things matter immediately. Nothing you have published breaks — records still begin with v=DMARC1 and there is no DMARC2. And a handful of tags changed, which most validators have not caught up with yet.
Three tags were retired
| Tag | What it did | What to do |
|---|---|---|
pct | Applied the policy to a percentage of mail | Receivers implemented it inconsistently. Use t=y instead |
rf | Requested a failure report format | Only one format was ever used. Remove it |
ri | Requested a report interval | RFC 9989 recommends daily reports. Remove it |
Three tags were added
| Tag | What it does | Values |
|---|---|---|
np | Policy for subdomains that do not exist | none, quarantine, reject |
psd | Declares a public suffix domain boundary | y, n, u |
t | Testing mode. Receivers apply one level below the stated policy | y or n, default n |
The t tag replaces pct directly: t=y means what pct=0 meant, and t=n means what pct=100 meant and is the default when the tag is absent.
The transition detail nobody mentions: receiver adoption is uneven. A server that still follows RFC 7489 reads pct and ignores t; a server following RFC 9989 does the opposite. If you are staging a rollout right now, publish both — pct=25 alongside t=y — so either kind of receiver understands you are still testing. The check above flags a record that has one without the other.
The Public Suffix List is gone
RFC 7489 told receivers to consult an offline list, usually the one at publicsuffix.org, to work out where a domain's organizational boundary sat. RFC 9989 replaces that with a DNS tree walk: when a subdomain has no record of its own, the receiver queries each parent in turn until it finds one. The practical result is usually identical, and it removes a dependency on a file that had to be maintained separately. The check above walks up the same way and shows every query it made. The stopping rules in unusual cases are the specification’s business rather than this page’s, so treat the query list as what was actually asked rather than a claim of byte-for-byte conformance.
Why Your DMARC Reports Never Arrived
A record can be flawless and still produce no reports at all. When that happens the cause is almost always one of four things, and only one of them is visible in the record itself.
1. The address is on someone else's domain and they never consented
This is the one that catches people, because nothing about the record looks wrong. If your rua address is on a different organizational domain — a monitoring vendor, a group mailbox at a parent company — that domain has to publish a TXT record granting permission.
# Your record at _dmarc.yourdomain.example
v=DMARC1; p=reject; rua=mailto:reports@vendor.example
# The record VENDOR must publish, in their zone
yourdomain.example._report._dmarc.vendor.example TXT "v=DMARC1"
Without it, receivers simply do not deliver. The reason is sound: otherwise anyone could publish a record pointing reports at a victim, then send enough failing mail to bury them.
The naming rule is where people slip. The label on the left is the domain the policy was retrieved from, not necessarily the domain you looked up. If mail.example.com has no record of its own and inherits the one at example.com, the authorisation record is named after example.com. Publish it under the subdomain and receivers will never query it. The check builds the name from the domain the record actually came from and tells you whether it exists.
2. The rua or ruf URI is malformed
One missing mailto: prefix silences the entire feed. The same applies to ruf, which carries per-message failure reports rather than daily summaries. Multiple addresses are separated by commas, tags by semicolons, and mixing the two breaks it. The check validates the syntax of every address in both tags.
3. There is nothing to report on
Receivers report on mail they evaluated. A domain sending a handful of messages a day may genuinely receive nothing.
4. Not enough time has passed
Most receivers send aggregate reports once per UTC day. Allow a full 24 to 48 hours before concluding something is broken. RFC 9990 describes them as daily or more frequent, which is also why the old ri interval request was retired.
Check in this order: read the live record, validate the rua syntax, confirm the external authorisation record if the address is off-domain, confirm you are actually sending mail, then wait 48 hours. Four of those five are answered by the check at the top of this page.
Moving From p=none to Enforcement Without Breaking Your Mail
Publishing p=reject on a domain you have not measured is the fastest way to block your own invoices. The sequence below is slower and it works.
Four stages, in order
1 Publish p=none with reporting
Nothing is blocked. The point is the rua feed. Confirm reports actually arrive before you wait on them — that is the failure this page's check exists to catch.
2 Read the reports until you recognize every sender
Your CRM, your invoicing platform, your helpdesk, the marketing tool someone signed up for two years ago. Each needs SPF or DKIM aligned with your From domain. Weeks, not days.
3 Move to quarantine, staged
Publish p=quarantine with t=y, and keep pct alongside it while older receivers are still in the mix. Watch for a fortnight. Failures now go to junk, which is recoverable.
4 Move to reject, and set sp and np
Drop the testing flag. Set sp deliberately rather than letting it inherit, and add np=reject to close the non-existent subdomain gap in the same edit.
The mailbox providers have made the deadline real. Gmail moved from deferring non-compliant bulk mail to rejecting it permanently in November 2025, Outlook applied its own hard rejection the same month, and Microsoft's refusal carries a code worth recognising in a bounce: 550 5.7.515. A recipient adding you to their safe-sender list does not override it, because the check runs before personal allow lists are consulted.
There is a compliance angle too. PCI DSS 4.0 requirement 10.4.1.1 obliges organisations handling cardholder data to run anti-phishing controls that explicitly include DMARC. It became mandatory during 2025 and is enforced through 2026.
Six Mistakes This Check Finds Most Often
Ordered by how often they turn up rather than how serious they are.
1. Two DMARC records on one domain
A domain may publish exactly one. When a receiver finds two it treats the domain as having none, so DMARC stops working entirely. This usually happens when a record is added at a new provider without removing the old one. To see every TXT record a domain publishes, use our DNS record lookup.
2. p=none, published years ago, never revisited
Monitoring only. Nothing is blocked. It is the correct first step and it protects nothing on its own.
3. Reports pointed at an unauthorised destination
Covered above, and worth repeating because it fails silently. The record validates, the reports never arrive, and the whole rollout stalls waiting for data.
4. A strict p with a permissive sp and no np
The domain is locked down and every subdomain, real or invented, is open. Summaries that report only p will call this domain protected.
5. Retired tags still published
pct, rf and ri were removed in RFC 9989. Nothing breaks, because receivers ignore tags they do not recognize, but a record carrying them is describing behavior that no longer applies.
6. A missing mailto: prefix
rua=dmarc@example.com is not a URI. One prefix, and the entire reporting feed goes silent.
After you fix the record: send yourself a real message from each of your sending platforms and read the headers. The record says what should happen; the headers show what receivers actually concluded. The header analyzer linked earlier computes the alignment itself rather than reprinting the verdict. If a sending address has also picked up a poor reputation along the way, our DNSBL blacklist check shows whether it is listed.
DMARC Checker: Frequently Asked Questions
What does a DMARC checker actually check?
It reads the TXT record published at _dmarc under your domain and works out what a receiving mail server would do with it. That means the syntax, the policy strength, whether subdomains are covered, whether your reporting addresses will actually receive anything, and whether the record still uses tags the current specification retired.
My policy is p=none. Is that bad?
It is the right place to start and the wrong place to stay. p=none tells receivers to take no action when a message fails, so nothing is blocked and nothing is protected. Its purpose is to collect aggregate reports until you can see every legitimate sender, then move to quarantine and eventually reject. A domain that has sat on p=none for years is publishing a record that does nothing.
What is the np tag and do I need it?
np sets the policy for mail claiming to come from a subdomain that does not exist. It was added in RFC 9989 to close a gap the original specification left open: an attacker sending as invoices.yourdomain.example when no such subdomain was ever created. Without np, that mail is handled by sp, or by p if sp is absent too. Adding np=reject costs nothing and closes the gap.
Why am I not receiving DMARC reports?
Usually one of four reasons. The rua address is malformed, most often a missing mailto: prefix. The address is on a different organizational domain and that domain has not published the authorisation record receivers look for. There is too little mail volume to report on. Or not enough time has passed, since most receivers send aggregate reports once a day.
What is external destination verification?
If your report address sits on a domain other than yours, that domain has to consent. It does so by publishing a TXT record named yourdomain._report._dmarc.theirdomain with the value v=DMARC1. Without it receivers will not deliver your reports, because otherwise anyone could point their reports at a victim and flood them. The tool checks this and shows you the exact record name.
Do I need to change my record now that RFC 9989 has replaced RFC 7489?
Nothing breaks. Records still begin with v=DMARC1 and there is no DMARC2. The pct, rf and ri tags were retired, so remove them at your next DNS edit; receivers ignore them rather than reject the record. The new np, psd and t tags are optional additions. If you use pct for a staged rollout, publish t=y alongside it during the transition so newer receivers understand the intent too.
What replaced the Public Suffix List?
A DNS tree walk. When a subdomain has no DMARC record of its own, a receiver now walks up the tree querying each parent until it finds one, rather than consulting an offline list to guess where the organizational boundary sits. The practical effect is the same in most cases, and it removes a dependency on a file that had to be kept up to date.
Does a DMARC pass mean an email is safe?
No. It means the message came from a server authorised by the domain in the From line, and that the two line up. A compromised but genuine account passes every check and still sends whatever the attacker wants. Authentication tells you about origin, not intent.
Related Email & DNS Tools
Work the rest of the chain with the TrustMyIP toolkit.
Your Record Says One Thing
Receivers May Read Another
Check the policy that actually applies to your domain, your subdomains, and the subdomains that do not exist. Validated against the May 2026 standard.