How this site works

Every tool runs as JavaScript in your browser. When you check a domain, your browser sends the DNS query directly to a public DNS-over-HTTPS resolver (Cloudflare, Google, Quad9 and others listed on the propagation page) and, for registry data, to the RDAP server of the registry via rdap.org.

This site has no backend and keeps no logs. Results are not stored; the link you copy simply contains the domain so the check can be re-run.

Checks follow the RFCs: SPF 7208, DMARC 9989 (obsoletes 7489), DKIM 6376, CAA 8659, DoH 8484. Where a check cannot be done in a browser (port-43 WHOIS, SMTP tests, traceroute) we say so and point to alternatives.

Advertising: pages may show ads outside the result area; links marked “sponsored” earn us a commission. They never influence results.

Who this is for

System administrators and developers who need a fast DNS, SPF, DKIM, DMARC or DNSSEC answer. Marketers and small-business owners who set up email and then met a “message rejected” bounce. You should not need to read an RFC to fix your records, but the explanation should point to the RFC section so you can check it.

How it works

Every tool runs in your browser. Your browser sends the DNS question over HTTPS (DNS-over-HTTPS) directly to a public resolver, or to an RDAP server for registration data, and the page parses the answer. There is no application server in between: we do not proxy, log or store your queries. The domain you check lives in the URL fragment after #, which browsers never send over the network. Details are in the Privacy Policy.

This design has limits. A browser cannot open raw TCP connections, so we cannot do SMTP tests, port scans or classic whois. Where a tool cannot work from a browser, we say so instead of faking a result.

Principles

• Privacy first. No query leaves your browser except to the resolver or RDAP server named on screen.
• Correct over broad. Validators follow the standards: SPF (RFC 7208), DKIM (RFC 6376), DMARC (RFC 9989, obsoletes 7489), CAA (RFC 8659). Explanations cite the section. An SPF checker that miscounts DNS lookups is worse than none.
• Failures are shown. Timeouts, SERVFAIL and NXDOMAIN each get a plain-language line. We do not hide a failed resolver behind an empty result.

How results are verified

Parsers and validators are pure functions with unit tests. The tests run against DNS answers recorded from real resolvers and stored as fixtures, so they are repeatable and never touch the network. Resolvers are added to the propagation checker only after we confirm that they allow browser requests and return correct answers. Some behave differently, and we note that. For example, one resolver truncates large TXT record sets, so its entry is flagged in our data.

Editorial policy for guides

Guides are written from official sources only: RFCs and the documentation of the mail or DNS provider concerned. Each guide lists its sources at the end. Provider details such as SPF include hosts come from that provider’s own documentation, not from forums. We explain trade-offs, for example the risk of moving DMARC to p=reject before every legitimate sender is aligned. Some pages carry ads or labelled “sponsored” links; they never sit inside a result and do not change what a check reports.

Resolvers

Questions or corrections: see Contact.