Every domain name lookup — opening a website, sending an email, checking whether a server you set up is actually reachable — starts with a DNS query most people never see directly. This tool makes that query explicit: enter a domain and see exactly what its DNS records say, including the two records email deliverability actually depends on (SPF and DMARC), checked at the specific locations mail servers actually look for them.
What each record type actually tells you
A and AAAA records are the core of DNS — the IPv4 and IPv6 addresses a domain resolves to, what a browser is really asking for every time you type a URL. CNAME points one hostname at another instead of at an IP directly, commonly used for a www subdomain pointing at the root domain, or a subdomain pointing at a third-party service. MX records say which mail servers handle email for the domain, each with a priority number — lower numbers are tried first. NS records name the domain's authoritative nameservers, which is really an answer to "who controls this domain's DNS," independent of who registered the domain itself. SOA carries the zone's administrative metadata — the primary nameserver, an admin contact, and timing values that control how long a secondary nameserver waits before re-checking for changes. CAA restricts which certificate authorities are allowed to issue TLS certificates for the domain, a defense against a misissued certificate from an unrelated CA. TXT is a general-purpose free-text record used for almost anything that doesn't fit the other types — domain ownership verification, and, most importantly for deliverability, SPF and DMARC.
Why SPF and DMARC get checked automatically, and separately
SPF and DMARC are both published as TXT records, but they live in different places, which is the single most common reason a correctly-written record doesn't actually work. An SPF record belongs at the domain's own root as a TXT record, and it lists which mail servers are authorized to send email claiming to be from that domain — include: for trusting another domain's own SPF, ip4:/ip6: for trusting a specific address directly, and a closing all mechanism (usually -all or ~all) that decides what happens to anything not explicitly listed. A DMARC record, by contrast, has to be published at _dmarc.yourdomain.com specifically — the DMARC specification defines that exact subdomain as where mail servers look, and a DMARC-formatted record sitting at the root domain instead is simply invisible to anything checking it. This tool queries both locations automatically, parses any SPF record's mechanisms into plain language, and flags clearly when either one is missing from where it actually needs to be.
Forward lookups versus reverse lookups
A forward lookup — the default here — answers "what does this domain point to." A reverse lookup flips the question: given an IP address, what hostname does it resolve back to? Reverse DNS works through a special zone, in-addr.arpa for IPv4, where the IP's octets are reversed and treated as a domain name themselves (1.1.1.1 becomes a lookup for 1.1.1.1.in-addr.arpa). Reverse lookups matter most for email — a receiving mail server commonly checks whether a connecting server's IP has a PTR record at all, and whether it plausibly matches the hostname the server claims, since a missing or mismatched reverse record is a signal many spam filters weight heavily.
Updating a DNS record doesn't make every resolver on the internet see the change instantly — each record carries a TTL (time to live), and resolvers that already cached the old value keep serving it until that TTL expires. A lookup here queries Cloudflare's resolver directly, which may itself be serving a cached answer if the TTL hasn't elapsed since the last time anyone queried that record — if a change isn't showing up yet, that's very often just the TTL window, not a sign the change failed.