Check a domain's DMARC record against RFC 9989 (May 2026): policy, reporting, retired tags, and a record generator.
Built & maintained by Pappu Venkata Subbi Reddy, founder of Clacify · Updated October 2026
DMARC Checker shows a domain's DMARC policy, what each part of it means, and what to change. DMARC is the record that tells receiving servers what to do with mail that claims to come from your domain but cannot prove it: deliver it anyway (p=none), send it to spam (quarantine) or refuse it (reject). It is what actually stops other people sending email as you, and it has been mandatory for bulk senders to Gmail and Yahoo since February 2024 and to Outlook.com since May 2025. In May 2026 the standard itself changed: RFC 9989 replaced RFC 7489, the document DMARC had run on since 2015. It retired three tags, added new ones and changed how receivers find a domain's policy. Many records, including those of some of the largest companies, still use the retired tags. This checker follows the new standard: it finds the policy the way receivers now do, explains every tag in plain language, marks retired ones with their replacement, and checks that your reports will actually be delivered.
The checker first queries the TXT records at _dmarc.<domain> and keeps those that begin with "v=DMARC1"; exactly one is required. If there is none, it runs the DNS tree walk from RFC 9989 section 4.10: it removes labels from the left of the domain one at a time and queries _dmarc at each level, stopping at the first valid record. The walk is limited to eight queries, and for a domain with more than eight labels it jumps straight to the last seven, as the standard specifies. The same walk determines the organizational domain, which decides relaxed alignment: a domain whose record says psd=n is itself the organizational domain, one below a psd=y record is too, and otherwise it is the record-holding domain with the fewest labels. This replaces the Public Suffix List that RFC 7489 relied on. The record is parsed into tags. Values are validated against the standard: p, sp and np must be none, quarantine or reject; adkim and aspf r or s; t y or n; psd y, n or u. Tags not defined by RFC 9989 are reported, because receivers ignore them. For each external mailto: report address, meaning one on a different organizational domain, the checker queries <your-domain>._report._dmarc.<their-domain> for a "v=DMARC1" record. That is the authorization a receiver looks for before sending reports elsewhere, defined in RFC 9990. Without it, reports are silently not sent.
| Tag | Meaning | Values | Status |
|---|---|---|---|
| p | Policy for the domain | none, quarantine, reject | Required |
| sp | Policy for existing subdomains | none, quarantine, reject | Current |
| np | Policy for subdomains that do not exist | none, quarantine, reject | New in core standard |
| adkim / aspf | DKIM / SPF alignment | r (relaxed), s (strict) | Current |
| rua | Where aggregate reports go | mailto: URIs | Current |
| ruf / fo | Failure reports and when to send them | mailto: URIs / 0, 1, d, s | Current |
| t | Testing mode: apply one level less | y, n | New, replaces pct |
| psd | Public suffix domain flag | y, n, u | New |
| pct | Percentage of mail to apply policy to | 0-100 | Retired: use t |
| rf / ri | Report format / interval | afrf / seconds | Retired |
When we checked well-known domains in October 2026, GitHub, Microsoft and TCS all still published pct in their DMARC records, five months after RFC 9989 removed it. This is not a security hole: receivers following the new standard simply ignore tags they do not know, and the policy itself still applies. But it shows how slowly DNS records change, and it matters in one case: a record using pct=0 to stage a rollout loses that meaning under the new rules. The direct replacement is t=y, which asks receivers to apply one level less than the stated policy (reject is treated as quarantine, quarantine as none). When you are ready to enforce, remove t or set t=n.
Start with p=none and a rua address. For two to four weeks, read the aggregate reports, which arrive as daily XML files from Gmail, Yahoo, Microsoft and others, or use a reporting service that turns them into charts. They list every server that sent mail as your domain and whether it passed. You will usually find legitimate senders you had forgotten: a billing system, a helpdesk, a CRM. Fix each one by adding it to SPF or, better, turning on DKIM signing with your domain. Then move to p=quarantine, optionally with t=y for a first cautious step, and after another clean period to p=reject. Set sp explicitly if subdomains send mail on their own, and consider np=reject: subdomains that do not exist should never send mail, and attackers like to invent them.
The most common reason is the one this checker tests: reports addressed to another domain need permission from that domain. If example.com sends its reports to reports@dmarc-vendor.example, the vendor must publish a TXT record at example.com._report._dmarc.dmarc-vendor.example. Commercial reporting services do this automatically when you add a domain to your account, but people who send reports to their own second domain often miss it. Other causes are a typo in the mailto: address, a mailbox that rejects large attachments, and expecting failure (ruf) reports: most large mailbox providers do not send those at all, for privacy reasons, so aggregate reports are what you should rely on.
RFC 9989 (May 2026) replaced RFC 7489. The pct tag was retired and replaced by t (testing mode): t=y asks receivers to apply one level less than your policy, the old pct=0 behaviour. The rf and ri tags were also retired. A new np tag sets the policy for subdomains that do not exist, and the psd tag supports public-suffix operators. Policy discovery now uses a DNS tree walk instead of the Public Suffix List. Existing records keep working; retired tags are simply ignored.
p=none meets the minimum Gmail, Yahoo and Outlook require from bulk senders, but it only monitors: mail that fails DMARC is still delivered, so spoofing is not stopped. Use p=none with a rua report address for a few weeks, fix any legitimate senders that fail, then move to p=quarantine and finally p=reject.
Common causes: no rua tag, a typo in the address, or reports sent to an address on a different domain that has not published an authorisation record (yourdomain._report._dmarc.theirdomain). Reporting services publish that record automatically when you sign up; for your own other domains you must add it. The checker tests this for each report address.
As a TXT record at the host _dmarc.yourdomain.com in your DNS provider (for example GoDaddy, Cloudflare or Route 53). The generator shows the exact host name and value to paste.