Domain DNS Security Posture: Full Audit Checklist

The Registrar and Registry Perimeter: Securing the Root

The registrar layer is the absolute foundation of your domain's existence. If an attacker compromises your account at a registrar like GoDaddy, Namecheap, or AWS, they have the power to change your nameservers, redirect your traffic, and effectively steal your brand in minutes. No amount of application firewalls or encryption can protect you if the "Root of Trust" is compromised. This is why registrar security must be the very first step in your domain audit.

The most critical control is Hardware-based MFA. SMS-based codes or even TOTP authenticator apps are vulnerable to real-time phishing and SIM-swapping. For any production domain, you should mandate the use of FIDO2-compliant keys (like YubiKeys) for all accounts with domain management permissions. This ensures that even if a password is stolen, the physical key is required to make any changes to your core DNS routing.

Check Registrar Account MFA: Hardware keys are the only acceptable standard for high-value domains.
Audit Domain Expiry: Ensure auto-renewal is enabled and that multiple billing methods are on file to prevent accidental drops.
Verify Registry Lock: For critical domains, implement a server-side lock at the registry level (e.g., .com registry) that requires out-of-band verification for any changes.
Registrant Contact Accuracy: Outdated WHOIS information can lead to verification delays and can be exploited by social engineers during "Account Recovery" attempts.

Registry Lock is the "Gold Standard" of registrar security. Unlike a standard "Domain Lock," which only prevents transfers and can be toggled off by anyone with account access, a Registry Lock (ServerLock) is enforced by the TLD operator itself. It turns a "Self-Service" change into a "Managed Verification" event, often requiring a manual phone call from a pre-authorized individual. This effectively eliminates the risk of automated DNS Hijacking.

For a daily check, you can use our WHOIS Guard tool to monitor for unexpected status changes or updates to your nameservers. An unexpected "Transfer Pending" or "Pending Update" status in your WHOIS record is a major red flag that requires immediate intervention with your registrar's emergency support team. By hardening this perimeter, you ensure that every other security layer you build sits on top of a truly secure foundation.

Cryptographic DNS: Validating the Chain of Trust with DNSSEC

Standard DNS is an unauthenticated protocol. When a browser asks for your IP address, it accepts whichever answer arrives first. This is vulnerable to DNS Cache Poisoning, where an attacker injects a fake IP into the ISP's cache. DNSSEC (Domain Name System Security Extensions) solves this by adding a digital signature to every single record in your zone. This allows resolvers (like 8.8.8.8) to verify that the answer they received hasn't been tampered with.

A complete DNSSEC audit checks for the presence of the DS (Delegation Signer) record at your parent registry and the DNSKEY record in your own zone. Without the DS record at the registry, the "Chain of Trust" is broken, and resolvers won't know that your signatures are valid. This is often the step that webmasters forget—they sign the zone at their DNS provider but fail to "Anchor" it at their registrar, leaving the domain unprotected despite the extra effort.

Code

# How to manually verify your DNSSEC chain:
dig DS yourdomain.com +short
# If this returns a value, your domain is "Anchored" at the registry.

dig DNSKEY yourdomain.com +short
# If this returns a value, your zone is "Signed" at the provider.

The "Health" of your DNSSEC deployment can be determined by looking for the AD (Authenticated Data) flag in your queries. If you query your domain via a validating resolver and the ad flag is present, it means the entire chain from the "Root" of the internet to your specific A record is cryptographically verified. If the flag is missing, or if the resolver returns a SERVFAIL, your DNSSEC configuration is broken and is likely blocking users on high-security networks.

Record Type	Purpose	Critical Check
DS Record	Anchors your domain at the registry (.com)	Must match your local KSK
DNSKEY	The public key used to verify signatures	Must be rotated regularly
RRSIG	The actual digital signature on the record	Must not be expired
NSEC/NSEC3	Proves that a subdomain doesn't exist	Protects against zone walking

As shown in the table, DNSSEC logic is complex and relies on precise timing. If your signatures expire or if you rotate your keys without updating the registry, your site will go "Dark" for everyone using secure DNS. For this reason, we recommend using a DNS provider that offers "Managed DNSSEC," which automates the signing and rotation process. You can verify your current "Chain Maturity" in seconds using our DNSSEC Audit Tool.

Email Authentication Ecosystem: SPF, DKIM, and DMARC Audits

Email is the most common vector for organizational compromise. Without authentication, your domain name can be used by anyone to send convincing phishing emails to your customers, employees, or partners. A complete audit of your "Email Posture" looks at three pillars: SPF (The allowed list of senders), DKIM (The digital signature), and DMARC (The enforcement policy).

