The Anatomy of a 30-Point Security Audit (And Why Every Domain Needs One)

Most domains have between six and ten security misconfigurations that their owners do not know about.

Not because the owners are careless. Because DNS is a layered system built over four decades, where each layer adds its own records, requirements, and failure modes — and where a misconfiguration in one layer often has no visible symptom until an attacker finds it first.

An open DNS resolver. A dangling CNAME pointing to a deleted Heroku app. An SMTP server that answers user enumeration queries. A DNSSEC chain with an expired signature. None of these appear in uptime monitors. None of them trigger alerts. All of them are exploitable.

A structured security audit checks every layer systematically. This post walks through all 30 checks — what each one tests, what a failure means in practice, and why the check exists.

How the Audit Is Organized

The 30 checks fall into five categories, each targeting a different attack surface on the same domain.

Every check produces one of three outputs: pass, fail with severity rating, or warning. Every fail produces a fix guide. The aggregate result is an Email Health Score from 0 to 100.

Category 1: Email Security (8 Checks)

These eight checks cover everything that determines whether your outgoing email reaches the inbox — and whether your domain can be spoofed to send email you never sent.

Check 1: SPF Record Validation

What it tests: Whether a TXT record starting with v=spf1 exists at your root domain, whether it is syntactically valid, and whether it lists all your authorized sending services without exceeding the 10 DNS lookup limit.

What failure looks like: No SPF record means any server on the internet can send email claiming to be from your domain, and receiving servers have no mechanism to verify it is fake. A broken SPF record — syntactically invalid or over the 10-lookup limit — produces an SPF PermError, which many receiving servers treat the same as a hard fail.

The two-record failure is particularly common: a company adds a second SPF TXT record instead of editing the existing one. Having two v=spf1 records on the same domain immediately invalidates both. Every email you send fails SPF. The symptom — emails landing in spam — appears days later and is hard to trace back to the DNS change.

Why it matters: SPF is the first authentication layer that inbox providers check. Without it, your domain has no control over who can send email in your name.

Check 2: DKIM Signing Verification

What it tests: Whether DKIM TXT records exist for your active email selectors, whether the keys are present (not revoked with p=), and whether the key length is 2048 bits or higher.

What failure looks like: Missing DKIM means every email you send goes unsigned. Receiving servers cannot verify the email came from you — it is treated as unauthenticated. Weak 1024-bit keys can be computationally cracked, allowing an attacker to forge valid DKIM signatures for your domain. Revoked keys (p= with no value) indicate a service that has been removed from your stack but whose DNS records were never cleaned up.

Why it matters: DKIM is the cryptographic proof that an email bearing your domain name was actually sent by you and was not modified in transit. Gmail and Outlook increasingly deprioritize unsigned email from domains where DKIM is expected.

Check 3: DMARC Policy Enforcement

What it tests: Whether a DMARC record exists at _dmarc.yourdomain.com, whether the p= policy is set to quarantine or reject, and whether a rua= reporting address is configured.

What failure looks like: No DMARC record means SPF and DKIM results are never coordinated — a receiving server that sees SPF pass and DKIM fail has no policy to apply. p=none means the policy exists but takes no action: spoofed emails still reach recipients' inboxes. No rua= address means you receive no reports and have no visibility into authentication failures or unauthorized senders using your domain.

Why it matters: DMARC ties SPF and DKIM together and gives the receiving server an explicit instruction for what to do when authentication fails. It is the only control that actively blocks email domain spoofing. NIS2 and SOC2 CC6.6 both require enforcement (p=quarantine or p=reject) — p=none satisfies neither.

Check 4: BIMI Logo and VMC Validation

What it tests: Whether a BIMI TXT record exists at default._bimi.yourdomain.com, whether the logo URL in the record is reachable over HTTPS, and whether the SVG file passes BIMI format requirements (SVG Tiny 1.2). If a VMC certificate URL is present in the a= field, that is validated separately.

What failure looks like: A BIMI record pointing to an unreachable logo URL silently fails — no logo appears in the inbox and no error is reported. A standard SVG file that has not been converted to SVG Tiny 1.2 fails validation at the mail client level. A BIMI record without p=quarantine or p=reject DMARC has no effect regardless of the logo configuration.

Why it matters: BIMI is the only control that makes your brand visually identifiable in the inbox before the email is opened. Its prerequisites — enforced DMARC and a compliant SVG — are checked as part of this audit step.

Check 5: MTA-STS Configuration

What it tests: Whether an _mta-sts TXT record exists at your domain, whether the policy file is reachable at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt, and whether the policy specifies mode: enforce (not mode: testing).

