DMARC Checker

Check any domain's DMARC record the way a receiving mail server reads it: where the policy is found, what happens to mail that fails, whether reports reach anyone, and what SPF and DKIM need before you enforce.

Sources: the domain's _dmarc TXT records and its parents', through Google Public DNS (Cloudflare 1.1.1.1 behind it) · RFC 9989 tree walk · report authorization per RFC 9990 · SPF and DKIM from our own checkers · nothing about you is stored

How do I check a DMARC record?

Type a domain above: the checker asks DNS for the TXT record at _dmarc. plus the domain, walks up to the organizational domain when there is none (RFC 9989 §4.10), and shows what a receiving server does with mail that fails.

By hand, ask for the same name: dig +short TXT _dmarc.paypal.com, or nslookup -type=TXT _dmarc.paypal.com on Windows. One answer starting with v=DMARC1 is the record; two answers mean receivers use neither (RFC 9989 §4.10).

dig stops there. It doesn't walk up from a subdomain, check whether report addresses accept the reports, or tell which RFC a receiver follows. That's what the checker adds.

% dig +short TXT _dmarc.example.com

Every answer at the name. One starting v=DMARC1 is the record.

What dig shows, and what it doesn't

terminal

$ dig +short TXT _dmarc.paypal.com 1

"v=DMARC12; p=reject; rua=mailto:d@rua.agari.com,mailto:dmarc_agg@vali.email; ruf=mailto:d@ruf.agari.com,mailto:MTc4Mzcw@ruf.vali.email3"

$ dig TXT _dmarc.mail.google.com | grep status 4

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN

1The name is _dmarc. plus the domainNot the domain itself: a TXT at paypal.com is SPF's place.
2One record, v=DMARC1 firstTwo records at one name: receivers discard both (RFC 9989 §4.10).
3Tags, separated by ;p is the policy; rua and ruf say where reports go.
4Nothing here? Walk up_dmarc.mail.google.com is NXDOMAIN: google.com's record applies.

paypal.com's record as Google Public DNS returned it on October 24, 2026; mail.google.com has none of its own.

Reading the result: the receiver's view

The answer comes first, as a sentence. Under it, the evidence: the record as receivers parse it, each tag coloured over its exact characters, and on navy the path a receiving server takes for this domain, ending in what it does with mail that fails.

No score: a policy at none is a phase, not a failure, and the ladder under the path says what the next step needs.

DMARC check of paypal.com: rejects mail that fails DMARC, with the receiver's view and the enforcement ladder — A DMARC check of paypal.com: the verdict, the record split into its tags, the receiver's view with every DNS question and what happens to failing mail, and the enforcement ladder. Select a number to see what each part shows.

What is DMARC used for?

DMARC tells receiving mail servers what to do with mail that uses your domain in the From: line but can't prove it came from you, and where to send reports about it (RFC 9989 §4.7).

The proof is SPF or DKIM, aligned with the From: domain: SPF passing for a bounce domain in the same organization, or a DKIM signature with d= your domain. One aligned pass is enough (RFC 9989 §5.3.5); everything else fails DMARC, and the record's policy decides: deliver, spam folder or reject.

Reports are the other half. Receivers that honour rua send a daily summary of every server that sent as your domain, which is how you find the legitimate senders you forgot before you enforce.

Two messages, one From: line

From: billing@example.comp=reject · rua=mailto:dmarc@example.com

Your invoice, sent through an email servicevia a service set up with custom DKIM, so it signs with d=example.com

SPFpass · bounces.esp.example (not aligned)
DKIMpass · d=example.com (aligned)
DMARCpass: one aligned result is enough

Delivered

A forged invoice from 203.0.113.9a server example.com never authorized

SPFfail · 203.0.113.9 isn't listed
DKIMnone · no signature
DMARCfail → p=reject

Rejected

550 5.7.1 Email rejected per DMARC policy for example.com

Tomorrow's aggregate report to dmarc@example.com: 1 message from 203.0.113.9, SPF fail, DKIM none, disposition reject.

A pass doesn't promise delivery (the receiver's filters still decide), and a fail at p=reject is a request, not a command (RFC 9989 §5.4, §7.4). Addresses from RFC 5737; the reply text is RFC 9989's own example.

DMARC record tags explained

A DMARC record is a list of tag=value pairs in a TXT record at _dmarc. plus the domain: v=DMARC1 first, then the policy, alignment and reporting tags in any order (RFC 9989 §4.7).