The most frequent error in email security is having a DMARC policy of p=none. While this is a necessary first step for monitoring, it provides zero security. Attackers can still spoof your domain perfectly, and the p=none policy just tells the receiving server to "let it in anyway." To secure your domain, you must reach an enforcement policy of p=quarantine (send to spam) or p=reject (block completely).

Audit SPF Syntax: Ensure you don't have multiple SPF records (which is a fatal error) and that your "Mechanism Count" is under 10.
Check DKIM Key Length: Legacy 1024-bit keys are increasingly vulnerable and or rejected. Upgrade all active selectors to 2048-bit keys.
Verify DMARC Alignment: Ensure that the domains in your From: header match those used in your SPF and DKIM signatures. Disaligned mail is treated as unauthenticated.
Parked Domain Protection: For domains that don't send mail, publish a "Nuclear" policy: v=spf1 -all and v=DMARC1; p=reject.

Authentication is about Alignment. A common troubleshooting scenario is seeing mail pass SPF and DKIM but fail DMARC. This usually happens because the IT team set up a third-party service like Zendesk or Salesforce but didn't set up "Custom Domain" settings. The mail comes from the ESP's domain but claims to be from yours, causing a "Domain Mismatch." A successful audit will identify every third-party mail flow and verify they are all fully aligned with your organizational domain.

If you are managing a large domain portfolio, use our Email Security Dashboard to scan all your domains at once. It will highlight which domains are currently "Spoofable" and which are safe. For a detailed guide on moving from monitoring to full enforcement, follow our DMARC Policy Enforcement guide, which provides a 30-day "Safe Rollout" plan to prevent legitimate mail from being blocked.

Inbound Transport Security: MTA-STS and TLS-RPT Compliance

While SPF and DMARC secure the identity of the sender, they do nothing to secure the Transport of the message. By default, email encryption (STARTTLS) is opportunistic—if an attacker performs a "Downgrade Attack," the servers will fall back to sending your sensitive data in clear, readable text. MTA-STS closes this gap by allowing you to declare that your mail servers must use encryption for all inbound mail.

An MTA-STS audit verifies the presence of two items: the _mta-sts TXT record and the policy file hosted at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. If either is missing or misconfigured, sending servers (like Gmail) will continue to use the insecure "Opportunistic" model. You should also ensure you have a TLS-RPT record, which tells other servers where to send failure reports if they are unable to establish a secure connection with you.

Check Policy Mode: Ensure you move from mode: testing to mode: enforce once you’ve confirmed your mail server has a valid SSL certificate.
MX Match Validation: Your policy file must list every MX host correctly. If your MX is mail.example.com but your policy only lists example.com, delivery will fail.
TLS-RPT Monitoring: Analyze your daily JSON reports. If you see "Certificate Mismatch" errors, it means a sender is seeing an old or fake certificate on your mail server.

Component	Function	Failure Impact
MTA-STS Record	Signals policy existence	Senders use insecure legacy SMTP
HTTPS Policy	The rules for encryption	Senders block delivery (if set to enforce)
TLS-RPT	The reporting endpoint	Security teams miss critical failure data

As shown in the table, MTA-STS is a "High Stakes" control. Because it uses the "Web PKI" (HTTPS certificates) to secure "Email Infrastructure" (SMTP), it requires perfect synchronization between your web and mail teams. If your web team allows the certificate on the mta-sts subdomain to expire, your organization's entire inbound email flow could be blocked by high-security partners. This is why automated SSL Expiry Monitoring for this subdomain is mandatory.

Implementing MTA-STS and TLS-RPT is the final step in reaching "Zero Trust" email security. It ensures that your communications are protected from source to destination, both in terms of identity and encryption. To begin your deployment, use our MTA-STS Lookup tool to find your current gaps and generate a compliant policy file that you can host on your server today.

SSL/TLS Integrity and Certificate Lifecycle Management

The health of your HTTPS deployment is a primary signal of your security posture. A domain audit should evaluate not just the "Presence" of a certificate, but the Quality of the implementation. This includes checking for "Incomplete Chains" (which causes errors on Android and older browsers), weak cipher suites (like 3DES or RC4), and deprecated protocols (TLS 1.0 and 1.1). A secure domain should only support TLS 1.2 and TLS 1.3.

Certificate Transparency (CT) monitoring is the "Early Warning" system for unauthorized certificates. Every time a trusted CA issues a certificate for your domain, it is logged in a public database. If you see a certificate issued for your domain that your team didn't request, it’s a definitive signal that your DNS has been hijacked or that your domain validation has been compromised. Every security audit should include a review of the CT logs for the last 6 months.