What failure looks like: No MTA-STS means inbound email delivery to your domain has no transport security enforcement — a network attacker on the path between a remote mail server and yours can strip TLS and transmit the email in plaintext. mode: testing collects data but does not prevent this. A policy file served over HTTP (not HTTPS) is ignored by the spec.

Why it matters: MTA-STS is the email equivalent of HTTPS enforcement — it prevents downgrade attacks on your inbound email transport. ISO 27001:2022 Annex A.5.14 and NIS2 Article 21.2j both reference transport encryption for email communications.

Check 6: TLS-RPT Monitoring Setup

What it tests: Whether a _smtp._tls TXT record exists at your domain with a rua= reporting address.

What failure looks like: No TLS-RPT means you receive no reports when other mail servers fail to establish TLS connections when delivering to your domain. TLS negotiation failures are silent — email may be delayed or dropped and you have no visibility into why.

Why it matters: TLS-RPT is the monitoring companion to MTA-STS. MTA-STS enforces transport security; TLS-RPT tells you when enforcement is causing delivery failures or when TLS negotiation is being blocked. Without it, MTA-STS enforcement is a one-way door — you cannot see whether it is working correctly.

Check 7: DMARC Reporting (RUA) Validation

What it tests: Whether the DMARC record includes a rua=mailto: address that is reachable — specifically whether the receiving domain at the rua= address has published a DMARC external reporting authorization record if it differs from the sending domain.

What failure looks like: A rua= address that points to a domain you no longer control stops receiving reports silently. A third-party reporting address (e.g., a DMARC analysis service) that has not published the external reporting authorization record causes report delivery to fail — you configure reporting, assume it is working, and receive nothing.

Why it matters: DMARC reports are the primary mechanism for discovering unauthorized senders using your domain and for verifying that your authentication is working correctly. The reporting check confirms reports are actually being delivered, not just configured.

Check 8: Blacklist Monitoring (50+ Databases)

What it tests: Whether your sending IP address or domain is listed on any of 50+ DNS-based blacklists, including Spamhaus ZEN (SBL, XBL, PBL), Barracuda BRBL, SpamCop, SORBS, and Microsoft SNDS.

What failure looks like: A Spamhaus ZEN listing blocks delivery to approximately 3 billion mailboxes. Most blacklist listings produce no bounce notice to the sender — email is silently rejected or dropped. The sender's dashboard shows emails as delivered. Recipients never see them.

Why it matters: Blacklist placement is one of the fastest-moving and highest-impact email deliverability events. A single compromised account or a sending volume spike can trigger a listing within hours. The only way to know your status is to check continuously — a clean result from a manual check last month says nothing about your status today.

Category 2: DNS Security (10 Checks)

These ten checks audit the integrity, configuration, and cryptographic security of your DNS zone — the infrastructure that everything else depends on.

Check 9: DNSSEC Validation

What it tests: Whether DNSSEC signing is active on your zone (DNSKEY records present), whether a DS record exists in the parent zone establishing the chain of trust, and whether signatures are valid and not expired.

What failure looks like: No DNSSEC means DNS responses for your domain carry no cryptographic proof of authenticity — cache poisoning attacks can substitute forged responses and resolvers have no way to detect the substitution. An expired DNSSEC signature causes validating resolvers to return SERVFAIL for your domain, which is indistinguishable from a DNS outage for roughly 30% of users (those whose resolvers validate DNSSEC).

Why it matters: DNSSEC is the only DNS-layer defense against cache poisoning and DNS hijacking via forged responses. NIS2 Article 21.2g and ISO 27001:2022 Annex A.8.20 both reference cryptographic controls for DNS.

Check 10: CAA Records

What it tests: Whether Certificate Authority Authorization records exist at your domain specifying which CAs are permitted to issue TLS certificates.

What failure looks like: No CAA records mean any of the hundreds of publicly trusted certificate authorities in the world can issue a certificate for your domain — including in response to a social engineering attack or a rogue CA. The audit detects your current CA from your existing SSL certificate and flags if CAA records are missing or if the authorized CA does not match your actual certificate issuer.

Why it matters: CAA records are a pre-issuance control on certificate fraud. They do not prevent an attacker from attempting to obtain a fraudulent certificate, but they prevent a non-authorized CA from issuing one.

Check 11: Nameserver Configuration and Redundancy

What it tests: Whether your domain has at least two nameservers, whether they are reachable and responding correctly, and whether they return consistent answers (zone consistency between primary and secondary).

What failure looks like: A single nameserver is a single point of failure — one server going offline takes your domain completely offline. Inconsistent zones between nameservers (zone transfer lag or misconfiguration) can cause different users to receive different DNS answers for the same query.

