How to Analyze DNS Records for Security
A practical guide to reading DNS records for security purposes: understand A/AAAA/MX/NS/TXT/CNAME, check SPF and DMARC in TXT records, and spot common misconfigurations.
Quick Answer
DNS security analysis means reviewing a domain's records — A/AAAA/MX/NS/TXT/CNAME — and checking TXT records for SPF and DMARC, since missing SPF or DMARC is a common enabler of email spoofing.
Definition
DNS security analysis is the review of public DNS records to identify mail security configuration (SPF, DMARC, DKIM selectors), delegation issues and other exposure indicators.
Answer first
Focus on TXT records first: SPF and DMARC presence is a quick email-spoofing sanity check. Then review A/AAAA/MX/NS for delegation concerns.
Record types that matter
| Record | Purpose | Security relevance |
|---|---|---|
A | IPv4 address of a host | Check resolved IPs against known hosting/abuse data |
AAAA | IPv6 address of a host | Same checks as A |
MX | Mail routing servers | Legacy/unexpected mail servers are a spoofing surface |
TXT | Free-form text; hosts SPF, DKIM selectors, domain verification | SPF/DMARC presence and correctness |
NS | Authoritative name servers | Delegation to unexpected or unclaimed providers |
CNAME | Alias to another hostname | Dangling CNAMEs enable subdomain takeover |
PTR | Reverse mapping (IP → name) | Rarely validated; useful for context, not proof |
TTL | Cache lifetime on each record | Very short TTLs are common in attacker-controlled infra |
1. Host records (A / AAAA / CNAME)
Confirm expected hosts resolve as intended and no unexpected CNAME chains create takeover risk (dangling CNAME to an unclaimed service is a real hijack vector). Compare resolved IPs with what the organization actually publishes.
2. Mail routing (MX)
Check MX records point to your intended mail provider and that no legacy servers remain. Unexpected MX targets mean mail for the domain can be accepted by infrastructure the domain owner doesn’t control.
3. TXT: SPF
Look for v=spf1 ... — it declares which servers may send mail for the domain. Missing SPF means spoofed mail from the domain is plausible. A valid SPF should be short enough to fit in a single DNS response (the 10-lookup limit) and end with -all (hard fail) rather than ~all (soft fail) where possible.
4. TXT: DMARC
Check _dmarc.<domain> for v=DMARC1. The policy (p=none|quarantine|reject) tells receivers what to do with non-aligned mail. Without DMARC, receivers lack policy guidance and spoofing stays undetected. Look for rua=/ruf= reporting addresses so failures are actually visible.
5. Delegation and unusual patterns
- NS: name servers should belong to the domain owner or an expected DNS provider — not to an unrelated service.
- PTR: reverse records that don’t match the domain are common in botnets and C2 hosting.
- TXT without SPF/DMARC: TXT entries that are only domain-verification strings (e.g.
google-site-verification) do not protect against spoofing. - Very short TTLs (seconds to minutes) across infrastructure are a marker of attacker-controlled domains, though legitimate CDNs also use them.
6. Verify in context
DNS results change; reconcile with your authoritative provider. Use a read-only lookup and treat results as one signal. Pair DNS findings with header analysis — a domain that fails SPF/DMARC in the header and has no DMARC record in DNS is almost certainly spoofed.
Investigation path
Domain
↓
DNS Lookup
↓
A / AAAA / MX / TXT / NS / CNAME / PTR
↓
SPF · DMARC verdicts
↓
Related domains · resolved IPs
↓
IOC Lookup
↓
Correlate with header evidence
↓
Phishing Defense ChecklistTools that help
- DNS Lookup — query records and surface missing SPF/DMARC.
- Email Header Analyzer — check received headers against authentication results.
- IOC Lookup — check resolved IPs and related domains.
- URL Analyzer — inspect URLs that resolve through the domain.
References
Ask OpenTrojan's evidence-backed assistant about this topic — answers cite their sources.