RFC 9989 (May 2026) replaced RFC 7489. It added np, psd and t, and removed pct, rf and ri: current receivers ignore those, while receivers still on RFC 7489 read them, so a record with pct=25 means different things to different receivers.

Tags you don't publish take their defaults, and the checker shows those too: a missing sp means subdomains get p.

Every tag, by what it does

v=DMARC1; p=reject; sp=quarantine; np=reject; adkim=r; aspf=r; rua=mailto:dmarc@example.com; ruf=mailto:forensic@example.com; fo=1

VersionPolicyTest and suffixAlignmentReportsRemoved

Tag	What it sets	Default	Status	Seen in
v	VersionDMARC1	required, first	RFC 9989	192
p	Policy for the domainnone · quarantine · reject	none if missing and rua is valid	RFC 9989	192
sp	Policy for existing subdomainsnone · quarantine · reject	p	RFC 9989	39
np	Policy for names that don't existnone · quarantine · reject	sp, then p	new in RFC 9989	2
t	Test mode: one step below the policyy · n	n	new in RFC 9989	0
psd	Public suffix (y) or organizational domain (n)y · n · u	u	new in RFC 9989	1
adkim	DKIM alignmentr · s	r	RFC 9989	20
aspf	SPF alignmentr · s	r	RFC 9989	24
rua	Where aggregate reports gomailto:…	no reports	RFC 9989	186
ruf	Where failure reports gomailto:…	no reports	RFC 9989	120
fo	When to send failure reports0 · 1 · d · s	0	RFC 9989	96
pct	Share of failing mail the policy applies to0–100	–	removed	70
rf	Failure report formatafrf	–	removed	9
ri	Report interval, seconds86400	–	removed	14

Seen in: how many of 192 DMARC records published by 196 well-known domains carry the tag (read October 24, 2026; 69 of the 70 pct tags say pct=100). Defaults and status from RFC 9989 §4.7 and Appendix C.

DMARC policy: p=none vs quarantine vs reject

p=none asks receivers to deliver failing mail as usual and only report it; quarantine asks them to treat it as suspicious, usually the spam folder; reject asks them to refuse it during the SMTP conversation.

None is a phase, not a failure: RFC 9989 §7.4 suggests at least a month there with reports flowing, and as long again at quarantine, before reject. Domains whose people post to mailing lists should stop at quarantine.

Big mailbox providers split it too: gmail.com and outlook.com publish p=none for the domain itself and sp=quarantine for subdomains, while google.com, yahoo.com and microsoft.com publish reject.

Where a forged message ends up

Deliveredp=none

apache.orggmail.comsamsung.com

23 of 192

Spam folderp=quarantine

github.comapple.comamazon.com

30 of 192

Rejectedp=reject

google.compaypal.commicrosoft.com

139 of 192

Receivers decide in the end: they may deliver mail that fails at p=reject, and must not reject on the policy alone (RFC 9989 §5.4, §7.4). A vendor study shows how far the wider web is behind: across the top 1.8 million domains in early 2026, EasyDMARC found 29.2% at p=none and 22.9% at quarantine or reject.

Is DMARC really necessary?

Yes, if you send to Gmail, Yahoo or Outlook.com in bulk: all three require a DMARC record, and p=none is enough to meet the rule. Enforcement (quarantine or reject) is what stops other people sending as your domain, and BIMI logos need it.

