What you are looking at
Each query goes to a public recursive resolver, which either answers from its cache (the TTL shown is the time left in that cache) or asks the authoritative servers for the zone. That is why two resolvers can disagree after a change: one still holds the old record until its TTL runs out. The resolver comparison makes this visible; when both agree with what you expect, the change has propagated as far as most of the Internet is concerned. Full propagation is simply “every cache has expired”, so lowering the TTL a day before a change is the only way to make it fast.
Record types in brief
| Type | Holds | Typical check |
|---|---|---|
| A / AAAA | IPv4 / IPv6 address | does the site point at the right server |
| CNAME | alias to another name | cannot coexist with other records at the same name; never at the zone apex |
| MX | mail servers with priority | lowest number is tried first; the target must have an A/AAAA, not a CNAME |
| TXT | free text: SPF, DMARC, DKIM, site verification | exactly one SPF record |
| NS | authoritative name servers | must match what the parent zone delegates to |
| SOA | zone parameters: serial, refresh, retry, expire, minimum | serial goes up on every change; minimum is the negative-cache TTL |
| CAA | which certificate authorities may issue | Let’s Encrypt needs issue "letsencrypt.org" or no CAA at all |
| SRV | service location: priority, weight, port, target | _sip._tcp, _xmpp-client._tcp, _minecraft._tcp |
| DS / DNSKEY | DNSSEC chain of trust | DS in the parent must match a KSK in the zone; the AD flag shows validation succeeded |
| HTTPS / SVCB | service binding: ALPN (h2, h3), ECH, IP hints | what Cloudflare publishes for HTTP/3 and Encrypted Client Hello |
| TLSA | DANE certificate pinning | mostly for SMTP between mail servers |
SPF and the 10-lookup limit
An SPF record lists who may send mail for the domain. Every include:, a, mx, ptr, exists and redirect= term costs the receiving server a DNS lookup, and RFC 7208 caps the total at ten, counted through every nested include. Go over it and receivers return permerror, which DMARC treats as a failure, so mail from a domain with too many includes starts landing in spam the day a provider adds one more include to their own record. The chain view resolves each include and shows the running total; the usual fix is replacing include: with the provider’s ip4: ranges or dropping senders you no longer use. Includes that resolve to no SPF record count as “void lookups”, limited to two.
DMARC and DKIM
DMARC lives at _dmarc.domain and says what to do when neither SPF nor DKIM aligns with the From address: p=none monitor, p=quarantine spam folder, p=reject bounce. DKIM public keys live at selector._domainkey.domain; the selector is in the s= tag of the DKIM-Signature header of any message you send, so look there if you do not know it. Common selectors: google (Google Workspace), selector1/selector2 (Microsoft 365), k1 (Mailchimp), default, mail, dkim.
Questions
Why do Cloudflare and Google give different answers?
Caching. One resolver fetched the record before your change and keeps it until its TTL expires; the other fetched it after. Wait for the old TTL to run out, or lower the TTL before the next change. If they still disagree after that, your authoritative name servers may be out of sync with each other (compare the SOA serial on each).
Why is there no record when I know it exists?
Check the exact name: www.example.com and example.com are different names. A CNAME at the name hides other types. If the status is NXDOMAIN the name does not exist at all; NOERROR with no answers means the name exists but has no record of that type.
What does the DNSSEC (AD) flag mean?
The resolver validated the answer against the DNSSEC chain of trust and it checked out. If the zone is signed and the flag is missing on both resolvers, the DS record in the parent may not match the zone’s key (a classic after a DNS provider move), which makes the domain unreachable for validating resolvers.
Is this the same as dig or nslookup?
Close. dig +dnssec example.com MX @1.1.1.1 asks the same resolver the same question. This page uses the resolvers’ DNS-over-HTTPS endpoints so it can run in a browser; it cannot query your own name servers directly, so to check authoritative answers use dig @ns1.yourdns.com.
Why is the SPF lookup count different from another tool?
Tools differ on whether they count the redirect= modifier, nested includes, and a/mx terms with explicit arguments. This page follows RFC 7208 section 4.6.4: include, a, mx, ptr, exists and redirect all count, at every level of nesting; ip4, ip6 and all are free.