DMARC checker

What a DMARC record does

SPF and DKIM each prove something about a message, but neither one checks the address your customer actually sees in the From line. DMARC closes that gap. It asks receivers to confirm that the domain which passed SPF or DKIM matches the From domain (this is called alignment), and it tells them what to do when nothing aligns: deliver anyway, send it to spam, or refuse it. It also asks them to send you reports, so you can see every service sending mail as your domain.

The record is a single TXT record at _dmarc.yourdomain. The current specification is RFC 9989, published in May 2026 as a Standards Track document. It replaces the original DMARC document, RFC 7489, and RFC 9091. The record format didn’t change (it still begins v=DMARC1), but a few tags were removed and a few were added, and this checker follows the new rules.

How to read the results

The checker fetches _dmarc.yourdomain, makes sure there’s exactly one DMARC record, and lists every tag with what it does. If a subdomain has no record of its own, it looks up the parent domains, because receivers apply the parent’s policy to subdomains that don’t publish one. Then it rates the record:

• Fail: no record, more than one record, a record that doesn’t start with v=DMARC1, or an invalid policy. With two records, receivers throw both away (RFC 9989, section 4.10), which is the same as having none.
• Warning: the record works, but the policy is p=none, there’s no rua= address, it uses a removed tag such as pct, it’s in test mode (t=y), or reports go to another domain that hasn’t authorized them.
• Pass: a valid record with an enforcing policy (quarantine or reject) and reporting turned on.

When the fix is mechanical, you get a corrected record to copy. If your policy is p=none, the suggestion shows the next step (quarantine), with a reminder to wait until your reports look clean.

The tags that matter

• p is the policy for the domain: none (monitor only), quarantine (treat failures as suspicious, usually the spam folder) or reject (refuse them). If p is missing but a valid rua is present, receivers treat the record as p=none.
• sp sets a different policy for subdomains. Without it, subdomains get p.
• np is new in RFC 9989: a policy for subdomains that don’t exist, which spoofers like to use. Without it, receivers fall back to sp, then p.
• rua is where aggregate reports go, as a mailto: address. Receivers send them roughly daily, as XML summaries of what they saw from your domain.
• adkim and aspf set alignment. Relaxed (r, the default) accepts any domain in the same organization, so mail.acme.com aligns with acme.com. Strict (s) requires an exact match.
• t is also new: t=y marks the policy as a test so receivers don’t apply it in full. It replaces the old practice of publishing pct=0.

What happened to pct?

The old pct tag asked receivers to apply the policy to only a percentage of failing mail. In practice it was applied unreliably for anything except 0 and 100, so RFC 9989 removed it (Appendix A.6) along with rf and ri, and lists them in the tag registry as historic. Receivers that follow the new standard ignore pct and apply your policy to all failing mail. If your record says pct=100, nothing changes; just remove it. If it says pct=0 or any other value, you were relying on a partial rollout that no longer exists. Use t=y while you test, then remove it.

What a good record looks like

A sensible end state for a domain that sends support replies looks like this:

v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain

Getting there safely takes a few weeks:

1. Publish p=none with a rua address. Nothing changes for delivery.
2. Read the reports. List every service that sends as your domain (your mailbox provider, helpdesk, billing system, newsletter tool) and fix SPF or DKIM for any that fail.
3. Move to p=quarantine and keep watching.
4. Move to p=reject once nothing legitimate is failing.

The RFC itself suggests at least a month at p=none and a similar period at quarantine before publishing reject (section 7.4). It also warns that reject can cause problems for people who post to mailing lists from the domain, so take that slowly if your team does.

Common mistakes, and how to fix each

• Two DMARC records. Usually an old record left behind when a new one was added. Delete one; receivers ignore both until you do.
• The record at the wrong name. It must be at _dmarc.yourdomain, not at the root of the domain. Some DNS panels add the domain for you, so enter just _dmarc as the host.
• Stuck at p=none. Monitoring forever means anyone can still put your domain in the From line. Use the reports to move on.
• No rua address. Without reports you’re tightening the policy blind. Add one, even if it’s a mailbox you only check monthly.
• Reports sent to a third party that hasn’t authorized them. When rua points at a different domain, that domain must publish a record at yourdomain._report._dmarc.theirdomain. Reporting services do this automatically; a personal mailbox at another domain won’t have it.
• Leftover pct, rf or ri tags. Harmless at 100, misleading otherwise. Remove them.
• Strict alignment without a reason. adkim=s or aspf=s breaks services that sign or bounce with a subdomain of yours. Keep relaxed unless you know you need strict.

Why DMARC matters for support email

The big mailbox providers now treat DMARC as a basic requirement for anyone sending at volume. Gmail requires senders of more than 5,000 messages a day to personal accounts to publish DMARC (p=none is enough) and to align the From domain with SPF or DKIM (Gmail sender guidelines). Yahoo asks bulk senders for a DMARC policy of at least p=none that passes (Yahoo best practices). Outlook.com asks the same of domains sending more than 5,000 messages a day and routes mail that doesn’t comply to Junk (Microsoft).

Those thresholds apply to the whole domain, so your support replies inherit whatever your marketing and product email do. There’s also a direct support angle: customers trust email that says it’s from your support team. An enforcing DMARC policy is what stops someone else sending “Your refund is ready, click here” as support@yourdomain.