Gmail has required it since February 1, 2024 of senders of more than 5,000 messages a day to Gmail accounts; Yahoo since February 2024, without naming a volume; Outlook.com since May 5, 2025, above 5,000 a day. Without a record, Gmail answers 4.7.31 (and 4.7.32 when From: isn't aligned), and Outlook.com rejects with 550 5.7.515.

For a domain that sends nothing, DMARC is the cheapest protection there is: p=reject, a null MX and v=spf1 -all, as example.com publishes (M3AAWG).

What each mailbox provider asks of bulk senders

GmailFeb 1, 20245,000+ a day to Gmail accounts4.7.31 · 4.7.32

YahooFeb 2024no threshold publishedDMARC must pass

Outlook.comMay 5, 20255,000+ a day550 5.7.515

Deliveredp=nonemeets all three providers' rule

Spam folderquarantinestops most spoofing · BIMI logos possible

Rejectedrejectstops spoofing at the door · BIMI

✓Required: a record, p=none or stricteriProtection: quarantine or reject

From each provider's own sender pages, read October 24, 2026. A spam rate under 0.3% and one-click unsubscribe are rules too, but DNS can't show them; the checker's Requirements view says which parts it can prove.

How to fix DMARC failures: forwarding, mailing lists, a vendor's own domain

Find the failing source in your aggregate reports, then fix it at the sender: sign it with DKIM for your own domain, or move it to a bounce domain inside your organization. Three causes cover most failures.

Forwarding keeps the DKIM signature but breaks SPF, so DKIM carries the pass. Mailing lists that edit the message break both. And an email service that signs with its own domain passes DKIM for itself, not for you: turn on its custom DKIM (usually CNAMEs like s1._domainkey) and a custom return path.

Three failures, what the report shows, and the fix

Forwarding

SPF192.0.2.80 isn't in example.com's SPF
DKIMsignature intact

Report showsspf=fail dkim=pass → pass

DKIM-sign everything; DKIM survives forwarding. ARC (RFC 8617) helps forwarders vouch.

Mailing list

SPFthe list's server sends
DKIMbody changed: hash fails

Report showsspf=fail dkim=fail → fail

Lists that rewrite From: fix it; domains whose people post to lists stay at quarantine (RFC 9989 §7.4).

A vendor's own domain

SPFpass for bounces.esp.example: not aligned
DKIMpass for esp.example: not aligned

Report showsdkim=pass(esp.example) → fail

Turn on the vendor's custom DKIM: paypal.com's s1 and s2 are CNAMEs to SendGrid, which signs as paypal.com.

Addresses from RFC 5737; esp.example is a placeholder. The SendGrid CNAMEs are paypal.com's real selectors (October 24, 2026).

DMARC for subdomains: sp and np

A subdomain without its own record gets its organizational domain's policy: sp for subdomains that exist, np for names that don't, each falling back to p (RFC 9989 §4.7).

A subdomain that publishes its own record uses it for itself. But a record between a name and its organizational domain is never used for that name: berkeley.edu's tree shows it, where eecs.berkeley.edu's sp=none doesn't reach www.eecs.berkeley.edu (RFC 9989 §4.10.1).

np is the cheap win: names that don't exist send no real mail, so np=reject blocks forgeries from them even while p is still at none. Receivers on RFC 7489 don't know np and use sp.

berkeley.edu's tree, as a receiver reads it

berkeley.edup=reject; np=reject; psd=n; rua=…its own record · psd=n: the organizational domainRejected

www.berkeley.eduno recordexists → sp, absent → pRejected

eecs.berkeley.edup=reject; sp=none; rua=…its own record → pRejected

www.eecs.berkeley.eduno recordwalk: eecs.berkeley.edu's record is skipped (not the organizational domain) → berkeley.edu's pRejected

nosuch-x7.berkeley.eduNXDOMAINdoesn't exist → npRejected

eecs.berkeley.edu's sp=none is never applied: a record between a name and its organizational domain isn't used for it (RFC 9989 §4.10.1). The checker flags it as a record that isn't used.

Read October 24, 2026 through Google Public DNS. nosuch-x7.berkeley.edu is a made-up name; its NXDOMAIN is real.

Reading DMARC reports (rua)

An aggregate report is a daily XML file from each receiver that lists every server that sent mail as your domain, how many messages, and whether SPF, DKIM and DMARC passed (RFC 9990).

Read it by source: your own servers and services should show an aligned pass; a known service failing needs its custom DKIM; an unknown address failing at p=reject is spoofing, stopped. A report service (dmarcian, Valimail, EasyDMARC, Postmark and others) turns thousands of files into that list; the DMARC Report Analyzer does it in your browser, without uploading them.

Reports to an address in another domain only arrive if that domain agrees: it publishes yourdomain._report._dmarc.its-host with v=DMARC1 (RFC 9990 §4). The checker asks for you, and gives the exact record when it's missing.

One report, read line by line

<org_name>google.com</org_name>1

<date_range>Oct 23, 00:00 UTC – Oct 24, 00:00 UTC</date_range>

<policy_published>example.com · p=reject</policy_published>2

<source_ip>198.51.100.24</source_ip> <count>412</count> dkim=pass spf=fail → none3

<source_ip>203.0.113.9</source_ip> <count>37</count> dkim=fail spf=fail → reject4

1Who reportedOne file per receiver per day (RFC 9990: at least every 24 hours).
2The policy it foundWhat it read at _dmarc.example.com.
3Forwarded mail, saved by DKIMSPF failed at the forwarder; the aligned signature passed DMARC.
4Spoofing, stoppedAn unknown server, nothing aligned, refused.

paypal.comrua=mailto:d@rua.agari.comrua.agari.compaypal.com._report._dmarc.rua.agari.com TXT "v=DMARC1;"✓ authorized: reports flow

Report services the checker recognisesdmarcianValimailEasyDMARCPostmarkCloudflareMimecastProofpointAgariRed SiftPowerDMARC+6 more

The XML is shortened and made up (documentation addresses, RFC 5737); the authorization record is paypal.com's real one, read October 24, 2026.

DMARC checker: frequently asked questions

What is DMARC?

DMARC is a DNS record that tells receiving mail servers what to do with mail that uses your domain in the From: line but fails DMARC alignment, meaning neither SPF nor DKIM passes for a matching domain: deliver it, quarantine it or reject it. It also names where receivers send reports about that mail. It is published as a TXT record at _dmarc plus your domain and is defined by RFC 9989, which replaced RFC 7489 in May 2026.

What does a DMARC record checker show?

It does a DMARC record lookup: it reads the TXT record at _dmarc plus the domain, and its parents' when there is none, the way a receiver does. This one shows the record tag by tag with its defaults, the policy for the domain, its subdomains and names that don't exist, whether report addresses accept the reports, and the domain's SPF record and DKIM keys, without a score.

How do I test DMARC?

Check the domain above for the published policy: that is the DMARC test DNS can answer. For DMARC verification of a real message, send one to a mailbox you control and read its Authentication-Results header, or paste the headers into the Email Header Analyzer. A DMARC validator checks the record's syntax; only a message shows whether SPF or DKIM aligned.

Which DMARC policy should I start with?

Start with p=none and a rua address, so receivers send you daily reports without changing delivery. Fix every legitimate sender that fails, usually by turning on its custom DKIM, then move to quarantine and finally reject. RFC 9989 suggests at least a month at p=none and as long again at quarantine. A domain that sends no mail can go straight to p=reject.

Does p=none protect my domain?

No. p=none asks receivers to handle failing mail as usual, so a forged message is judged only by their own spam filters. What it does give you is reports, and it meets the Gmail, Yahoo and Outlook.com bulk-sender rule. Treat it as a monitoring phase: protection starts at quarantine, and reject stops forged mail before it reaches anyone.

What does t=y mean in a DMARC record?

t=y is RFC 9989's test mode: receivers apply one level below the published policy, so p=reject acts as quarantine and p=quarantine as none. It has no effect on p=none and doesn't change reports. Receivers still on RFC 7489 don't know the tag and apply the policy as written. Remove t=y once your reports show every legitimate sender aligned.

Is the pct tag still used?

RFC 9989 removed pct, along with rf and ri, because values other than 0 and 100 were applied inconsistently. Current receivers ignore it and apply the policy to all failing mail. Receivers still on RFC 7489 sample: pct=25 at quarantine sends a quarter of failing mail to spam and delivers the rest. pct=100 is harmless; for a test phase, use t=y.

Why is my rua address "not authorized"?

When reports go to a mailbox in another organizational domain, that domain must agree by publishing a TXT record named yourdomain._report._dmarc.its-host with the value v=DMARC1 (RFC 9990 §4). Without it, receivers that check skip the address. The record goes in the destination's DNS, not yours: report services publish a wildcard for every customer, so this usually means a typo or a partner's mailbox.

Do subdomains need their own DMARC record?

Usually not. A subdomain without a record gets its organizational domain's policy: sp for subdomains that exist, np for names that don't, both falling back to p. Publish one on a subdomain only when it needs a different policy. A record on an in-between name, like team.example.com for www.team.example.com, isn't used for the deeper name.

What happens if a domain publishes two DMARC records?

Receivers discard both, so no DMARC policy applies and no reports are sent, even if one of the two says reject (RFC 9989 §4.10). It usually happens when a new record is added without deleting the old one, or when a DNS host adds a default. Keep one record at _dmarc and delete the other; the checker shows which looks intended.

Why does DMARC fail when SPF passes?

DMARC needs SPF to pass for a domain that aligns with the From: address. Most email services send with their own bounce domain, so SPF passes for them, not for you, and it doesn't count. The same goes for DKIM signed with the service's domain. Set up the service's custom DKIM or custom return path so the passing domain is yours.

The checker shows no record, but I just added one. Why?

Check the host field first: most DNS panels want only _dmarc, and typing _dmarc.example.com there creates _dmarc.example.com.example.com. Then wait for the old answer to expire: if the name was looked up before, resolvers keep its NXDOMAIN for the zone's negative TTL, often 5 minutes to an hour. A SERVFAIL or timeout shows as "couldn't check", never as no record.