72 checks. 8 categories. One verdict.

The parent zone is the layer above your domain — the TLD registry. For your domain to resolve correctly, the parent zone must recognise your nameservers and correctly delegate authority to them.

• Parent zone NS delegation — Are your nameservers listed in the parent zone?
• Nameserver glue records — Are glue records present for in-bailiwick nameservers?
• Parent-child NS consistency — Do parent zone NS records match your own zone's NS records?
• Parent zone reachability — Is the parent zone responding correctly?
• Lame delegation detection — Are any delegated nameservers unresponsive or misconfigured?
• DS record presence — Is a Delegation Signer record present for DNSSEC?

Your nameservers are the authoritative source of truth for your domain's DNS records. DNSSnuff verifies that they're properly configured, consistent, and redundant.

• Minimum nameserver count — Do you have at least 2 nameservers for redundancy?
• Nameserver hostname resolution — Do all NS hostnames resolve to valid IP addresses?
• IPv4 and IPv6 support — Do nameservers respond on both A and AAAA records?
• Authoritative response — Do all nameservers return authoritative answers for your zone?
• Answer consistency — Do all nameservers return identical records for the same query?
• Nameserver reachability (UDP) — Are all nameservers reachable over UDP port 53?
• Nameserver reachability (TCP) — Are all nameservers reachable over TCP port 53?
• Open resolver detection — Are any nameservers configured as open resolvers?
• Recursive query rejection — Do nameservers correctly refuse recursive queries?
• EDNS support — Do nameservers support Extension Mechanisms for DNS?
• Zone transfer restriction — Are AXFR zone transfers correctly restricted?
• Response time — Are nameserver response times within acceptable thresholds?
• Nameserver in same subnet — Are all nameservers in different IP ranges for true redundancy?

The SOA record defines the zone's administrative properties — including caching times, serial numbers, and retry behaviour. Problems here cause slow propagation and stale caches.

• SOA record presence — Does a valid SOA record exist?
• Primary nameserver match — Does the SOA MNAME match a listed nameserver?
• Hostmaster email validity — Is the responsible party email address correctly formatted?
• Serial number format — Is the serial in the recommended YYYYMMDDNN format?
• Refresh interval — Is the refresh interval within best-practice range (3600–86400 seconds)?
• Retry interval — Is the retry interval appropriately shorter than the refresh interval?
• Expire value — Is the expire value long enough to handle extended nameserver outages?
• Negative TTL (minimum) — Is the negative TTL short enough to allow quick recovery after fixes?
• SOA consistency — Do all nameservers return the same SOA record?

Mail server configuration is one of the most common sources of email delivery failure. DNSSnuff checks the full stack — from MX record syntax to SMTP connectivity.

• MX record presence — Does the domain have valid MX records?
• MX hostname resolution — Do all MX hostnames resolve to valid IP addresses?
• MX priority ordering — Are MX priorities correctly set for preferred routing?
• MX hostname as bare IP — Are any MX records incorrectly pointing to IP addresses?
• MX hostname is CNAME — Are any MX records incorrectly pointing to CNAME records (not permitted by RFC)?
• Null MX detection — Is a null MX record (0 .) correctly used for domains that don't send/receive email?
• SMTP connectivity — Are mail servers reachable on port 25?
• SMTP banner validity — Do mail servers return a valid SMTP greeting?
• Open relay detection — Are mail servers configured to relay email for any sender?
• Reverse DNS (PTR) match — Do mail server IPs have reverse DNS records matching their forward hostname?

SPF, DKIM, DMARC, and BIMI are the four authentication standards that determine whether email from your domain is trusted by receiving mail servers. This is where most deliverability problems live.

• SPF record presence — Does a valid SPF record exist?
• SPF syntax validation — Is the SPF record correctly formatted per RFC 7208?
• SPF policy strength — Is the mechanism ending in -all (reject), ~all (softfail), or ?all (neutral)?
• SPF lookup count — Does the record stay within the 10 DNS lookup limit?
• Multiple SPF records — Is there only one SPF record? (Multiple records cause authentication failure)
• DKIM record discovery — Are DKIM public key records discoverable for common selectors?
• DKIM key validity — Are DKIM public keys syntactically valid?
• DKIM key length — Are DKIM keys at least 1024 bits? (2048 recommended)
• DMARC record presence — Does a valid DMARC record exist?
• DMARC policy strength — Is the policy none, quarantine, or reject?
• DMARC reporting configured — Is a reporting address (rua) configured?
• DMARC alignment mode — Are SPF and DKIM alignment modes set appropriately?
• DMARC subdomain policy — Is a subdomain policy (sp) configured?
• BIMI record presence — Is a Brand Indicators for Message Identification record present?

DNS doesn't stop at email. DNSSnuff checks your web presence — HTTP and HTTPS reachability, SSL validity, redirect chains, and security headers.

• HTTP reachability — Does the domain respond over HTTP?
• HTTPS reachability — Does the domain respond over HTTPS?
• HTTP to HTTPS redirect — Is HTTP automatically redirected to HTTPS?
• www to root redirect — Is the www subdomain correctly redirected?
• SSL certificate validity — Is the SSL certificate valid and trusted?
• SSL certificate expiry — How many days until the certificate expires?
• Certificate chain completeness — Is the full certificate chain served correctly?
• HSTS header presence — Is HTTP Strict Transport Security correctly configured?
• Redirect chain depth — Are there excessive redirect hops that could affect performance and SEO?

DNSSEC adds cryptographic signatures to DNS records, allowing resolvers to verify that records haven't been tampered with. DNSSnuff verifies the full chain of trust.

• DNSSEC enabled — Is DNSSEC signing active for the zone?
• DS record present — Is a Delegation Signer record in the parent zone?
• DNSKEY record validity — Are DNSKEY records syntactically valid and correctly typed?
• RRSIG validity — Are Resource Record Signatures present and within their validity period?
• Chain of trust verification — Can a validating resolver build a complete chain of trust to the root?

Real-time block lists (RBLs) are databases of IP addresses and domains known to send spam or malware. Cross-referenced against 50+ RBL databases.

• Domain RBL listing — Is the root domain listed on any domain-based block list?
• MX IP listing — Are any mail server IPs listed on IP-based block lists?
• Sending IP listing — Are known sending IPs listed?
• URI RBL check — Is the domain listed on URI-based block lists used by spam filters?
• SURBL listing — Is the domain in SURBL databases (used by major email platforms)?
• SpamCop listing — Is the domain or IP listed in SpamCop?