DNS Records Analyzer
DNS (Domain Name System) records map domain names to IP addresses and configure email routing. This tool parses zone file output from dig or BIND, analyzes email authentication records (SPF, DMARC, DKIM, BIMI), and warns about common misconfigurations.
Specifications
Common Use Cases
- Analyze dig or host command output for troubleshooting
- Audit domain DNS configuration before migration
- Verify email authentication setup (SPF, DMARC, DKIM)
- Debug email deliverability issues
- Document domain DNS records for compliance
- Check CAA records before requesting SSL certificates
Features
- Parse BIND/dig zone file output
- Display A, AAAA, NS, MX, TXT, CNAME, SOA, SRV, CAA, TLSA records
- Human-readable TTL formatting (5m, 2h, 1d)
- Auto-detect and analyze SPF records with mechanism explanations
- Analyze DMARC policies and reporting configuration
- DKIM record analysis (key type, selector, validity, testing mode)
- BIMI record analysis (VMC presence, validity)
- DNSSEC support (DNSKEY, DS, RRSIG records with expiration)
- TLSA/DANE certificate pinning display
- Validate SPF DNS lookup count (max 10 per RFC 7208)
- Warn about email authentication misconfigurations
Examples
Zone File Output
Try it →Output from dig showing various record types.
example.com. 300 IN A 192.0.2.1
example.com. 172800 IN NS ns1.example.com.
example.com. 172800 IN NS ns2.example.com.
example.com. 300 IN MX 10 mail.example.com.
example.com. 300 IN TXT "v=spf1 include:_spf.google.com ~all"
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"SPF Record
Try it →An SPF record authorizing Google and Mailgun to send email.
v=spf1 include:_spf.google.com include:mailgun.org ip4:192.168.1.0/24 ~allDMARC Record
Try it →A strict DMARC policy with aggregate and forensic reporting.
v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:forensic@example.com; adkim=s; aspf=s; pct=100Tips
- Get all records with: dig example.com ANY +noall +answer
- SPF allows max 10 DNS lookups. Use "include" sparingly.
- DMARC p=reject is strongest, but start with p=none and rua reporting.
- CAA records restrict which CAs can issue certificates for your domain.
- TLSA records enable DANE for certificate verification.
Understanding DNS Records
The Domain Name System (DNS) is the internet's directory service, translating human-readable domain names into IP addresses and providing other critical mappings. DNS records are stored in zone files on authoritative nameservers, each with a name, type, class, TTL (time to live), and type-specific data.
The most fundamental record types handle name resolution. A records map a domain to an IPv4 address, AAAA records map to IPv6. CNAME records create aliases pointing one name to another. NS records delegate subdomains to specific nameservers. MX records direct email to mail servers with a priority value. SOA records contain zone metadata including the primary nameserver and serial number.
TXT records carry email authentication data. SPF records (v=spf1 ...) specify authorized email senders. DMARC records (v=DMARC1; ...) tell receivers how to handle SPF/DKIM failures. DKIM records store public keys for email signature verification. Misconfigured email authentication is a leading cause of deliverability problems.
The TTL value controls how long resolvers cache responses. High TTLs (86400 seconds = 1 day) reduce DNS traffic but make changes slow to propagate. Low TTLs (300 seconds = 5 minutes) enable fast updates but increase query volume. Before migrations, lower TTLs in advance so old values expire quickly.
DNS does not actually "propagate" in the way the term implies. When a record changes, resolvers continue serving the cached old value until its TTL expires, then fetch the new value from the authoritative server. If the TTL was 86400 (24 hours), it can take up to 24 hours for the change to be visible everywhere. To speed up changes, lower the TTL well in advance (for example, to 300 seconds 48 hours before the migration), make the update, then raise the TTL again afterward.
An A record maps a domain directly to an IPv4 address, while a CNAME creates an alias pointing to another domain name — the resolver follows the chain to the final A record. CNAMEs cannot be used at the zone apex (bare domain like example.com) because they conflict with the required SOA and NS records at the apex. Some DNS providers offer proprietary ALIAS or ANAME record types to work around this limitation.
Setting up email authentication involves three DNS records. For SPF, add a TXT record with "v=spf1" followed by the authorized senders. For DKIM, add a TXT record at a selector subdomain containing the public key provided by the email service. For DMARC, add a TXT record at _dmarc.yourdomain.com specifying the policy (none, quarantine, or reject) and a reporting address. Starting with p=none allows monitoring alignment before enforcing. SPF failures are commonly caused by exceeding the 10 DNS lookup limit, forgetting to authorize a sending service, using -all (hard fail) before all senders are verified, or having multiple SPF records on the same domain — only one v=spf1 record is allowed, and multiple records cause a permanent error.