Skip to content
StoutNook
Menu
Every tool runs in your browser. Your files never leave your device.

DMARC checker

Enter a domain to see its DMARC record and what it tells receiving mail servers to do with email that fails checks. Every tag is explained, along with how to move safely from monitoring to a stricter policy.

Public DNS lookup. Only the domain and record names (such as _dmarc.example.com) are sent, to Cloudflare's DNS resolver.

You'll see the DMARC policy, every tag in plain English, where reports go, and the next step toward p=reject.

  • Looks up public DNS records only
  • Free, no sign-up
  • Works on phone and desktop

How to check a DMARC record

  1. 1

    Type your domain, such as example.com, or a subdomain you send mail from.

  2. 2

    Click Check DMARC. If a subdomain has no record, we look for the one it inherits.

  3. 3

    Read the policy and every tag in plain English, and check where your reports go.

  4. 4

    Follow the next step on the path from p=none to p=reject.

Features

  • Every tag explained

    p, sp, np, pct, rua, ruf, adkim, aspf, fo, rf and ri in plain English, with the changes made by the new DMARC standard noted.

  • Report addresses checked

    Spots rua addresses missing mailto: and outside report services that haven't authorized your reports.

  • Path to p=reject

    Shows where you are between monitoring and full protection, and what to do next.

  • Public DNS only

    Only DNS names are looked up, through Cloudflare. No sign-up and nothing stored.

What DMARC does

SPF and DKIM each prove something about a message, but neither checks the From: address people actually see. DMARC (Domain-based Message Authentication, Reporting and Conformance) closes that gap. A message passes DMARC when SPF or DKIM passes for a domain that aligns with the From: domain: under the default relaxed alignment, the domains must share an organizational domain, so mail.example.com aligns with example.com.

Your DMARC record then tells receivers what to do with mail that fails, and asks them to send you reports. Those reports are the only way to see every service that sends mail using your domain, including ones you've forgotten and ones pretending to be you.

DMARC was first published as RFC 7489 in 2015. In May 2026 the IETF replaced it with RFC 9989, on the Standards Track this time, plus RFC 9990 for aggregate reports and RFC 9991 for failure reports. Records still start with v=DMARC1, so existing records keep working.

How to read a DMARC record

v=DMARC1; p=quarantine; sp=reject; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r
TagMeaning
pPolicy for the domain: none, quarantine or reject. Required.
sp / npPolicy for subdomains, and (newer) for subdomains that don't exist.
rua / rufWhere to send aggregate and failure reports, as mailto: addresses.
adkim / aspfAlignment: r relaxed (default) or s strict.
pctShare of failing mail the policy applies to. Removed in RFC 9989.
fo, rf, riFailure report options, format and interval. rf and ri were removed in RFC 9989.
t, psdNew in RFC 9989: test mode, and a flag for registries.

In the example, mail from example.com that fails DMARC goes to spam, mail from any subdomain is rejected, and daily reports go to a mailbox at the same domain.

Moving safely from p=none to p=reject

  1. Monitor. Publish v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com and read the reports for a few weeks.
  2. Fix your senders. For every legitimate service in the reports (your mailboxes, newsletter, invoicing, help desk), set up DKIM with your own domain, and SPF where the service supports a custom return path.
  3. Quarantine. Change to p=quarantine and keep watching the reports.
  4. Reject. When nothing legitimate fails, change to p=reject.

Older guides suggest ramping up with pct=10, then 50, then 100. RFC 9989 dropped pct because receivers applied in-between values inconsistently, so step between policies instead.

Common DMARC mistakes

  • No mailto:. rua=dmarc@example.com is invalid; it must be rua=mailto:dmarc@example.com.
  • Two records at _dmarc. Receivers then ignore DMARC completely.
  • Reports to an unauthorized domain. If example.com sends reports to mailto:reports@dmarc-service.example, that service must publish a TXT record v=DMARC1 at example.com._report._dmarc.dmarc-service.example. Report services do this when you add your domain to your account.
  • Jumping straight to p=reject before every sending service is aligned, which blocks your own invoices or newsletters.
  • sp=none next to a strict p=, which leaves every made-up subdomain open to spoofing.

Subdomains and the organizational domain

If you check a subdomain such as news.example.com and it has no record of its own, receivers fall back to the record of the organizational domain, example.com. This checker walks up one level at a time, as RFC 9989 describes, and stops at the registrable domain. It recognizes common two-part endings such as co.uk and com.au with a built-in list rather than the full Public Suffix List, so results for unusual endings may differ from a receiver's.

Gmail and Yahoo requirements

Since February 2024, Google and Yahoo have required bulk senders (for Gmail, anyone sending 5,000 or more messages a day to personal Gmail accounts) to publish a DMARC record with at least p=none, to align the From: domain with SPF or DKIM, to support one-click unsubscribe, and to keep spam complaints below 0.3%. Every sender needs SPF or DKIM. Check those with the SPF checker and DKIM checker, and confirm where your domain receives mail, including your report mailbox, with an MX lookup.

Frequently asked questions

What is a DMARC record?

A TXT record at _dmarc.<your domain> that tells receiving mail servers what to do with mail that claims to come from your domain but fails authentication, and where to send reports. It starts with v=DMARC1 and was defined in RFC 7489, now replaced by RFC 9989.

Is p=none enough?

It meets the minimum Gmail and Yahoo set for bulk senders in 2024, and it's the right way to start, because the reports show who sends mail as your domain. But p=none doesn't stop anyone: receivers deliver failing mail as normal. Move to quarantine and then reject once your real mail passes.

What's the difference between quarantine and reject?

With p=quarantine, receivers treat failing mail as suspicious, which usually means the spam folder. With p=reject, they refuse it during delivery, so it never reaches the recipient. Reject is the end goal; quarantine is the safe step before it.

Why am I not getting DMARC reports?

Check that rua uses mailto: in front of the address, that the mailbox accepts large attachments, and, if the address is on another organization's domain, that the domain has published an authorization record. Reports usually arrive once a day per receiver, and only from receivers that send them.

Do subdomains need their own DMARC record?

No. A subdomain without a record uses its organizational domain's record, with the sp= policy if there is one and p= otherwise. Give a subdomain its own record only when it needs a different policy or different reports.

Does DMARC need both SPF and DKIM?

A message passes DMARC if either SPF or DKIM passes for a domain aligned with the From: address. Set up both anyway: SPF breaks on forwarding, and Gmail and Yahoo require both from bulk senders.

More free tools