DMARC record checker — instant validation against your domain's published policy
Type a domain. The browser queries DNS over HTTPS directly against Cloudflare's 1.1.1.1 resolver and parses the resulting TXT record at _dmarc.yourdomain.com. You see the raw record, the parsed policy, the aggregate and failure report addresses, alignment modes, the subdomain policy, and any syntax or operational issues — including the ones that block Gmail, Yahoo, and Microsoft Outlook from accepting bulk mail under the 2024-2026 sender requirements. No account required, no telemetry, no rate limits; the lookup happens entirely in your browser.
Check a domain
Enter any domain — yours, a competitor's, a vendor you are evaluating. The lookup runs in your browser against Cloudflare's public DNS over HTTPS resolver.
DNS over HTTPS via cloudflare-dns.com · No data sent to our servers
DMARC is the policy layer on top of SPF and DKIM — the place where you tell receiving mailbox providers what to do with mail that fails authentication or alignment
The DMARC record is a single TXT entry at _dmarc.yourdomain.com in your DNS. It is a short policy statement, defined in RFC 7489, that receivers like Gmail, Outlook, and Yahoo read when they evaluate inbound mail claiming to be from your domain. The receiver runs SPF and DKIM checks first; DMARC then asks two further questions. First, did at least one of those checks pass with the domain in the From: header — the alignment requirement that prevents an attacker from passing SPF on their own domain while claiming to be you. Second, what should the receiver do if neither check passed in an aligned way: deliver normally (p=none, monitoring only), route to spam (p=quarantine), or reject outright at SMTP time (p=reject).
The record also tells receivers where to send aggregate reports — the daily XML summaries that show which senders are using your domain and whether they are passing or failing — via the rua tag. A second tag, ruf, requests forensic-level failure reports, though most major receivers stopped sending these in 2017-2018 over privacy concerns. Two alignment-mode tags control whether SPF and DKIM checks need to align strictly (exact domain match) or relaxed (organizational domain match): aspf and adkim, both defaulting to relaxed. A subdomain policy tag sp sets the policy for subdomains; without it, subdomains inherit the parent's policy. A percentage tag pct applies the policy to a fraction of failing mail — useful during enforcement rollouts but a common source of confusion when senders forget it after the rollout completes.
The 2024-2026 enforcement landscape has made the difference between policy levels material. As of February 2024, Gmail and Yahoo require bulk senders (5,000+ messages per day to Gmail accounts) to publish a DMARC record at minimum policy p=none; without one, mail gets rejected. Microsoft Outlook followed in May 2025 with the same threshold and a 550 5.7.15 SMTP rejection code for non-compliant bulk mail. Gmail's Postmaster Tools v2 in October 2025 added a binary "Compliance Status" indicator that reads enforcement-level DMARC (p=quarantine or p=reject) as a stronger trust signal than monitoring-only. The progression from p=none to enforcement is no longer optional for senders trying to maintain inbox placement at scale.
What this means for the typical operator: a working DMARC record is the entry ticket; an enforcement-policy DMARC record with monitoring infrastructure underneath is where actual deliverability protection lives. The checker above will tell you which side of that line your record sits on, and the rest of this page walks through what to fix when it returns issues.
Every tag the checker parses, what it means, and what value you should typically use
Example record at enforcement
v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:forensic@example.com; sp=reject; adkim=s; aspf=s; pct=100; fo=1
v=DMARC1 Version identifier. Always DMARC1. Must be the first tag. Receivers ignore the record if missing or malformed.
p=none | quarantine | reject Policy for failing mail. none = monitor only, quarantine = route to spam, reject = block at SMTP time. The 2024-2026 trust signal scale runs none → quarantine → reject.
rua=mailto:address Where to send aggregate XML reports — the daily summary of authentication results across all senders using your domain. Critical for visibility. Multiple addresses allowed, comma-separated.
ruf=mailto:address Failure (forensic) report destination. Most major receivers stopped sending these around 2017-2018 over privacy concerns. Optional and increasingly ignored — set it if your DMARC platform requires it; do not rely on volume.
sp=none | quarantine | reject Subdomain policy. If omitted, subdomains inherit p. Setting sp=reject while p=quarantine is a common rollout pattern — strict on unused subdomains, gradual on the main domain.
adkim=r | s · aspf=r | s Alignment modes. r (relaxed, default) allows organizational domain match — mail.example.com aligns with example.com. s (strict) requires exact match. Strict catches more spoofing but breaks more legitimate senders that use subdomains.
pct=N (1-100) Percentage of failing mail to which the policy applies. pct=10 with p=quarantine means quarantine 10% of failures, treat the rest as p=none. Used during rollouts; should return to pct=100 at steady state.
fo=0 | 1 | d | s Failure-report options. fo=1 sends a report when either SPF or DKIM fails (most useful). fo=d on DKIM failure only, fo=s on SPF only, fo=0 only when both fail. Default 0 produces too little data for diagnostic use.
The eight problems we see most often when running this check across customer domains
No record published
The most common result on first check. Zero protection, and as of February 2024, blocks delivery to Gmail and Yahoo accounts for bulk senders (5,000+ daily messages). Start with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; to begin monitoring; that gets you visibility into who is sending under your domain before you tighten policy.
Policy stuck at p=none for years
The record exists but the policy never moved off monitoring. Gmail's Postmaster Tools v2 from October 2025 reads enforcement-level DMARC (quarantine or reject) as a stronger trust signal than p=none. If your aggregate reports show clean alignment for known senders for 30-90 days, move to p=quarantine; pct=10, then ramp pct up over 4-8 weeks, then to p=reject.
Multiple DMARC records
Two or more TXT records at _dmarc.yourdomain.com. Per RFC 7489, this causes receivers to treat the policy as undefined and skip enforcement entirely. Usually happens when a security tool adds a record without removing the old one. Consolidate into a single record.
Syntax errors
Missing semicolons, invalid tag values, wrong version string, malformed email in rua. Receivers parse strictly; a single syntax error causes the record to be ignored. The most common error we see is a typo in v=DMARC1 (lowercase v, missing 1, or DMARC2 from someone confusing it with the IETF draft DMARCbis).
No rua address — no visibility
A DMARC record without rua still enforces the policy at receivers, but you receive no aggregate reports. You are flying blind on which legitimate senders are using your domain and whether they pass authentication. Always set rua — to an inbox you actually read, or to a DMARC monitoring platform that parses the XML for you.
External report destination not authorized
If your rua or ruf points to a domain you do not own (a DMARC platform like Postmark, dmarcian, EasyDMARC, or our own monitoring), the receiving domain needs a separate TXT record at yourdomain.com._report._dmarc.theirdomain.com authorizing the cross-domain reporting. Most platforms set this up for you; some require manual configuration.
No subdomain policy on parked or unused subdomains
Without sp, subdomains inherit the parent policy. If your parent is at p=none during a slow rollout, every subdomain — including ones you do not send from but attackers can spoof — is also at p=none. Add sp=reject early; it costs nothing for subdomains you do not use.
Stuck pct value from old rollout
Records with p=reject; pct=10 are common — the team rolled out quarantine, ramped pct, moved to reject, and forgot to bring pct back to 100. Result: only 10% of failing mail actually gets rejected. Restore pct=100 at steady state; you have the policy you wanted only when pct matches.
Running the check is step one. The next steps are aggregate report ingestion, alignment fixes for misbehaving senders, and the rollout to enforcement
A DMARC record on its own does not improve deliverability — it just adds a policy declaration that may or may not be reflected in receiver decisions. The actual work of getting to p=reject safely is: ingesting daily aggregate reports for 30-90 days to see who is sending under your domain, fixing SPF and DKIM alignment for legitimate senders that show up failing (newsletter platforms, transactional ESPs, marketing tools, payroll systems, support ticket software — every domain has a long tail), then ramping pct upward in stages and watching for collateral damage before declaring enforcement.
The tool above gives you the policy snapshot. The longer work is what we do day-to-day for managed customers — aggregate report parsing, sender identification, alignment remediation, and the rollout from monitoring to quarantine to reject without blocking the company's own payroll provider three days before the cycle. If you are running this on your own domain and the result is p=none after years, that is the conversation to have, not the conversation about which DMARC record to publish.
Questions teams ask when they run this check for the first time
Does this tool send my data to your servers?
+
No. The lookup runs entirely in your browser using Cloudflare's public DNS over HTTPS resolver at cloudflare-dns.com/dns-query. The domain you type is sent to Cloudflare's DNS infrastructure — the same query path your browser uses for any DNS lookup — and the response is parsed locally. We never see the query, the result, or any other browsing data. You can verify this in your browser's developer tools network tab; no requests go to authorize-hosting domains during the check.
Is p=none enough to satisfy Gmail and Yahoo's bulk sender requirements?
+
Yes, technically. The February 2024 Gmail and Yahoo announcements set the minimum at "having a DMARC record with at least p=none." Microsoft Outlook followed the same threshold in May 2025. So p=none is the entry ticket; without it, mail to those receivers gets rejected at SMTP time.
The qualifier is that since Gmail's Postmaster Tools v2 launch in October 2025, the binary "Compliance Status" indicator gives a stronger trust signal for enforcement-policy DMARC (p=quarantine or p=reject) than for monitoring. Inbox placement, complaint thresholds, and reputation recovery all factor in. p=none gets you past the door; p=reject with clean aggregate reports gets you the better table.
How long should we stay at p=quarantine before moving to p=reject?
+
Depends on the shape of your sending program, but the typical pattern we see in managed migrations is 30 days at p=none to gather aggregate reports, then a graduated p=quarantine rollout: pct=10 for 1-2 weeks, pct=25 for 1-2 weeks, pct=50 for 2 weeks, pct=100 for 2-4 weeks, then move to p=reject; pct=100. The full rollout from no-DMARC to enforcement is typically 3-4 months. Shorter is possible for senders with simple, well-controlled infrastructure; longer is normal for enterprises with dozens of legitimate sending sources that need alignment remediation.
We have p=reject and we are still seeing spoof attempts get through. How?
+
A few possibilities. First, p=reject only protects against direct domain spoofing — attackers using your exact domain in the From: header. Lookalike domains (your-company.co versus your-company.com, or homoglyph variants) and display-name spoofing (where the visible name says "Your Company" but the From address is attacker@gmail.com) are entirely different attack surfaces that DMARC does not address.
Second, some receivers — particularly small or self-hosted servers, certain mailing list software, and some legacy enterprise gateways — do not enforce DMARC at all, or enforce it inconsistently. Your aggregate reports tell you which receivers honor your policy; the long tail of small receivers may show failures arriving anyway.
Third, DMARC has known interactions with mailing lists and forwarding. A legitimate message forwarded through a mailing list often fails DMARC at the second hop because the list rewrites the body or changes the From. ARC (Authenticated Received Chain) was designed to address this but adoption is uneven. If your reports show DMARC failures correlated with mailing list activity, that is what you are seeing.
Can we use this checker for client domains we don't own?
+
Yes. DMARC records are public DNS records — anyone can query them for any domain. Agencies, MSPs, and consultants run checks like this routinely as part of client onboarding. The checker does not authenticate against the target domain in any way; it just performs a public DNS lookup. The only difference between checking your own domain and a client's domain is that you can act on the result for your own.
What about DMARCbis — the proposed update to DMARC?
+
DMARCbis is the IETF draft that updates RFC 7489 — adding a Public Suffix List-aware lookup for the organizational domain, formalizing tree walking for subdomain resolution, deprecating pct in favor of named percentage rollouts, and tightening report format requirements. As of mid-2026 the draft is still in IETF process; no major receiver has signaled they will require DMARCbis-specific syntax. The version string remains v=DMARC1; do not publish records claiming DMARC2 or DMARCbis — those are not valid and receivers will ignore them.