DMARC Checker

Finds the DMARC record at _dmarc, validates its tags, and explains what your policy actually tells receivers to do with spoofed mail, with the record text as evidence.

Your browser queries these services directly, so the name you look up and your IP address are visible to them: Cloudflare DNS and Google Public DNS (both public recursive resolvers) for records and comparison, and rdap.org, a redirector that forwards to the registry's RDAP server, for registration data. DevDome does not proxy, see or store these lookups. Privacy policy.

Run a lookup to get an evidence-based summary: web resolution, delegation, DNSSEC, email records, CAA and expiration, each with the observation behind it.
Enter a name above to query common DNS records (A, AAAA, CNAME, MX, TXT, NS, SOA, CAA) from a public recursive resolver, or pick a specific type including DS, DNSKEY, SRV, TLSA, SVCB and HTTPS.
Registration data appears here via RDAP: registrar, creation and expiration dates, EPP status codes, nameservers and DNSSEC delegation state.
SPF and DMARC analysis appears here: record syntax, the 10-DNS-lookup limit, policy strength and common misconfigurations, with the exact records as evidence.
Compares one record type between Cloudflare and Google. These are observations from two public recursive resolvers, not proof of global propagation. Add an expected value above to check whether your change is visible to each.

The policy that decides what spoofing costs

Anyone can put your domain in an email From header; DMARC is the only mechanism that lets you publish what should happen when they do. The checker above fetches the record at _dmarc for your registrable domain, parses every tag, and grades the substance, not just the syntax: a missing p tag invalidates the record, p=none is labeled as monitor-only rather than protection, multiple records cancel each other out entirely, and a missing rua address means you are flying blind on who sends as you.

DMARC only works on top of the other two legs: SPF authorizes your sending servers and DKIM signs your messages, and DMARC enforces alignment between them and your visible From domain. Check all three together; the Email tab above shows SPF alongside DMARC for exactly that reason.

DMARC FAQ

What does a DMARC record do?

DMARC, published as a TXT record at _dmarc.yourdomain.com, tells receiving servers what to do with mail that claims to be from your domain but fails SPF and DKIM alignment: deliver it anyway (p=none), send it to spam (p=quarantine) or refuse it (p=reject). It also requests reports, which is how you find out who is sending as your domain, legitimately or not.

Is p=none pointless?

No, it is step one. p=none enforces nothing, but combined with a rua reporting address it turns every major receiver into a sensor telling you which servers send as your domain and whether they authenticate. The standard rollout is p=none with reports for a few weeks, fix every legitimate sender the reports reveal, then move to quarantine and finally reject. Staying on p=none forever is the actual mistake: it advertises that spoofing your domain has no consequences.

What is the rua tag and why does this checker flag it when missing?

rua=mailto:address requests aggregate reports: daily XML summaries from receivers showing every source IP that sent mail as your domain and how it authenticated. Without it, DMARC gives you no visibility at all: you are enforcing (or not) blind. Because raw XML is unreadable at volume, most teams point rua at a report-processing service rather than a human mailbox.

Why does DMARC exist when SPF and DKIM already authenticate mail?

Two gaps. First, SPF and DKIM verify technical identifiers that recipients never see; DMARC requires alignment between those identifiers and the From address a human actually reads, which is what phishing spoofs. Second, before DMARC there was no way to tell receivers what to do on failure, so they each guessed. DMARC closes both: alignment plus an explicit published policy.

Do subdomains inherit my DMARC policy?

Yes, unless overridden: receivers look for a record at the exact subdomain first, then fall back to the organizational domain’s policy. The sp tag sets a separate policy for subdomains, useful when the apex is at p=reject but a subdomain still needs monitoring. This checker queries _dmarc at the registrable domain, the record that provides the inherited default.