Why it matters: DNS availability is the prerequisite for every other internet service. Email delivery, website availability, and API connectivity all depend on DNS resolving correctly.

Check 12: CNAME Chain Analysis

What it tests: Whether any CNAME records on your domain create excessively long chains (standard limit is 8 hops) or create circular references that would cause resolution to fail.

What failure looks like: CNAME chains longer than 8 hops are truncated by some resolvers, causing the final record to fail to resolve. Circular CNAMEs — where A points to B and B points to A — cause resolution to loop until timeout.

Why it matters: Long or broken CNAME chains produce intermittent resolution failures that are difficult to diagnose and appear as random downtime to users.

Check 13: SOA Parameters Validation

What it tests: Whether the Start of Authority record's timing parameters (REFRESH, RETRY, EXPIRE, MINIMUM TTL) are within RFC-recommended ranges.

What failure looks like: An EXPIRE value that is too short causes secondary nameservers to stop serving the zone if they cannot reach the primary — a primary nameserver outage triggers a full zone outage much sooner than necessary. A MINIMUM TTL that is too low causes excessive negative caching traffic. Values that deviate significantly from RFC recommendations often indicate a zone that has never been audited.

Why it matters: SOA parameters control zone reliability and propagation behavior. Incorrect values create fragility that only surfaces under failure conditions.

Check 14: TTL Optimization Analysis

What it tests: Whether TTL values on your DNS records are set appropriately — not so low that they cause excessive query load, not so high that DNS changes take days to propagate.

What failure looks like: TTL values under 60 seconds on stable records create unnecessary query volume without meaningful benefit. TTL values of 86400 (24 hours) on records that might need to change during an incident mean that DNS changes take a full day to reach all resolvers — a significant problem during a migration or a security incident.

Why it matters: TTL is a reliability lever. Appropriate TTL values give you fast propagation when you need it and low query load when you do not.

Check 15: PTR / Reverse DNS Check

What it tests: Whether your mail server's IP address has a PTR (Pointer) record that resolves to a hostname matching your domain, and whether that hostname forward-resolves back to the same IP.

What failure looks like: A missing PTR record is one of the most common reasons email is filtered as spam by Gmail, Outlook, and Yahoo. These providers perform a PTR lookup on the sending IP and compare the result to the HELO hostname. A mismatch or a missing record is a strong spam signal. A PTR record that resolves to a generic hostname like ip-192-0-2-1.ec2.internal instead of a mail hostname is nearly as bad.

Why it matters: PTR validation is one of the first checks major inbox providers perform on inbound email. It is configurable at your hosting provider (AWS EC2, DigitalOcean, Hetzner, etc.) and is frequently overlooked on new mail server setups.

Check 16: Open Resolver Detection

What it tests: Whether your nameserver answers recursive DNS queries from arbitrary external IP addresses.

What failure looks like: An open resolver will appear in public databases used by DDoS attack operators within days of being discovered. Attackers send small forged DNS queries to your server with a victim's IP as the source address. Your server sends large responses to the victim, multiplying the attacker's bandwidth by 30–70×. Your server's IP may be blacklisted by upstream providers as a result.

Why it matters: An open resolver turns your DNS infrastructure into an amplification tool for attacks on others — and an operational liability for you.

Check 17: DNS Performance Benchmarking

What it tests: Response time from your nameservers measured from multiple geographic locations, and whether any nameserver is returning DNS timeouts rather than responses.

What failure looks like: Response times above 200ms from major geographic regions indicate a DNS provider with poor coverage or a nameserver that is geographically distant from that region's users. Timeouts are more serious — a nameserver returning timeouts means some resolvers cannot reach it at all, causing resolution failures for a subset of users.

Why it matters: DNS response time is the first component of every web request, email delivery check, and API call. High DNS latency adds directly to page load time and service availability perception.

Check 18: DANE / TLSA Records

What it tests: Whether TLSA records exist for your mail server, pinning the TLS certificate or public key that connecting servers should expect.

What failure looks like: No TLSA records mean email transport TLS has no certificate pinning — a compromised CA can issue a fraudulent certificate for your mail server and a man-in-the-middle attacker could use it to intercept email in transit, with no mechanism for the sending server to detect the substitution.

Why it matters: DANE (DNS-Based Authentication of Named Entities) is the mail server equivalent of certificate pinning. It requires DNSSEC to be active — DNSSEC signs the TLSA records, making them tamper-evident. Without DNSSEC, DANE is not implementable.

Category 3: Infrastructure Security (6 Checks)

