DNS Health Checker

🖥️ NS delegation & consistency

Your domain's authoritative nameservers (the NS records) are the source of truth for all your DNS. Each of these servers should hold an identical copy of your zone file. The SOA serial number is the version stamp used to detect when a copy is out of date. If two nameservers have different serials, they'll return different answers to different users — a problem most general-purpose DNS checkers miss because they only ever query one resolver.

📋 SOA record sanity

The SOA (Start of Authority) record contains timer values that control how secondary nameservers refresh their zone copies and how long they serve stale data if the primary becomes unreachable. RFC 1912 provides battle-tested recommendations: refresh between 1200–43200 seconds, expire at least 7 days, retry shorter than refresh. Misconfigured SOA timers don't usually cause problems until your primary server goes down — and then they matter a lot.

📡 A/AAAA records present

This is the basic check: does your domain resolve to an IP address? Domains used only for email or as DNS delegation points legitimately have no A record, so we phrase this as an informational note rather than a hard fail in those cases. AAAA records provide IPv6 addresses, which are increasingly important as IPv4 exhaustion continues — most CDNs and hosting providers can enable dual-stack with a checkbox.

✉️ SPF record

SPF (Sender Policy Framework) is a TXT record that lists which mail servers are authorized to send email on behalf of your domain. Without it, any server on the internet can send email claiming to be from you@yourdomain.com — and many spam filters won't catch it. The most common SPF mistake is having two SPF TXT records instead of one: RFC 7208 says multiple SPF records are invalid, and many mail servers will fail the check entirely rather than evaluating both.

🔏 DKIM presence

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outbound email that receiving servers can verify against a public key published in your DNS. The signature proves the email wasn't modified in transit and came from someone with access to your private key. The catch: there's no way to discover a DKIM selector (the subdomain where the public key lives) without knowing what it's called. We check common selectors used by Google, Microsoft 365, and Mailchimp — but custom selectors require the manual input below each check.

🛡️ DMARC record & policy

DMARC (Domain-based Message Authentication, Reporting & Conformance) builds on SPF and DKIM by telling receiving servers what to do when a message fails authentication: report it (p=none), send it to spam (p=quarantine), or reject it outright (p=reject). The most common mistake is staying on p=none forever — the record exists, so IT can report compliance, but spoofed email still reaches inboxes unchanged. DMARC reports (sent to rua= address) show you exactly which servers are sending on your behalf before you move to enforcement mode.

🔐 DNSSEC

DNSSEC cryptographically signs DNS responses so that resolvers can detect if the answer has been tampered with or forged — an attack class called DNS spoofing or cache poisoning. Without DNSSEC, a network-level attacker could redirect your domain to a malicious server and most users would never know. DNSSEC requires coordination between your DNS provider (who signs the zone) and your registrar (who publishes the DS record in the parent zone). Cloudflare, AWS Route 53, GoDaddy, and most modern providers offer one-click enablement.

🏷️ CAA record

CAA (Certificate Authority Authorization) records specify which certificate authorities are allowed to issue SSL/TLS certificates for your domain. Without CAA records, any of the hundreds of CAs in the world can issue a certificate for your domain — which has historically been exploited through mistakes or compromise at lesser-known CAs. CAA records are a simple, underused protection: a single record saying 'only Let's Encrypt can issue for me' dramatically reduces the attack surface without any operational impact on your existing certificates.

⚠️ Subdomain takeover risk

A dangling CNAME is a DNS record pointing to a third-party service that no longer exists. For example: blog.yourcompany.com used to CNAME to yourcompany.wordpress.com, but you deleted the WordPress account. The CNAME still exists in DNS, but the target is unclaimed. An attacker who registers that exact WordPress subdomain now controls blog.yourcompany.com and can serve content, issue cookies, and run phishing pages under your domain. We check 15 common subdomains against a list of services known to be vulnerable to this class of attack.