Use A, AAAA, CNAME, MX, TXT, NS, SOA, CAA and PTR records to answer specific website, email, authority and routing questions.
What matters first
- Record types answer different operational questions.
- Negative responses must distinguish NXDOMAIN from existing names without that type.
- TTL is cache policy context, not a global propagation promise.
- A useful diagnostic records name, type, resolver, time and response code.
Address and alias records
A and AAAA publish IPv4 and IPv6 destinations. CNAME makes one owner name an alias of another and generally cannot coexist with other data at that owner. Compare address families separately; working IPv4 does not prove working IPv6.
Query the record families discussed here with the DNS lookup and retain the answer type and TTL with the observation.
Mail and policy records
MX gives mail exchangers with preferences; lower values are tried first. TXT is a general text container commonly used by SPF and verification systems. CAA expresses which certificate authorities may issue for the domain, but absence does not invalidate an existing certificate.
Authority records
NS identifies authoritative servers. SOA carries the primary server name, responsible-party mailbox form, serial, and timing values. PTR lives under reverse-mapping zones and points an address toward a hostname; it does not prove exclusive ownership or identity.
For a grouped snapshot and carefully limited warnings, use the DNS report.
A disciplined lookup
Record the queried name, exact type, recursive resolver, answer TTL, response code, and whether the data came from cache or an authoritative server. A screenshot of one answer without those details is not a durable diagnosis.
When the input is an address rather than a domain, a reverse DNS lookup checks the separately controlled PTR record.
Evidence-to-decision table
| Evidence | What it means | Responsible next step |
|---|---|---|
| A / AAAA | Where IPv4 / IPv6 clients connect | Test both families independently |
| CNAME | Owner name aliases another name | Resolve target chain and detect loops |
| MX | Where mail should be delivered | Resolve targets; lower preference first |
| CAA | Which CAs may issue | Check applicable labels and issuer syntax |
| TXT | Published text and policy tokens | Interpret using the consuming protocol |
Illustrative mail-receipt investigation
This is an illustrative example, not a claimed real-world test.
Query MX and record preference values, then resolve A and AAAA for every exchanger.
Check that MX targets are hostnames rather than aliases and test mail connectivity separately.
Review SPF, DKIM and DMARC at their correct owner names; do not treat all TXT strings as one policy.
Defensible outcome: The result separates DNS reachability from mail policy and application acceptance, making the next responsible team clear.
Action checklist
- Use the exact owner name
- Choose one record type
- Record response code
- Capture TTL and query time
- Follow alias targets
- Compare authoritative answers
- Retest after relevant caches expire
Edge cases that change the answer
Apex aliasing
Traditional CNAME rules conflict with other required apex data; provider-specific flattening is not itself a CNAME record.
Wildcard answer
A wildcard can synthesize answers for absent names. Querying one invented label helps reveal this behavior.
Split horizon
Internal and public resolvers may intentionally return different views; record which network and resolver supplied the answer.
Questions this guide should settle
Can TXT contain multiple strings?
Yes. DNS presentation and application protocols define how character strings are combined or interpreted.
Does lower MX mean backup?
Lower preference is tried first; equal preferences can distribute attempts, while higher values are commonly secondary.
Can a CNAME coexist with other data?
At the same owner name, CNAME generally cannot coexist with other ordinary record data under DNS rules.