These six checks look at your server exposure and zone data — the attack surface that exists below the DNS record layer.

Check 19: Subdomain Takeover Detection

What it tests: Whether any CNAME records on your domain point to external resources (Heroku apps, S3 buckets, GitHub Pages, Azure web apps, Netlify sites, etc.) that no longer exist and are therefore claimable by anyone.

What failure looks like: A CNAME pointing to yourapp-staging.herokuapp.com where that Heroku app has been deleted means anyone can create a new Heroku app with that name and immediately receive all HTTP traffic sent to that subdomain — including session cookies scoped to your root domain. The attacker serves content from a URL that reads staging.yourdomain.com with a valid SSL certificate and no browser warnings. Azure, S3, GitHub Pages, Fastly, Shopify, and many other platforms have the same vulnerability pattern.

Why it matters: Subdomain takeover is one of the most exploitable vulnerabilities in the category because it requires no access to your systems — only access to the third-party platform, which is open to anyone. The fix is deletion of the dangling CNAME record.

Check 20: Zone Transfer Vulnerability Test

What it tests: Whether your nameservers respond to DNS zone transfer requests (AXFR queries) from arbitrary IP addresses.

What failure looks like: A successful zone transfer dumps your entire DNS zone — every record, every hostname, every subdomain, every internal service — to anyone who asks. This is reconnaissance of your entire infrastructure handed to an attacker in one query. Properly configured nameservers restrict zone transfers to authorized secondary nameservers only.

# Test if your nameserver allows unrestricted zone transfers
dig axfr yourdomain.com @ns1.yourdomain.com

A response with actual zone data is a critical failure. A response of Transfer failed or REFUSED is the correct behavior.

Why it matters: Zone transfer exposure is a configuration error that has no legitimate use case for external access. It provides complete infrastructure reconnaissance to anyone who checks.

Check 21: DNS Flood Protection Evaluation

What it tests: Whether your DNS infrastructure has Response Rate Limiting (RRL) configured, or whether it is protected by a managed provider's Anycast network that absorbs flood attacks at the network level.

What failure looks like: An unprotected nameserver with no RRL can be used as an amplification device in DDoS attacks — attackers send small queries and your server sends large responses to a victim's IP. Separately, NXDomain flood attacks (DNS Water Torture) send queries for random subdomains of your domain, exhausting your nameserver's resources.

Why it matters: Managed DNS providers (Cloudflare, Route53, Google Cloud DNS) handle this automatically through their Anycast infrastructure. Self-hosted nameservers require explicit RRL configuration in BIND, Unbound, or NSD.

Check 22: Geographic Redundancy Analysis

What it tests: Whether your nameservers are distributed across geographically and network-diverse locations, or whether they are concentrated in a single region or autonomous system.

What failure looks like: Two nameservers in the same data center, on the same AS, or with the same upstream provider are not meaningfully redundant — a regional outage or a BGP routing incident that affects that provider takes both offline simultaneously. Fewer than three distinct networks detected across all nameservers is a warning indicator.

Why it matters: Geographic redundancy determines whether your domain remains reachable during regional internet incidents. NIS2 Article 21.2c (business continuity) requires resilient infrastructure for this reason.

Check 23: MX Record Validation

What it tests: Whether your MX records are syntactically correct, whether the hostnames in MX records resolve to valid IP addresses, and whether multiple MX records exist with different priority values for failover.

What failure looks like: An MX record pointing to a hostname that does not resolve means email delivery to your domain fails for all senders whose MX resolution hits that record. A single MX record with no backup means your entire inbound email delivery depends on one server.

Why it matters: MX misconfiguration is one of the most direct paths to complete email delivery failure. It is also one of the easiest checks to overlook after a mail server migration.

Check 24: SMTP VRFY/EXPN Exposure Check

What it tests: Whether your mail server responds to SMTP VRFY commands from arbitrary external connections — queries that ask whether a specific email address exists at your domain.

What failure looks like: A mail server that responds to VRFY with 250 User exists or 252 Cannot VRFY user (confirming the query was processed) allows attackers to enumerate valid email addresses at your domain. A list of valid email addresses is a prerequisite for targeted phishing and spear phishing campaigns. The audit connects to your actual mail server (identified from your MX records) and probes VRFY directly — it reports the actual response received, not a theoretical vulnerability.

Why it matters: User enumeration through SMTP VRFY is a reconnaissance step that precedes targeted phishing attacks. Disabling VRFY has no impact on legitimate email delivery — the command is used only by diagnostic tools and attackers.

Category 4: Compliance Mapping (4 Frameworks)

