DMARC checker
A DMARC record is a DNS TXT record published at _dmarc.<domain> that tells receiving mail servers what to do with messages which claim to come from your domain but fail SPF or DKIM alignment. This checker performs that one TXT lookup, shows the record verbatim, and explains each tag: the policy in p=, the separate subdomain policy in sp=, the sampling rate in pct=, the reporting addresses in rua= and ruf=, and the alignment modes in adkim= and aspf=. It flags the four conditions that make a record do nothing — no record at all, a monitoring-only p=none, no aggregate report address, and more than one DMARC record at the name, which RFC 7489 treats as no policy at all.
Run the check
Result
Enter a domain to run the check. Results appear here.
How the check works
One DNS query runs: a TXT lookup at _dmarc. prefixed to the domain you entered. DMARC has no other discovery mechanism — there is no record type of its own and no second location to try. Whatever TXT records exist at that name are returned, and the ones beginning with v=DMARC1 are the DMARC records; RFC 7489 requires the version tag to come first, so a record that mentions DMARC further along is not one.
The tags are then read as semicolon-separated key=value pairs. Only two are mandatory: v= and p=. Everything else has a default, and the defaults matter more than most people expect. Absent adkim= and aspf= both default to relaxed alignment, which means an organisational-domain match is enough — mail signed by mail.example.com aligns with a From address at example.com. Set to strict, the domains must match exactly, which breaks most third-party sending platforms unless they sign with a subdomain you have delegated to them. Absent sp= means subdomains inherit p=; present, it replaces it, and sp=none under an enforcing p= is the gap most often left open by accident, because spoofing is routinely attempted from subdomains that were never created.
A DMARC pass requires more than SPF or DKIM passing. It requires one of them to pass and to be aligned with the domain in the From header the recipient actually sees. This is the whole point of the specification: SPF authenticates the envelope sender and DKIM authenticates a signing domain, neither of which a reader is shown. A message can therefore pass SPF outright and fail DMARC, and that combination is the single most common source of unexplained DMARC failures on a domain that uses a sending platform.
When a lookup times out or the nameserver returns SERVFAIL, this tool says the check was inconclusive rather than reporting that no record exists. Those are different facts, and only one of them is something we observed.
A worked example
v=DMARC1; p=quarantine; sp=reject; pct=100; adkim=s; aspf=r; rua=mailto:dmarc@example.com; fo=1
Read left to right. v=DMARC1 identifies the record and has to come first. p=quarantine asks receivers to file failing mail as suspicious rather than deliver it normally, while sp=reject overrides that for subdomains and refuses their failing mail outright — stricter on subdomains than on the domain itself, which is a deliberate choice because nothing legitimate should be sending from a subdomain nobody set up. pct=100 applies the policy to all failing mail rather than a sample. adkim=s demands an exact DKIM domain match, while aspf=r leaves SPF on relaxed alignment. rua= is where the daily aggregate XML is sent, and fo=1 requests a failure report whenever any underlying check fails.
Questions
- What is a DMARC record?
- A DNS TXT record published at _dmarc.<domain> that tells receiving mail servers what to do with messages that claim to be from your domain but fail SPF or DKIM alignment. It carries a policy (p=none, p=quarantine or p=reject) and, through the rua tag, an address where receivers send daily aggregate reports about mail sent in your name. It is defined by RFC 7489.
- Does p=none do anything?
- It turns on reporting and nothing else. Receivers evaluate DMARC, record the outcome, send you the aggregate report and then deliver the message exactly as they would have anyway. That makes it the right first step, because you learn which of your own senders are failing before you risk blocking them — but a domain sitting at p=none is not protected from spoofing, however long the record has been there.
- Can I publish two DMARC records?
- No. RFC 7489 section 6.6.3 says that if more than one record beginning with v=DMARC1 is found at _dmarc.<domain>, the receiver stops and applies no policy at all. Two records is not a stronger setting than one; it is the same as having none. This checker reports duplicates as a failure for that reason.
- What does pct= actually change?
- It applies your policy to a sample of failing mail rather than all of it. At p=quarantine with pct=50, half the failing messages are quarantined and the other half are treated with the next weaker policy, which is none. It exists so you can ramp enforcement gradually. Left at less than 100 permanently, it means the policy you believe you are enforcing applies to a fraction of the mail.
- Why does my DMARC pass while individual messages fail?
- DMARC requires alignment, not just a pass. SPF can pass on an envelope sender at your sending platform’s own domain while the From header shows yours; DKIM can be signed by the platform’s domain rather than yours. In both cases the underlying check passes and DMARC still fails, because the domain that passed is not the domain the reader sees. The adkim and aspf tags control how exact that match has to be.
- Do I need DMARC to send cold email?
- Google and Yahoo both require a DMARC record on domains that send bulk mail to their users, and the requirement is satisfied by a record at p=none. So the record is not optional, but the enforcement level is a separate decision, and moving straight to p=reject before reading the aggregate reports is how legitimate mail gets blocked.
The rest of the set
SPF checker
Recursive lookup counting against the RFC 7208 limit of ten, plus +all and ptr detection.
DKIM checker
Selector lookup or fourteen common selectors tried at once, with exact key sizes.
Blacklist checker
Domain and MX hosts resolved to IPs, checked against blocklists verified live on every request.
Read further
- DMARC Record: the setup that survives multi-domain sending
- DMARC quarantine vs reject: which policy to run while sending cold email
- How to read a DMARC report without a parser
- SPF, DKIM and DMARC for cold email: the setup that keeps you out of spam
For the economics rather than the DNS, our free calculators cover cost per meeting, cold email ROI and a spam word checker that runs in your browser.
Authentication is the floor, not the plan.
A correct DMARC record stops your domain being spoofed. It does not get a cold email answered — that is a function of who you picked, what you said, and whether the offer was worth a reply. We run the whole programme for clients and are paid on meetings that get attended.