How do you read a DNS lookup result (A, AAAA, CNAME, MX, TXT, NS)?
A DNS lookup result is a list of one specific record type published for a name: A and AAAA return the IPv4 or IPv6 address a hostname points to, CNAME returns an alias to another name, MX returns the mail servers (with a priority number) authorized to receive mail, TXT returns arbitrary machine-readable text such as SPF or verification strings, and NS returns the authoritative name servers that answer for the whole zone — each is a separate record type, so a lookup only ever shows the type you asked for.
By AdminKit team, Netbase JSC · Updated October 29, 2026
DNS is organized by record type, not by domain
A common misconception is that a domain has one DNS “entry” that a lookup reveals all at once. It doesn’t. RFC 1035 defines DNS as a collection of independent resource record (RR) types, each with its own format and its own purpose, and a single name can publish several different types at once — an A record, an MX record and a TXT record can all exist at example.com. simultaneously, as entirely separate records that happen to share a name. A lookup always queries one specific type at a time; AdminKit’s DNS lookup tool queries Cloudflare’s public DNS-over-HTTPS resolver on your behalf and supports A, AAAA, MX, TXT, NS, CAA, PTR, SOA and CNAME, showing each as its own result rather than one combined record.
A and AAAA: the address records
A records (RFC 1035 §3.4.1) map a hostname to an IPv4 address — the most basic DNS record type, and the one that lets a browser turn example.com into a routable address. AAAA records (RFC 3596) do the identical job for IPv6, as a separate record type with a separate four-times-longer address format rather than an extension of A. A domain can publish both at once (a “dual-stack” setup), only one, or several of either type for load distribution or redundancy — a resolver returning multiple A records for one name is normal, not an error, and clients are free to try them in any order.
CNAME: an alias, not an address
A CNAME record (RFC 1035 §3.3.1) doesn’t hold an address at all — it holds another hostname, telling the resolver “look up whatever this other name resolves to instead.” It’s how a domain points www.example.com at example.com, or a custom domain at a hosting platform’s own infrastructure, without needing to track that platform’s IP addresses directly. One important restriction: RFC 1035 does not allow a CNAME to coexist with any other record type at the exact same name, which is why you cannot add, say, a TXT record directly on top of a name that already has a CNAME pointing elsewhere — it has to go on a different name, or the CNAME has to move.
MX: where mail actually goes
MX records (RFC 1035 §3.3.9) list the hostnames authorized to receive mail for a domain, each with a priority (preference) number — lower numbers are tried first. A lookup against example.com for MX type shows these hostnames and priorities but not whether they’re actually reachable; that needs a follow-up A/AAAA lookup on each returned hostname, which AdminKit’s dedicated MX lookup tool does automatically. See what MX record priority actually does for how the priority ordering and ties between equal-priority records work in practice.
TXT: free-form, machine-readable text
TXT records (RFC 1035 §3.3.14) hold arbitrary text, originally meant for human-readable notes but now used almost entirely for machine-readable policy strings: SPF (v=spf1 ...), domain-ownership verification tokens for services like search consoles or cloud platforms, and DKIM public keys published at a selector subdomain. A single name can carry multiple TXT records at once, which is why a DNS lookup on a busy domain’s root name often returns several unrelated-looking text strings — each one belongs to a different system that happens to use the same record type to publish its data.
NS: who’s authoritative for the whole zone
NS records (RFC 1035 §3.3.11) list the nameservers authoritative for an entire zone, not just one name — they answer the question “who do I ask about anything under this domain” rather than describing one specific record. The NS records that actually get used are the ones delegated at the parent zone (set through your registrar), which should match what your DNS provider’s own zone reports about itself; a mismatch between the two is a common, often overlooked cause of DNS changes not taking effect anywhere, since resolvers follow the registrar-level delegation, not your provider’s internal records, to find the zone in the first place.
Reading a result with propagation in mind
Every DNS record carries a TTL (time to live) that controls how long a resolver may cache it before re-checking. A lookup reflects what the resolver you queried has right now, which can briefly lag a change you just made until the old TTL expires everywhere it was cached — see DNS propagation and TTL explained for how long that realistically takes. Before assuming a result is wrong, confirm you’re querying the record type you intend, that you’ve waited out the previous value’s TTL, and that the registrar-level NS delegation actually points at the DNS provider you think it does.
This guide is general information, not a security audit of your specific network — see our disclaimer for what AdminKit's guidance does and does not commit to.
Frequently asked questions
Why does looking up a domain's A record not show its MX or TXT records too?
Because DNS stores each record type separately, even at the same name. A query for the A type only returns A records; you need a separate query (or a separate panel in a tool like AdminKit's DNS lookup) for MX, TXT, NS or any other type published at that name. There is no single 'everything about this domain' record — RFC 1035 defines each resource record type with its own format and purpose.
A domain has both an A record and a CNAME at the same name — is that normal?
No, and it isn't valid DNS. RFC 1035 requires that if a CNAME record exists for a name, no other record type can coexist at that exact name (the one standard exception is DNSSEC-related records at the same name). A CNAME pointing to another host is instead expected to resolve further by following that alias to wherever its own A or AAAA record lives.
What does it mean if a lookup returns multiple A records for the same hostname?
It means the domain publishes more than one IPv4 address for that name, which a resolver is free to return in any order or rotate between — a simple, DNS-level way to spread traffic across multiple servers or provide basic redundancy if one address stops responding. This is normal and common for high-traffic sites; it does not mean the domain is misconfigured.
My NS lookup shows different nameservers than my DNS provider's dashboard — what's wrong?
Usually nothing is wrong with your DNS provider's records; the mismatch is almost always at the registrar. The NS records a resolver actually uses come from delegation records set at the registry/registrar level, not from what your DNS provider's own zone file says about itself — if those two disagree, the registrar-level delegation wins. Confirm the registrar's nameserver delegation matches what you intend to use.
Why does a DNS lookup sometimes return no result for a record type I know exists?
The most common reasons are querying the wrong record type for that name (for example, looking up A on a name that only has a CNAME), a very recent change that hasn't propagated to the resolver you're querying yet, or a genuinely empty record set at that name. A resolver only ever reports what the authoritative servers for that zone currently return for the exact type and name you asked about.
Want AdminKit to watch this for you?
Free checks tell you the state today. Protective DNS and monitoring tell you when it changes.
Talk to an expert
Huy Nguyen (David), Founder & CEO, Netbase JSC
Ask whether this fix applies to your setup, or get a second pair of eyes on your DNS and mail records.