Free tool · no signup
Free DMARC checker
Look up the DMARC record on any domain, see the policy receivers actually apply to it, and find out whether your reports are reaching anyone. Most records enforce nothing.
Ungated · no email required · unlimited checks
In short
- This is a free, ungated DMARC checker. It reads the TXT record published at _dmarc.yourdomain.com, reports the policy that applies to the exact name checked, and verifies that every reporting address named in the record is able to receive reports.
- DMARC (Domain-based Message Authentication, Reporting and Conformance) is defined by RFC 7489. It tells receiving servers what to do with mail that shows a domain in the From address but fails SPF and DKIM, and where to send reports about that mail.
- The policy tag has three values. p=none means receivers report but deliver failing mail anyway, so nothing is blocked. p=quarantine sends failing mail to the spam folder. p=reject refuses it outright. Only quarantine and reject stop domain spoofing.
- DMARC does not authenticate mail itself. It reads the SPF and DKIM results and requires the domain that passed to align with the domain in the visible From address. Relaxed alignment, the default, accepts any subdomain of the same organizational domain; strict alignment requires an exact match.
- A subdomain that publishes no DMARC record of its own inherits the record on its organizational domain, and receivers apply that record's sp tag rather than its p tag (RFC 7489 §6.6.3). A checker that queries only the exact name reports no DMARC on most subdomains, which is wrong.
- A reporting address at a domain the sender does not own requires that domain to publish an authorisation record at senderdomain._report._dmarc.destinationdomain (RFC 7489 §7.1). Without it receivers must not send the reports, so the domain appears monitored while no data arrives.
- Publishing two DMARC records at _dmarc is not a merge. RFC 7489 §6.6.3 states that a receiver finding more than one applies no policy at all, so a second record removes DMARC rather than softening it.
Enter the domain that appears in your From address. We read the live record at _dmarc, follow the same fallback a receiving server does, and check that your reporting addresses are allowed to receive anything.
The shape of it
The three parts of a DMARC record
The version tagAlways first, always in capitals. It is the one case-sensitive value in the record, so v=dmarc1 is discarded by a strict receiver.
The instructionWhat receivers do with mail that fails: none, quarantine or reject. Without this tag the whole record is thrown away.
The reportsWhere the daily aggregate reports go. This is the only view you get of who is sending mail as your domain.
The whole record lives at _dmarc.yourdomain.com, never on the domain itself. A DMARC record published on the root is invisible to every receiver on the internet, which is the most common reason a domain that looks protected is not.
The other two records
DMARC is the verdict on the other two
SPF and DKIM decide whether a message authenticates. DMARC decides what that is worth by requiring the domain that passed to match the one your recipient can see, and then says what happens when nothing does. Turning it on before those two are in place is how a domain starts blocking its own mail.
Which servers may send as you
SPF Checker
SPF lists the servers allowed to send mail for your domain. Check that yours is published, resolves, and stays under the ten-lookup limit that silently breaks it.
What it looks like
v=spf1 include:_spf.google.com ~all
Proof the message is really yours
DKIM Checker
DKIM signs every message with a key only you hold. Check that the public key is published, parses, is not revoked, and is long enough to be trusted.
What it looks like
v=DKIM1; k=rsa; p=MIIBIjANBgkq…
The basics
What a DMARC record is
DMARC is the instruction you leave for every mailbox provider in the world about mail that claims to be from you and cannot prove it. It is one TXT record, and it works in three moves. This page is for reading a record you already have; if you are starting from nothing, our guide to setting up SPF, DKIM and DMARC covers publishing all three, in order.
Run first
A receiving server checks whether the sending server was authorised, and whether the signature on the message holds.
Checks alignment
It then asks the question neither of those does: is the domain that passed the same domain the recipient can see in the From line?
Decides the outcome
If nothing passed and aligned, your p tag says what happens next: deliver and report, quarantine, or reject.
The middle step is the one that matters, and it is called alignment. SPF checks the envelope sender and DKIM checks a signature, and neither of them looks at the From address a recipient actually reads, which is why a spoofer can pass both on a domain they own. DMARC closes that gap by demanding the two line up. Google and Yahoo have required bulk senders to publish a DMARC record since February 2024.
Not optional any more
Who is required to have a DMARC record
DMARC used to be advice. For anyone sending at volume it is now an entry requirement at the three mailbox providers most of your recipients use, and each of them asks for the same minimum: SPF and DKIM in place, a DMARC record of at least p=none, and the From domain aligned with one of them.
| Provider | Applies to | What it asks for |
|---|---|---|
| Gmailsince February 2024 | 5,000+ messages a day to Gmail personal accounts | SPF and DKIM, a DMARC record at p=none or stronger, and the From domain aligned with SPF or DKIM. Mail that fails is filtered or refused. Spam complaints must stay under 0.3%, and marketing mail needs one-click unsubscribe. Requirements |
| Yahoosince February 2024 | 5,000+ messages a day to Yahoo accounts | The same set: SPF, DKIM, DMARC at p=none or stronger, and alignment. Yahoo announced its requirements jointly with Google and applies the same bar. Requirements |
| Outlook, Hotmail and Livesince May 2025 | 5,000+ messages a day to Microsoft consumer mailboxes | SPF and DKIM passing, plus DMARC at p=none or stronger aligned with one of them. Microsoft routes non-compliant mail to Junk first, then refuses it outright with 550 5.7.15. Requirements |
The thresholds count messages per day to that provider's own consumer mailboxes, not your total send volume, so a list that skews towards Gmail can cross Google's line long before it looks like bulk sending internally. Below the threshold none of this is enforced, but the same authentication is what keeps ordinary business mail out of the spam folder, and the record costs nothing to publish.
The step most domains stop on
p=none, p=quarantine and p=reject, explained
DMARC is the only one of the three records that does nothing until you raise it. Publishing it is step one of three, and a record left on the first step protects exactly as much as no record at all.
p=none · Monitor
Nothing is blocked. Reports arrive so you can see every system sending as your domain, including the ones nobody remembers.
p=quarantine · Spam folder
Mail that fails DMARC is delivered to the spam folder rather than the inbox. Real enforcement, with a safety net.
p=reject · Blocked
Mail that fails DMARC is refused at the door. This is the only setting that actually stops someone spoofing your domain.
The risk in moving up the ladder is never the spoofers. It is the forgotten invoicing tool nobody remembered was sending as you.
That is what the reports are for, and it is why the order matters: publish p=none with a working rua address, leave it for two to four weeks, and read what comes back. The reports name every system sending under your domain, including the ones that predate everyone currently employed. Fix each legitimate sender so it passes SPF or DKIM with alignment, then move to quarantine, then to reject.
Two tags quietly undo this. pct= applies your policy to only a share of failing mail, so p=reject; pct=10 lets nine tenths of the spoofed mail through. sp=none protects the apex and leaves every subdomain open, which is precisely where a spoofer goes next. This checker reports the policy that is actually applied rather than the one the record appears to state.
Thirty seconds
How the DMARC checker works
Enter your domain
The domain that appears in the From address of your mail, for example example.com. A full URL or an email address works too.
We read _dmarc
The tool queries live DNS for the TXT record at _dmarc.yourdomain.com, and if there is none it follows the same fallback a receiver does, up to your organizational domain.
We check the reporting addresses
For every rua and ruf address outside your own domain, we look up the authorisation record that RFC 7489 requires at the far end, because without it no receiver will send your reports there.
Read the verdict
You get the policy that is actually applied to this exact name, every tag in plain language, the state of each reporting address, and each fault worth fixing.
Two honesty notes about that second step. Working out your organizational domain means knowing where a registrable name begins, which is what the Public Suffix List is for; this tool carries a trimmed copy of it, so it names the domain it fell back to and you can see whether the answer came from the record you expected. And DKIM is never guessed at here: signing keys live at selectors that DNS cannot list, so no checker can prove a domain has none. Your SPF record is read in the same pass, because a policy of reject on a domain with neither SPF nor DKIM fails your own mail.
Or do it yourself
How to check a DMARC record from the command line
DMARC lives in a plain TXT record, so any DNS client can read it. Swap in your own domain, and keep the _dmarc. prefix: querying the domain on its own returns your SPF record and no DMARC at all, which is the usual reason people conclude they have none.
dig +short TXT _dmarc.example.comnslookup -type=TXT _dmarc.example.comResolve-DnsName -Type TXT _dmarc.example.comWhat comes back is the raw record and nothing else: no policy in plain language, no check that the reporting addresses can receive anything, and no organizational-domain fallback if you happen to query a subdomain. That is the gap the tool above fills.
Read your record
Every DMARC tag, and what it does
The whole surface of DMARC is eleven tags defined by RFC 7489 §6.3. Two of them are required, one more is required in practice, and the rest are defaults you rarely need to touch. Note that v=DMARC1 is the one case-sensitive value in the record: the §6.4 grammar spells it out character by character, so v=dmarc1 is discarded while p=Reject is perfectly legal.
| Tag | Needed | What it does |
|---|---|---|
| v | Required | The version. Must read exactly v=DMARC1, in capitals, and must come first. |
| p | Required | The policy for the domain: none, quarantine or reject. A record without it is discarded. |
| rua | Strongly advised | Where daily aggregate reports are sent. Without it you are enforcing blind. |
| sp | Optional | A separate policy for subdomains. When absent, subdomains inherit p, which is usually what you want. |
| adkim | Optional | DKIM alignment: r (relaxed, default) or s (strict). Strict breaks most sending platforms. |
| aspf | Optional | SPF alignment: r (relaxed, default) or s (strict). Same warning as adkim. |
| pct | Optional | The share of failing mail the policy applies to, 0 to 100. Everything else is delivered as if you had no policy. |
| ruf | Optional | Where per-message forensic reports go. Few receivers send them, because they can contain message content. |
| fo | Optional | Which failures trigger a forensic report. Only meaningful alongside ruf. |
| ri | Optional | The requested reporting interval in seconds. The default is 86400, and most receivers send daily regardless. |
| rf | Optional | The forensic report format. afrf is the only one in general use. |
What usually breaks
The three faults worth knowing
A policy that blocks nothing
By far the most common state, and it is easy to mistake for protection because the record exists and the reports arrive. Receivers deliver failing mail exactly as they would if you had published nothing. It is a starting point, not a destination.
Reports going nowhere
A rua address at a vendor or agency needs an authorisation record on THEIR domain before receivers will send anything (RFC 7489 §7.1). Missing it fails silently: the dashboard just stays empty, and nothing anywhere says why.
Subdomains left open
p=reject with sp=none protects the apex and nothing else. Spoofers read DMARC records, so an unprotected subdomain is the obvious next move. Unless a subdomain has to fail DMARC, drop sp and let it inherit.
Copy the closest one
Example DMARC records for the four common cases
Most domains are in one of these four situations. Each record below is complete and legal as written: change example.com to your domain and point the reporting address at a mailbox somebody reads.
Starting out
v=DMARC1; p=none; rua=mailto:dmarc@example.com
The first record any domain should publish. Nothing is blocked and the reports start arriving, which is what you need before you can safely block anything.
Mid-rollout
v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:dmarc@example.com
Reports are clean and failing mail now goes to spam rather than the inbox. sp= is stated explicitly so subdomains move with the apex rather than being forgotten.
Full enforcement
v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc@example.com
Every sender is authenticated and aligned. Strict alignment is only safe once you have confirmed no platform signs or bounces on a subdomain of its own.
A domain that never sends
v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc@example.com
A parked or purely defensive domain. Nothing legitimate can break, so publish the strictest policy there is on day one rather than working up to it.
Publish whichever fits as a TXT record with the host set to _dmarc, then run it back through the checker above: it will tell you what receivers now apply, and whether the reporting address you chose can actually receive anything. If SPF and DKIM are not in place yet, do those first: how to set up SPF, DKIM and DMARC walks through all three from scratch.
The silent failure
Why your DMARC reports never arrive
A record with a rua address looks monitored. Whether anything is actually sent to it depends on a record published by somebody else, on a domain you do not control, and nothing anywhere tells you when it is missing.
If your reporting address is at another organization, that organization has to authorise it before a single report is sent.
RFC 7489 §7.1 requires the destination domain to publish a TXT record at yourdomain._report._dmarc.theirdomain containing v=DMARC1. Until it exists, receivers must not send your reports there. Every DMARC platform publishes it for its customers, usually a wildcard covering all of them, but only once your domain has been added on their side. Miss that step and the dashboard simply stays empty. This checker queries that exact name for every external address in your record and tells you which state each one is in.
Authorise the external destination
If your rua is at a vendor domain, that vendor has to publish yourdomain._report._dmarc.theirdomain containing v=DMARC1. Every DMARC platform does this for its customers, but only once you have added your domain in their console. This checker tests it for you.
Confirm the record is on _dmarc
A DMARC record published on the root of the domain is invisible: receivers only ever read _dmarc.yourdomain.com. Some DNS panels append the domain automatically and some do not, which is how records end up at _dmarc.yourdomain.com.yourdomain.com.
Expect a day, and only from senders with volume
Aggregate reports are daily, not immediate, and a receiver only reports on domains it actually sees mail from. A quiet domain gets few reports, which is normal rather than a fault.
Point rua at something that can parse XML
Aggregate reports arrive as gzipped XML attachments, several a day from every large receiver. A shared mailbox works for a week and then stops being read. Either use a DMARC platform or route the address into a parser.
One more thing worth knowing before you go looking for a fault: §6.6.3 means a subdomain with no record of its own is not unprotected. Receivers fall back to your organizational domain and apply its sp tag, or its p tag when there is no sp. You do not need a record on every subdomain, and publishing one on each is how policies drift apart.
Once the policy is right
Or keep cold outreach off the domain entirely
The reason a domain stays on p=none is usually fear of blocking its own mail. Cold outreach is the biggest single source of that fear, and it does not belong on the domain you get paid on. SmartReach runs it on separate sending domains, each one authenticated for you.
- Sending domains and mailboxes bought and authenticated in minutes, no IT ticket
- SPF, DKIM and DMARC configured for you, so there is no record to hand-edit
- Warmup, inbox rotation and ESP matching across unlimited sending accounts
- Every address verified free before a campaign sends, so bounces never touch your domain
“This software is focused on the end receiver as much as the user.”Matt McQuin · Co-founder, ColdlyticsEvery rule on this page is checked against RFC 7489, the specification that defines DMARC. Last reviewed .
FREQUENTLY ASKED QUESTIONS
DMARC questions, answered
Stop fixing deliverability one DNS record at a time.
SmartReach buys and authenticates your sending domains and mailboxes with SPF, DKIM and DMARC already in place, then warms them, rotates them, and verifies every address before you send.