The compliance checks do not add new technical tests — they map the results of the preceding 24 checks against the specific control requirements of four frameworks, identify which controls are missing or insufficient for each framework, and produce a compliance gap analysis with a score per framework.

NIS2 (EU Directive 2022/2555): Maps against Article 21.2c (business continuity → nameserver redundancy), 21.2d (supply chain → SPF, DKIM, DMARC enforcement), 21.2g (cryptography → DNSSEC, MTA-STS), and 21.2j (secure communications → TLS-RPT).

GDPR (EU 2016/679): Maps against data transmission security requirements — specifically MTA-STS enforcement, DMARC p=reject, and DNSSEC as controls over data-in-transit protection.

ISO/IEC 27001:2022: Maps against Annex A.5.14 (information transfer — DMARC, MTA-STS, SPF, DKIM), A.8.16 (monitoring activities — DMARC RUA, TLS-RPT), A.8.20 (network security — DNSSEC, CAA, nameserver redundancy), and A.8.12 (data leakage prevention — DMARC p=reject).

PCI-DSS v4.0: Maps against email security controls relevant to cardholder data environments — authentication requirements and transport encryption standards.

Category 5: Additional Checks (2 Checks)

Check 29: SSL Certificate Expiry Monitoring

What it tests: Whether your domain's SSL certificate is valid, which CA issued it, and how many days remain before expiry.

What failure looks like: An expired SSL certificate causes browsers to display a full-page trust error that blocks users from accessing your site. Automated certificate renewal (Let's Encrypt via Certbot, or managed renewal through your hosting provider) can fail silently for months before the certificate actually expires — the renewal process runs, encounters an error, and logs it somewhere that nobody checks. The audit catches expirations before they happen.

Check 30: Domain Expiry Tracking and Alerts

What it tests: Your domain's registration expiry date and registrar.

What failure looks like: An expired domain is immediately deactivated — website down, email stopped, all DNS records stop resolving. Most registrars send renewal notices to the WHOIS contact email, which is often an old address that nobody monitors. After expiry, a 30-day redemption period typically allows recovery at a significant fee. After redemption, the domain enters public availability and can be registered by anyone — including a competitor or attacker who then controls the entire namespace of your brand.

Why it matters: Domain expiry is a catastrophic, recoverable but humiliating failure mode. It is also completely preventable with auto-renew and monitoring.

What the Score Means

Every domain that runs the full audit receives an Email Health Score from 0 to 100. The score is weighted by severity:

• Critical failures (open zone transfer, subdomain takeover, no DMARC, blacklist listing) carry the most weight
• Configuration gaps (missing CAA, suboptimal TTLs, no TLS-RPT) carry moderate weight
• Optimization opportunities (BIMI not configured, DANE not implemented) carry the least weight

A score above 85 indicates a domain with no critical failures and most recommended controls in place. A score below 60 almost always includes at least one critical failure that represents an active, exploitable vulnerability.

Most domains score between 40 and 65 on first audit. The common pattern: email authentication is partially configured (SPF present, DKIM present, DMARC at p=none), DNS security is minimal (no DNSSEC, no CAA), and infrastructure checks reveal at least one unexpected exposure.

The audit does not stop at the score. Every failed check produces a fix guide with the exact corrective action — provider-specific steps for DNS changes, server configuration changes for SMTP VRFY and open resolver checks, and compliance documentation guidance for the framework mapping checks.

You can run the audit on any domain — your own, a competitor's, a prospective acquisition target — at zerohook.org. The free tier includes SPF, DKIM, DMARC, blacklist monitoring, and an Email Health Score. The full 30-point audit is on paid plans starting at $49/month.

TL;DR

• 30 checks across 5 categories: email security (8), DNS security (10), infrastructure security (6), compliance mapping (4), and expiry monitoring (2)
• The highest-severity findings are subdomain takeover (exploitable immediately with no access to your systems), open zone transfer (complete infrastructure reconnaissance), blacklist listing (silent email delivery failure), and DMARC p=none (no enforcement against domain spoofing)
• SMTP VRFY exposure is underestimated — a mail server that confirms whether email addresses exist hands attackers a validated list of targets for phishing campaigns
• Compliance mapping is a byproduct, not a separate effort — the technical checks feed directly into NIS2, ISO 27001, GDPR, and PCI-DSS gap analysis
• Most domains score 40–65 on first audit — partially configured email authentication and minimal DNS security with at least one unexpected infrastructure exposure is the most common pattern
• Every failed check produces a fix guide — the audit does not stop at finding problems; it produces the specific corrective action for each one

*Part of an ongoing series on DNS security and email deliverability.