DMARC Record CheckerVerify your DMARC policy record is live across all independent global DNS resolvers
- 7 independent networks
- Records + DNS flags
- No ads, no sign-up
Independent networks
7 public DNS networks, queried in parallel
Every test query is answered by these unaffiliated resolvers on separate networks and infrastructure. When they agree, you can trust the result.
- 8.8.8.8
Google Public DNS
Google LLC · North America
- 1.1.1.1
Cloudflare
Cloudflare, Inc. · Global Anycast
- 94.140.14.14
AdGuard DNS
AdGuard Software Ltd. · Europe
- 45.90.28.0
NextDNS
NextDNS, Inc. · Global Anycast
- 185.222.222.222
DNS.SB
xTom / Layer0 · Europe
- 223.5.5.5
Alibaba DNS
Alibaba Cloud · Asia
- 119.29.29.29
DNSPod
Tencent Cloud · Asia
How it works
A test query for flag propagation check, done right
Most checkers query a single resolver or a set of geographically labelled servers behind the same anycast network. isPropagated queries genuinely independent DNS operators and compares both their records and their response flags.
Enter a domain and run the test query
Type any domain, pick a record type (A, AAAA, CNAME, MX, TXT, NS and more), then run a single test query that fans out to every network at once.
We query independent global networks
Instead of asking one resolver, we ask several unaffiliated public DNS networks in parallel — across North America, Europe and Asia — so no single cache can mislead you.
Compare records and DNS flags
Each network returns its answer plus the DNS response flags (AD, CD, RA, RD, TC). We check that both the records and the flags agree before calling a domain propagated.
Read the propagation verdict
A clear consensus score shows how many networks resolved the record and whether their answers match — so you know the moment a change is live everywhere.
What is a DMARC record and why must it be fully propagated before enforcing policy?
DMARC (Domain-based Message Authentication, Reporting & Conformance) is a DNS-based policy that tells receiving mail servers what to do when a message fails SPF or DKIM authentication: nothing (p=none), quarantine it (p=quarantine), or reject it outright (p=reject). The policy is published as a TXT record at _dmarc.yourdomain.com.
DMARC propagation is especially important when moving from a monitoring policy (p=none) to an enforcement policy (p=quarantine or p=reject). If you update the policy before it has propagated to all resolvers, some receiving servers may still apply the old "none" policy and allow unauthenticated mail through. The transition to full enforcement is only meaningful once all resolvers consistently return the new policy.
DMARC also specifies where aggregate reports (rua=) and forensic reports (ruf=) are sent. After changing report destinations, verify the new _dmarc record has propagated before relying on the new reporting addresses to receive reports.
Using the DMARC preset to check propagation
Click the "DMARC" quick button and enter your domain. The tool automatically queries TXT records at _dmarc.yourdomain.com across 7 resolvers. Confirm all return the same policy value — "p=none", "p=quarantine", or "p=reject" — to ensure consistent enforcement.
The "pct=" tag controls what percentage of messages the policy applies to. During a gradual enforcement rollout (pct=10, pct=50, etc.) it is especially important to verify propagation so the policy change rolls out consistently rather than partially.
FAQ
Common questions about dmarc record checker
What is the recommended DMARC rollout path?
Start with p=none and rua= pointing to a reporting inbox to gather data. Once you can confirm legitimate mail passes SPF and DKIM alignment, move to p=quarantine pct=10, gradually increase pct to 100, then move to p=reject. Verify propagation at each step before proceeding.
How long does DMARC record propagation take?
DMARC is a TXT record at _dmarc.yourdomain.com and propagates on its TTL — typically 3600 seconds (1 hour). After updating, use this checker to confirm all 7 resolvers return the new record before relying on the new policy.
DMARC is set to reject but I am still getting spoofed emails. Why?
p=reject instructs receivers to reject mail that fails DMARC. However, enforcement only works if (1) the DMARC record has fully propagated, (2) the receiving server supports and enforces DMARC, and (3) the spoofed messages actually use your domain in the From: header. Some spoofing techniques use lookalike domains (example.com vs examp1e.com) which your DMARC record cannot prevent.
Do I need DMARC if I already have SPF and DKIM?
SPF and DKIM individually authenticate the sending infrastructure and message signing. DMARC adds the policy layer — it defines what should happen when they fail and requires alignment (the authenticated domain must match the visible From: header). Without DMARC, receivers make their own decisions; with DMARC you explicitly control the outcome.