What this tool does
This tool looks up DNS records for any domain over DNS-over-HTTPS, decomposing record types that have internal structure rather than showing raw text: MX records are shown with their priority and sorted lowest-first (the order mail servers are actually tried in), SOA records are split into their primary nameserver, admin email, serial number, and timing fields, and TXT records are automatically checked for SPF and DMARC syntax and broken down into their individual mechanisms or tags when recognized. You can query a single record type or all of them at once, and compare Cloudflare's and Google's public resolvers side by side to see whether they currently agree — useful for checking whether a recent DNS change has finished propagating.
Why record-type-specific parsing matters
An MX record's raw value is just a number and a hostname separated by a space, like 10 mail.example.com. — readable enough on its own, but a domain with several mail servers is easier to understand sorted by priority than in whatever order a resolver happened to return them. SOA data is denser: seven fields packed into one string, and the second field specifically (the admin contact) is encoded as a domain name rather than a normal email address — admin.example.com. decodes to admin@example.com, with the first unescaped dot marking the split point. This tool decodes that directly instead of leaving you to do the translation by hand.
Reading SPF and DMARC records
SPF and DMARC are both published as ordinary TXT records, and SPF is identified purely by its content — a record starting with v=spf1 is an SPF record, wherever it's published. DMARC needs one more thing: content starting with v=DMARC1 is DMARC-shaped, but DMARC policy discovery (RFC 9989 §4.5) only ever looks at names starting with _dmarc. — a record with perfectly valid DMARC syntax published anywhere else would never actually be found or used as a policy. This tool checks every TXT record it finds against both patterns; for a DMARC-shaped one, it also checks the record's own name and labels it "DMARC-like" instead of "DMARC" when the name doesn't start with _dmarc., rather than presenting content that merely looks right as if it functioned as one. When a pattern matches, this tool breaks the record down: SPF into its individual mechanisms (ip4, include, a, mx, and so on, including the optional CIDR suffix RFC 7208 allows on a and mx specifically) each with its qualifier (pass, fail, softfail, or neutral), and DMARC into its tags (policy, reporting addresses, and alignment modes) with a short description of what each one controls — including flagging any tag that's no longer part of the current DMARC specification (RFC 9989, published May 2026). Three tags from the previous specification — pct, rf, and ri — are registered as historic rather than current: this tool still shows their raw published value (a record containing one isn't rejected outright), but labels them explicitly as no longer processed, since RFC 9989 doesn't define any current meaning for them. DKIM records are trickier to identify this way — a DKIM record's meaning comes from being published at a specific selector._domainkey.example.com hostname, not from its content alone, and the v=DKIM1 tag that would let this tool recognize one by content is technically optional, so some real DKIM records won't be tagged even when this tool correctly shows their raw TXT value.
Comparing resolvers to check propagation
DNS changes don't appear everywhere at once — each record has a TTL (time to live) that controls how long a resolver is allowed to cache the old value, and different resolvers around the world cache independently of each other. Querying both Cloudflare's and Google's public resolvers for the same domain and comparing the results is a quick, practical way to see whether a recent change has fully propagated: if both agree, it likely has (at least as far as these two resolvers are concerned). If they disagree, that's often a sign one of them is still serving a cached answer from before the change — but not the only possible explanation: geographic or CDN-based answers, resolver-specific policy, load balancing, and DNSSEC-related differences can all produce a real, non-error disagreement between two resolvers even with no change in progress at all. This tool compares the two resolvers' answer sets directly (owner name, record type, and a type-aware normalized value — not the raw text, so e.g. a hostname's capitalization or an IPv6 address written in expanded vs. compressed form don't produce a false "disagree") rather than just their TTLs or answer order, since a resolver returning the same records in a different order, or with a different remaining TTL, isn't a real difference either way.
DNSSEC validation status
When a resolver validates a response's DNSSEC signatures successfully, it sets the AD (Authenticated Data) flag in its reply — this tool surfaces that flag directly rather than leaving it buried in the raw response. An AD flag of "not set" doesn't necessarily mean anything is wrong: it just as often means the domain (or its parent zone) isn't signed with DNSSEC at all, which is still the majority case across the internet. It's a useful signal specifically when you already expect a domain to be DNSSEC-signed and want to confirm the resolver is actually validating it.
Frequently asked questions
Why don't I see any results for a record type I expect?
Not every domain publishes every record type — a domain without email doesn't need an MX record, for example. An empty result usually just means that record type isn't configured, not that something is broken.
I just changed my DNS. Why does the old value still show up?
DNS changes propagate on their own schedule based on each record's TTL and caching along the resolution path. A resolver may cache a value briefly even after you've updated it upstream — give it some time, or use "Compare both" to check whether the two resolvers already disagree, which can be an early sign a change is spreading (though resolver-specific behavior can also cause disagreement unrelated to a recent change, so it's a useful signal, not a definitive diagnosis).
Why is my domain rejected before the lookup even runs?
This tool validates the domain name's basic syntax (label length, allowed characters, overall length) before sending a query, per RFC 1035/1123 — catching a typo immediately is more useful than waiting for a resolver to fail on it. If your domain uses non-ASCII characters (an internationalized domain name), convert it to its Punycode form (starting with xn--) first — this tool doesn't do that conversion for you.
Can I look up DKIM records with this?
You can look up the TXT record directly if you know the selector — DKIM records are published at a hostname like selector._domainkey.example.com, so enter that full hostname (not just the base domain) as the domain to look up, with TXT as the record type. This tool will show the raw value, and label it DKIM automatically if the record includes the optional v=DKIM1 tag.
What does the "DNSSEC validated (AD)" badge actually confirm?
It confirms the resolver you queried validated this response's DNSSEC signature chain successfully — it's the resolver's own claim, reflected directly from its response, not an independent verification this tool performs itself. If DNSSEC validation matters for your use case, cross-check with a resolver you trust or a dedicated DNSSEC validation tool.
How is this different from a full DNS propagation checker?
This tool queries two resolvers (Cloudflare and Google) for a fast, practical read of current DNS data and whether they currently agree. A dedicated propagation checker instead queries many resolvers across many regions worldwide to show a fuller picture of how a change is spreading — more thorough right after a major DNS change, less necessary for routine lookups.
Last reviewed: . Methodology: domain validation follows RFC 1035/1123 label and length rules (with the RFC 1034 §4.3.3 wildcard exception for a leftmost "*" label). DNS queries are sent over HTTPS using Cloudflare's and Google's own provider-specific JSON APIs \u2014 not a single IETF-standardized format; RFC 8484 defines DNS-over-HTTPS using the binary DNS wire format specifically, and the JSON shape these two providers happen to share isn't itself an IETF standard and could in principle vary between providers. Record data within that JSON is parsed per RFC 1035 §5.1 (presentation-format text and escaping). SPF parsing follows RFC 7208; DMARC parsing follows the current specification, RFC 9989/9990/9991 (which obsoleted RFC 7489 in May 2026) \u2014 including that specification's tag changes (the "p" tag is now optional rather than required, and "pct"/"rf"/"ri" are no longer part of the current spec, though this tool still parses and displays them from older published records, labeled as historical rather than current). The record-type-specific parsers (MX, SOA, TXT) and the IPv6 address canonicalization used when comparing resolvers are cross-checked against Python's dnspython and ipaddress libraries on synthetic fixtures \u2014 not live DNS queries, since this tests deterministic string-parsing logic, which has one correct answer regardless of what's actually published in DNS at any given moment. Verified against hand-picked edge cases and randomized property tests in addition to the cross-check.