Check Expiry Window: Any certificate expiring within 30 days is a "Postural Risk." Automation (via ACME/Certbot) should ideally renew at 60 days.
Validate Chain Integrity: Ensure your server is sending intermediate certificates. Use our SSL Checker to find "Chain Incomplete" errors.
Verify SAN Coverage: Ensure that yourdomain.com and www.yourdomain.com are both covered. Missing the www variant is a common cause of user-facing errors.
Audit Cipher Suites: Disable "Legacy" ciphers and ensure "Forward Secrecy" (ECDHE) is preferred by your server.

Managing the "Lifecycle" of certificates is often the most neglected part of IT operations. Most outages occur because a "Once-a-Year" manual renewal was forgotten. To prevent this, you should transition every possible service to "Automated Management." If a service doesn't support ACME, you should have it added to a centralized Expiry Monitoring Dashboard that triggers Slack or PagerDuty alerts well before the expiration date.

A secure certificate posture also requires thinking about Revocation. If your server is compromised and your private key is leaked, you must know how to revoke that certificate quickly. An audit should include a review of your "Emergency Response Plan" for certificate compromise, ensuring that your team knows how to signal to the CA that a specific certificate should no longer be trusted by the world's browsers.

Application-Layer Defense: Security Headers and CAA Controls

Once your DNS and Email are secure, you must focus on how your site's content interacts with the user's browser. HTTP Security Headers are the primary mechanism for this. They tell the browser to activate built-in defenses against Cross-Site Scripting (XSS), Clickjacking, and MIME-sniffing. A domain with "A+" security headers is significantly more difficult to attack than one with the default "Blank" settings.

