DMARC Record Checker

Read any domain's live DMARC record and find out what it actually enforces. Most published records enforce nothing, and the record looks identical either way until you read the policy tag.

Free Live DNS lookup Policy and rua reported No signup Runs in your browser

Check a DMARC record

Type a domain. This queries _dmarc on that name, reads the policy, and tells you plainly whether anything is being enforced and whether aggregate reports are being collected. It also reads SPF, DKIM and MX, because DMARC only passes if one of the other two does. Runs against Cloudflare's public resolver. Nothing is stored, nothing is sent to us.

What the checker just read

DMARC does not live at your domain's apex. It lives at _dmarc.yourdomain.com, as a TXT record starting v=DMARC1. The tool above queries that name directly and reports what it finds, including the case most tools skip: whether more than one record is published there.

The policy is the only part that does anything

Three values are possible, and the difference between them is the difference between a security control and a decoration.

p=none enforces nothing. A message that fails both SPF and DKIM alignment reaches the inbox exactly as it would if you had published no record at all. This is monitoring mode, and it exists for a reason: you publish it with a reporting address, read the reports for a few weeks, discover the four sending services you had forgotten about, and then tighten. It is a starting line, not a destination.

p=quarantine tells receivers to treat failing mail as suspicious, which in practice means the spam folder.

p=reject tells receivers to refuse it outright. This is the only value that actually stops someone sending mail that appears to come from your domain.

In our audit of 156 lead generation agencies, 64 sat at p=none and 18 published nothing at all. Fifty-three percent of an industry that sends email professionally enforces nothing on its own domain.

No rua means you are flying blind

The rua tag names an address that receives aggregate reports: daily XML summaries from Gmail, Microsoft, Yahoo and others listing every IP that sent mail claiming to be you, and whether it passed. This is the entire feedback loop. Without it you have no way of knowing which of your own services are misaligned, and no way of knowing whether tightening the policy would break something.

A record with p=none and no rua is doing no work of any kind. Nothing is blocked and nothing is measured. Thirty-nine of the 156 agencies we audited published a DMARC record with no reporting address.

If you set one thing today, set this.

Alignment: adkim and aspf

DMARC passes when SPF or DKIM passes and the domain it passed for aligns with the domain in the visible From address. Alignment is what closes the hole SPF leaves open on its own.

Both tags default to relaxed, written r, which accepts a subdomain match: mail from news.yourdomain.com aligns with yourdomain.com. Strict, written s, requires an exact match. Relaxed is right for almost everyone. Strict is worth it only when you control every sender and want to stop subdomain abuse.

pct and sp, the two tags people forget

pct= applies your policy to a percentage of failing mail. Setting p=quarantine; pct=25 is the safe way to start enforcing: a quarter of failing messages get quarantined, the reports show you what broke, and you raise the number as confidence grows. It is the closest thing DMARC has to a dimmer switch.

sp= sets the policy for subdomains. If you publish p=reject; sp=none, you have protected your main domain and left every subdomain wide open, which is precisely where domain abuse tends to happen. Unless you have a reason, leave sp unset so subdomains inherit the main policy.

Two DMARC records is worse than one bad one

If more than one record is found at the policy location, the specification says the domain is treated as having no DMARC policy at all. Not the first record, not the stricter one. None. Whatever you thought you had published stops applying, and no reports are collected.

Watch also for two mistakes we see repeatedly: a rua written without the required mailto: prefix, which silently prevents any reporting service from sending you anything, and a reporting address on a different domain. Cross-domain reporting requires the receiving domain to publish an authorisation record confirming it accepts reports for yours, and without it most senders drop the reports rather than deliver them.

A rollout that does not break your mail

Publish v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Wait two to three weeks and actually read the reports. Fix any legitimate sender that is failing, usually by adding it to SPF or switching on DKIM signing in its dashboard. Move to p=quarantine; pct=25, then raise the percentage, then to p=reject. The whole path takes about a month of mostly waiting, and every step is reversible in the time it takes DNS to propagate.

Next

DMARC only works if SPF or DKIM does, so check both: the SPF record checker and the DKIM record checker. The SPF, DKIM and DMARC guide explains how the three interact, and the deliverability checker audits the rest of your setup.