Free DMARC Record Checker
Enter a domain above and the DMARC checker reads the TXT record at _dmarc.yourdomain.com, parses every tag and reports whether the policy is valid. What it cannot tell you is whether that policy is the right one, which is the part this page covers: most domains that fail DMARC in practice have a perfectly valid record set to a policy that does nothing.
How to Read a DMARC Record
DMARC lives at a fixed name: the subdomain _dmarc under the domain it protects. Here are three live records, which between them show the whole range:
$ dig +short TXT _dmarc.google.com
v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com
$ dig +short TXT _dmarc.microsoft.com
v=DMARC1; p=reject; pct=100; rua=mailto:itex-rua@microsoft.com;
ruf=mailto:itex-ruf@microsoft.com; fo=1
$ dig +short TXT _dmarc.paypal.com
v=DMARC1; p=reject; rua=mailto:d@rua.agari.com,mailto:dmarc_agg@vali.email;
ruf=mailto:d@ruf.agari.com,mailto:MTc4Mzcw@ruf.vali.emailAll three sit at p=reject, which is the destination. Two tags are required and the rest are optional.
| Tag | What it does |
|---|---|
v=DMARC1 | Required. Must be the first tag, or the record is not a DMARC record at all. |
p= | Required. The policy for the domain itself: none, quarantine or reject. |
rua= | Where aggregate reports are sent. Optional in the spec, essential in practice: without it you are flying blind. |
ruf= | Where forensic reports are sent. Many receivers never send these, and they can carry message content, so treat them as optional. |
sp= | Policy for subdomains. When absent, subdomains inherit p=. |
pct= | Percentage of failing mail the policy applies to. A ramp control, not a permanent setting. |
adkim= / aspf= | Alignment strictness, r for relaxed (default) or s for strict. |
fo= | Which failures generate forensic reports. fo=1 means any failure rather than only a total one. |
Every tag is covered in full in the DMARC record reference with policy and roll-out roadmap.
A Valid Record at p=none Protects Nothing
This is the finding that matters most on this page. A checker will report p=none as a valid, correctly formed DMARC record, and it is. It also instructs receivers to take no action whatsoever on messages that fail. Domains sit at p=none for years, pass every checker they run, and remain exactly as spoofable as a domain with no DMARC record at all.
p=none is a monitoring mode and it has a real purpose: it turns on aggregate reporting so you can discover every system sending as your domain before you start rejecting anything. It is meant to be a phase, not a destination. The signal that you have stalled in it is simple: if you have been at p=none for more than a couple of months and cannot say what your reports show, the record is decorative.
| Policy | What receivers do | When it is right |
|---|---|---|
p=none | Nothing. Deliver as normal and send you reports. | Weeks one to eight, while you inventory your senders. |
p=quarantine | Deliver failing mail to spam. | Once reports are clean and you want a reversible first enforcement step. |
p=reject | Refuse failing mail at the door. | Once quarantine has produced no surprises. This is the destination. |
The move between the last two is the one people hesitate over longest, and the trade-offs are set out in DMARC reject versus quarantine, and when to move.
Alignment Is What DMARC Actually Adds
SPF and DKIM both existed long before DMARC and both had the same hole: neither looks at the From address your recipient reads. SPF validates the envelope Return-Path. DKIM validates whichever domain signed the message. Either can pass while the visible From says something else entirely, which is precisely the trick DMARC was built to stop.
DMARC passes when SPF or DKIM passes and the domain it validated aligns with the From domain. One of the two is enough. This is why a domain can show spf=pass in the headers and still fail DMARC, which looks contradictory in a report and is not.
A subdomain aligns with its parent. Mail from mail.example.com aligns with a From of example.com. This is what you want in almost every case, and it is what you get if you set nothing.
adkim=s or aspf=s requires an exact domain match. Set either without auditing first and every ESP that signs on a subdomain starts failing. Turn it on deliberately or not at all.
What the Checker Reports, and What Each Result Means
| Result | What it means |
|---|---|
| No record found | Nothing at _dmarc.yourdomain.com. Receivers apply no DMARC policy, and SPF or DKIM passing means nothing about your From domain. |
Valid, p=none | Correctly formed and enforcing nothing. Read the section above. |
| Two DMARC records | As with SPF, receivers do not choose between them. The policy is discarded entirely and you are effectively unprotected. |
v=DMARC1 not first | The record is ignored. Tag order is only enforced for the version tag, and this is the one that catches people. |
No rua= | Technically valid, practically useless. Without aggregate reports you cannot ever safely raise the policy, so the domain stays at p=none forever. |
pct= below 100 | Fine during a ramp, a problem if forgotten. p=reject; pct=10 reads as enforcement and rejects one failing message in ten. |
| Record on the wrong name | Published at the root instead of _dmarc, or with the domain appended twice by a control panel that adds it for you. The record exists and no receiver will ever find it. |
How to Check DMARC Without a Tool
$ dig +short TXT _dmarc.google.com v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com $ nslookup -type=txt _dmarc.google.com $ host -t TXT _dmarc.google.com
The _dmarc prefix is mandatory and is the single most common publishing mistake: many DNS panels append the domain automatically, so typing the full name into the host field produces _dmarc.example.com.example.com. Always verify with a lookup after publishing rather than trusting the panel’s confirmation. The same commands applied to other record types are in the MX record lookup guide and the DNS records reference.
What a DMARC Check Cannot Tell You
A record check reads DNS. It does not observe a single real message, and every question that matters is about real messages.
Only aggregate reports show which of your senders pass and which fail. That is what rua= is for, and it is why a record without it cannot be safely raised.
Forwarders, mailing lists and one forgotten invoicing tool are what break. They show up in reports, never in a record.
DMARC protects the exact domain in the record. An attacker on a domain that merely resembles yours publishes their own DMARC and passes.
That last point is the limit most often misunderstood, and it is expanded in why most phishing now authenticates cleanly and in the email spoofing reference.
DMARC Checker FAQ
How do I check my DMARC record?
Enter your domain in the checker above. Manually, run dig +short TXT _dmarc.yourdomain.com. The _dmarc prefix is part of the name, not an option, and a lookup on the bare domain will never find the record.
Is p=none good enough?
No, if the goal is protection. p=none tells receivers to do nothing about messages that fail, so your domain remains as spoofable as one with no record. It is the correct starting point because it switches on the reports that let you move forward safely, but a domain that has sat there for a year has a record rather than a policy.
Why does my mail fail DMARC when SPF passes?
Because DMARC requires alignment, not just a pass. SPF validates the envelope Return-Path domain, which on many sending platforms is the platform’s own domain rather than yours. It passes on their domain, that domain does not match your From, and DMARC fails. The usual fix is a custom Return-Path on a subdomain of yours, or getting DKIM signing on your own domain, since either one satisfies DMARC on its own.
Do I need both SPF and DKIM to pass?
No. DMARC passes if either one passes with alignment. Configuring both is still worth doing, because they fail in different situations: SPF breaks on forwarding, DKIM survives it, and having only one means every message that trips that one mechanism fails DMARC entirely.
Where do I put the DMARC record?
As a TXT record on the host _dmarc. In most DNS panels you type _dmarc in the name field and the panel appends your domain. If you type the full _dmarc.example.com into a panel that also appends, you end up with the record on _dmarc.example.com.example.com, which no receiver will ever query. Verify with a lookup afterwards.
What should a first DMARC record look like?
Version, a monitoring policy, and an address that will actually receive the reports: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Nothing else is needed on day one. The point of that record is to start the reports flowing so you can raise the policy later with evidence rather than hope.
Related Free Tools
DMARC Record Generator to build your first policy · SPF Record Checker · DKIM Record Checker · SPF Record Generator · DKIM Record Generator