The second critical "Application-Level" DNS control is the CAA (Certification Authority Authorization) record. This record allows you to specify exactly which Certificate Authorities (like Let's Encrypt or DigiCert) are allowed to issue certificates for your domain. Without a CAA record, any of the ~150 CAs in the world can issue a certificate for you. This "Universal Trust" is a major risk; CAA records close this door by pinning your trust to your specific vendors.

Strict-Transport-Security (HSTS): Tells browsers to only use HTTPS for a set duration (e.g., 1 year). Include the preload tag for maximum security.
Content-Security-Policy (CSP): The ultimate defense against XSS. It whitelists exactly which scripts and assets can load on your page.
X-Frame-Options: Prevents your site from being embedded in an iframe on an attacker's site (Clickjacking).
CAA issue tags: "Let's Encrypt only" or "DigiCert only."
CAA iodef tag: The email address where CAs should report "Rogue" certificate attempts.

Code

; A Recommended Baseline CAA Configuration:
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 issuewild "letsencrypt.org"
example.com. IN CAA 0 iodef "mailto:security@example.com"

Security headers are often omitted by developers because they are "Invisible." But to a security scanner or an automated attack bot, they are the difference between a "Hard" and "Easy" target. For example, HSTS eliminates the "SSL Stripping" attack window entirely. By publishing these headers, you are essentially "Hardening" the user's browser against your own potential vulnerabilities.

We recommend using our Security Header Audit Tool to check your live production URLs. It will give you a detailed breakdown of which headers are missing and provide you with the exact Nginx or Apache snippets to fix them. By combining strong headers with restrictive CAA records, you create a "Dual-Layer" defense that protects both the authenticity of your server and the safety of your users.

Zone Hygiene and Subdomain Takeover Prevention

The final section of the audit focuses on "Cleaning up" your DNS. Over time, every domain accumulates "Stale" records—old A records for servers you've turned off, TXT records for services you no longer use, and CNAMEs for defunct blog platforms. This "Technical Debt" is more than just an organization problem; it's a security risk. Every stale record is a potential "Dangling DNS" entry that could be exploited by an attacker.

The most dangerous stale record is the CNAME. If you have blog.example.com CNAME pointing to mycompany.github.io, but you later delete that GitHub project, the DNS record still points there. An attacker can create a new GitHub project with the name mycompany and suddenly they are the owner of blog.example.com. This is called a Subdomain Takeover, and it is shockingly common even among Fortune 500 companies.

Inventory All CNAMEs: Verify that every third-party destination (S3, GitHub, Heroku, Zendesk) is still active and under your control.
Remove Old TXT Records: Delete verification codes for services your company hasn't used in years. These give attackers clues about your internal stack.
Clean Up MX records: If you’ve moved to Outlook, delete your old SPF and MX records for Gmail (and vice-versa).
Audit Wildcard Usage: Avoid *.example.com A records whenever possible. They make subdomain takeover scanning trivial for hackers.

Zone hygiene also includes the "Accuracy" of your nameserver delegation. Many companies use multiple DNS providers for redundancy but forget to keep them in sync. If your Primary DNS has the latest security records but your Secondary DNS is "Stale," an attacker can simply query your secondary server to bypass your defenses. A secure audit ensures that N-Primary or Primary/Secondary synchronisation is working perfectly.

We advocate for a "Zero-Waste" DNS policy. If a record isn't actively serving a purpose today, it should be deleted. This reduces your "Attack Surface" and makes your DNS logs much easier to read during a real security incident. You can use our DNS Zone Scan to find orphaned records and identify potential "Takeover" candidates before an attacker does.

Scoring and Prioritizing your Domain Security Maturity

Not all gaps in your security posture are equal. A missing HSTS header is a significant issue, but a missing DMARC record is a "Critical" failure. To make your audit actionable, you should "Score" your domain based on the severity of the identified gaps. This allows you to focus your limited resources on the "Highest-ROI" fixes first. We use a four-tier maturity model to help organizations prioritize their infrastructure security roadmap.

Security Tier	Mandatory Controls	Postural Impact
Critical	Registrar MFA, DMARC p=reject, Valid TLS	Prevents immediate account theft and phishing
High	DNSSEC, HSTS (with subdomains), CAA	Prevents hijacking and transport-layer attacks
Medium	CSP, No Stale CNAMEs, TLS 1.3	Hardens application and reduces takeover risk
Optimized	HSTS Preload, CTA Monitoring, BGP Filtering	Enterprise-grade "Zero Trust" infrastructure

As indicated in the table, Critical controls are the baseline for any functional business. If you don't have MFA on your registrar account, nothing else matters—your domain can be stolen tomorrow. Once those firebreaks are in place, you move to the High tier to harden your traffic against network-level spoofing. The final tiers are about "Finesse"—optimizing headers and monitoring to stay ahead of the most sophisticated attack classes.

Your goal isn't to reach "Tier 4" in a single afternoon. It's to systematically close the gaps in order of their "Ease of Exploitation." Start with the records that take 5 minutes to fix (like SPF and CAA). Then move to the ones that require more coordination (like DMARC enforcement and DNSSEC). By following a structured "Maturity Path," you ensure that your security gains are permanent and don't break your production services.

To jumpstart this process, run our Domain Health Report. It will automatically generate a score based on this checklist, providing you with a "To-Do List" ranked by severity. This report can be shared with your IT, Security, and Engineering teams to coordinate the "Hardening" of your organization's digital perimeter.

Frequently Asked Questions

Q: Can I have a "Secure Posture" without DNSSEC?

You can be "Safe," but you aren't "Verified." DNSSEC is the only way to prove to the internet that your DNS answers are legitimate. While you can have great headers and email security, your users are still technically vulnerable to "Cache Poisoning" at the ISP level unless you use DNSSEC. It is the final "Seal of Authenticity" for your domain.

Q: Why is registrar MFA so important?

Because the registrar is the "Keys to the Kingdom." An attacker with access to your registrar can change your nameservers to point to their servers. Once they do that, they can create their own SPF, DKIM, DMARC, and SSL certificates. They bypass every other security control on this list. Registrar MFA is the single most important line of defense.

Q: Does it matter if my parked domains have security records?

Yes. Parked domains are often used in "Shadow Phishing" attacks. Attackers know that IT teams neglect unused domains. They can spoof your parked domain to send email that looks like it's from your company. You should ALWAYS set v=spf1 -all and p=reject on every domain you own, even if it has no website.

Q: Will security headers slow down my website?

No. In some cases, like HSTS, they can actually make it faster. HSTS tells the browser to skip the "HTTP-to-HTTPS" redirect step and go straight to the secure connection, saving a full round-trip to the server. Most other headers add only a few bytes of data to the response.

Q: How often should I audit my subdomain takeovers?

Ideally, every time you decommission a service. If you stop using a third-party app, deleting the associated DNS record should be the very next step. For large teams, we recommend a monthly automated scan of all CNAME records to find any that are returning "404 Not Found" errors from the hosting provider.

Q: What is the most common reason for a "Broken" security posture?

Technical Debt. Most companies have hundreds of records from old projects and previous IT managers. These stale records create holes in your security perimeter. The best thing you can do for your domain's security is to "Sanitize" your zone and remove anything that isn't actively required today.

Next Steps

Generate your first baseline report using our Domain DNS Security Audit. This tool will scan your apex domain and common subdomains for the 25 most critical configuration errors, giving you an instant "Maturity Score" and a prioritized fix-list.

Once you have your report, follow our deep-dive guides into the specific areas where you scored lowest: DMARC Enforcement for email, DNSSEC Implementation for resolution, or Security Header Setup for the web. If you're managing a large portfolio, see our DNS Infrastructure guide for enterprise management tips.

Browse all Security Guides on DNSnexus for advanced documentation on BGP stability, Registry Locks, and Hardware MFA implementation.

Domain DNS Security Posture: A Full Audit Checklist