In one sentence
DNS records are the entries that tell the internet how to resolve and treat a domain: A/AAAA map a name to an address, MX names the mail servers, TXT holds free text (SPF, DMARC, verification tokens), CNAME aliases one name to another, and NS delegates a zone.
Why it matters
A large share of e-mail-authentication and subdomain-security work is really "read the DNS records correctly". SPF and DMARC live in TXT records and DKIM under a _domainkey subdomain; a dangling CNAME is the entire mechanism behind subdomain takeover; an unexpected MX change is a classic sign of e-mail hijacking or a business-e-mail-compromise setup in progress; a stale A record advertises an IP you no longer control. DNS is also the last place people look when something is "down", and the first place an attacker looks when mapping you.
The types, and what to look for
| Type | Means | Security angle |
|---|---|---|
| A / AAAA | name → IPv4 / IPv6 address | Points at an address you no longer own? Points at a cloud IP that was released? Both are takeover-adjacent. |
| CNAME | this name is an alias of that name | Cannot coexist with other records at the same name (so never at the zone apex). Dangling target = takeover. |
| MX | mail servers for the domain, by priority | An unfamiliar or extra MX is an incident. A domain that sends no mail should publish a "null MX" (0 .). |
| TXT | free text | SPF (v=spf1), DMARC at _dmarc, DKIM at selector._domainkey, MTA-STS, and every "verify you own this domain" token you ever pasted — old ones leak which SaaS you use. |
| NS | delegates the zone to these nameservers | Delegation to a provider you left is a whole-zone takeover; check the registrar's NS matches the zone's. |
| CAA | which CAs may issue certificates for the name | Missing = any CA may issue. Cheap to add. |
| SOA | zone authority and serial | The serial tells you whether a change has propagated. |
Every record has a TTL — how long resolvers may cache it. Low TTLs (60 s) let you move quickly during an incident but are also what fast-flux malware infrastructure uses; very long TTLs mean a mistaken record lives for a day. DNSSEC signs the records so a resolver can detect forgery; it does not encrypt anything.
Try it yourself hands-on
Auditing a domain's DNS posture at a glance:
- Run the domain through the DNS Record Lookup for A, AAAA, MX, TXT, NS, CNAME and SOA in one pass, with TTLs. Read the MX first: does it match the mail provider you actually use, and only that one?
- Read the TXT records. You want exactly one
v=spf1entry, and a_dmarcrecord (query_dmarc.example.comseparately). The Email Security Checker interprets both and adds DKIM; the SPF and DMARC glossary entries say what "good" looks like. Old verification tokens for services you no longer use can go. - Check CNAME records for anything pointing at a third-party service that is no longer active — the DNS Mapper's graph view (DNS Mapper) shows all the delegations from one domain, including subdomains it discovers.
- Check CAA and HSTS with the CAA & HSTS Checker: no CAA record means any certificate authority can issue for your name; adding one that names your CA is a five-minute win.
Common misreadings
- "Propagation" is caching. A change is live at the authoritative server immediately; resolvers keep the old answer until its TTL expires. Lower the TTL before a planned change.
- The registrar and the DNS host are different roles. The registrar records who owns the name and which NS to delegate to; the DNS host serves the records. Losing either account is losing the domain.
- TXT records are public. Everything in them — the SaaS tokens, the SPF includes naming your vendors — is reconnaissance material.