DMARC Checker

Find a domain's DMARC record, validate its syntax and see what receivers will do with spoofed mail.

DMARC record checker

DMARC tells receiving mail servers what to do with messages that claim to be from your domain but fail SPF or DKIM: deliver, send to spam or reject. This checker finds the _dmarc record (or the parent domain's record when a subdomain has none), validates every tag, counts how many records are published and shows which policy actually applies to the domain you entered.

p, sp and np policies: what happens to spoofed mail

Falls back to the parent domain when a subdomain has no record

Syntax errors: p, pct, adkim, aspf, fo, unknown tags, duplicate records

rua/ruf report addresses and external destination authorization

How to Use

Enter a domain or an e-mail address — we take the part after @
Review the score, the effective policy and the findings
Fix the DNS record, then check SPF and DKIM with the links above the result

FAQ

It is a TXT record at the _dmarc name of your domain, e.g. _dmarc.example.com, with a value like v=DMARC1; p=none; rua=mailto:address. It sets the policy for mail that fails authentication and where to send reports. There must be exactly one.

Start with none plus a rua address: collect reports for a few weeks and make sure every service that sends as you passes SPF or DKIM. Then move to quarantine (optionally with pct below 100), and to reject once legitimate mail stops failing. Jumping straight to reject is risky: mail from services you forgot about will stop arriving.

DMARC needs alignment: the From domain must match the domain that passed SPF (the return-path) or the d= domain of the DKIM signature. If your email service signs with its own domain and uses its own return-path, SPF and DKIM pass but DMARC fails. Set up DKIM for your own domain in that service.

Not if the main domain's policy suits it: subdomains without their own record get the main domain's sp tag (or p if sp is absent). Publish a separate record only when the subdomain needs a different policy or different report addresses.

Since February 2024 Google and Yahoo require every sender to use SPF or DKIM, and bulk senders to have SPF and DKIM, a DMARC record of at least p=none and a From domain aligned with SPF or DKIM. Thresholds and details change — check the current Google and Yahoo sender guidelines.

How to read the DMARC check result

The DMARC checker queries the TXT record at the _dmarc. name of your domain. If a subdomain (say news.example.com) has no record of its own, the tool walks up to the parent domain — exactly what a receiving mail server does — and shows the policy that actually applies. Every tag is then validated, and you get a 0–100 score, the record itself, the p and sp policies, pct, the alignment mode and a list of findings ordered by severity.

What you see	What it means
Score 0, "no record found"	No DMARC: receivers decide on their own what to do with spoofed mail, and you get no reports
Two or more v=DMARC1 records	Per RFC 7489, DMARC is not applied at all — as if there were no record
p=none	Monitoring mode: reports arrive, spoofed mail is still delivered
p=quarantine	Mail failing DMARC goes to the spam folder
p=reject	Such mail is refused at SMTP time — the strongest protection

Points are deducted for a weak policy, for pct below 100, for unprotected subdomains (sp=none under a strict p), for a missing rua report address and for external report destinations that have not authorized your domain.

DMARC record syntax: every tag

A record is a list of tag=value pairs separated by semicolons. The version always comes first:

v=DMARC1; p=quarantine; sp=reject; pct=100; rua=mailto:[email protected]; adkim=r; aspf=r; fo=1

v=DMARC1 — required and must be first. Without it the TXT record is not a DMARC record.
p — policy for the domain itself: none, quarantine or reject. Required.
sp — policy for subdomains. If absent, p applies.
pct — the share of failing mail the policy applies to (0–100, default 100). The rest gets the next weaker treatment, which is handy for a gradual rollout.
rua — where aggregate reports go (XML, usually daily). Several addresses can be separated by commas.
ruf and fo — per-message failure reports and when to send them (0, 1, d, s). Large mailbox providers rarely send them.
adkim, aspf — alignment: r (relaxed, default) or s (strict).
ri, rf — report interval and format; rarely changed in practice.

The revised DMARC specification (DMARCbis) drops pct, ri and rf and adds np (policy for non-existent subdomains), psd and t. The checker understands both sets. Receivers silently ignore what they do not recognise, so a typo like p =reject or [email protected] without mailto: quietly breaks the record.

Alignment: why DMARC fails while SPF and DKIM pass

DMARC passes only when SPF or DKIM passes for the same domain as the visible From address. SPF checks the return-path (envelope) domain, DKIM checks the d= domain in the signature. If an email service sends with a return-path like bounce.esp-mail.com and signs with its own domain, both checks pass and DMARC still fails.

With relaxed alignment (r) the organizational domains only need to match, so mail.example.com aligns with example.com. Strict (s) needs an exact match. The fix is to set up your own domain in every sending service: DKIM signing with your domain (verify it with the DKIM checker) and, where offered, a custom return-path subdomain.

Rolling out DMARC without losing mail

Make sure SPF and DKIM cover every service that sends as your domain: office mail, CRM, newsletters, the website, the help desk.
Publish a monitoring record: v=DMARC1; p=none; rua=mailto:[email protected]. Reports are XML files; an aggregator service makes them readable.
After 2–4 weeks, review the reports: which IPs send as you and whether they align. Unknown sources are either forgotten services or spoofing.
Move to p=quarantine (you can start at pct=25 and raise it), then to p=reject.
Lock down domains that never send mail right away: v=DMARC1; p=reject, SPF v=spf1 -all and a null MX.

Sending reports to another domain

When rua points to an address in a different domain (a reporting service, for example), receivers check that the destination agrees to accept them by looking up a TXT record at example.com._report._dmarc.destination.com with the value v=DMARC1. Reporting services usually publish it themselves; if reports go to another domain you own, add it manually. The checker tests this for each external destination.

Gmail, Yahoo and sender requirements

Since February 2024 Google and Yahoo require every sender to authenticate with SPF or DKIM, and bulk senders to have both SPF and DKIM, a DMARC record of at least p=none, and a From domain aligned with SPF or DKIM. Thresholds and details change over time, so check the current Google and Yahoo sender guidelines. A p=none record meets the requirement on paper but does not stop spoofing — treat it as the starting point, not the goal.

Where to edit the DMARC record

Wherever the rest of the domain's DNS lives: your registrar, host or Cloudflare. Type TXT, name _dmarc (the panel appends the domain; for a subdomain use _dmarc.news), value — the whole record. Keep exactly one record: when changing the policy, edit the existing one instead of adding a second. After saving, wait for the TTL to expire and run the check again; the DNS propagation checker shows when resolvers pick it up.