Record types, decoded for real tasks
Knowing what each record does matters more than memorising letters. Here is the working developer’s view:
| Record | Answers the question | You touch it when… |
|---|---|---|
| A / AAAA | ”What IP serves this name?” (v4 / v6) | Pointing a domain at a server |
| CNAME | ”What other name should I follow?” | Aliasing www → apex, or to a SaaS host |
| MX | ”Where does email for this domain go?” | Setting up or debugging mail |
| TXT | ”What text policy is published here?” | SPF, DKIM, DMARC, domain verification |
| NS | ”Which servers are authoritative?” | Delegating or migrating a zone |
| SOA | ”Who owns this zone and how fresh is it?” | Checking serial numbers after a change |
Debugging email deliverability with three lookups
When mail goes to spam, the diagnosis is almost always in DNS, and three queries find it:
- MX — confirm mail is routed to the provider you expect, with sane priorities (lower number = higher priority).
- TXT (apex) — read the SPF record. A common failure is multiple SPF records (only one is allowed) or a stray
-allthat hard-fails legitimate senders. - TXT (_dmarc subdomain) — check the DMARC policy.
p=rejectwith a misaligned SPF/DKIM setup will bounce your own newsletters.
Get all three aligned and inbox placement usually fixes itself within a TTL or two.
Why this tool and dig sometimes disagree
This lookup uses DNS over HTTPS against Google and Cloudflare’s public recursive resolvers. Your local dig may hit your ISP’s resolver, your corporate split-horizon DNS, or a caching layer with a different TTL countdown. So three honest answers can all be “correct” simultaneously — they reflect different caches at different moments in the propagation window. To see the uncached truth, query the domain’s authoritative nameserver directly (dig @ns1.example.com example.com). Disagreement between resolvers right after a change is propagation in progress, not a bug.
TTL is a planning tool, not just a number
Before any migration, lower the TTL on the records you intend to change — to 300 seconds (5 minutes) a day ahead of time. That way, when you flip the record, the old value drains from caches in minutes instead of the 24–48 hours a high TTL imposes. After the change settles, raise the TTL back up to cut query load. Treating TTL as a deliberate lever rather than a default is what separates a smooth cutover from a day of “it works for me but not for them.”