A DNS health audit gives you a reliable inventory of what your domain does, which services still depend on it, and where stale or conflicting records create avoidable risk. This checklist explains what to review, how to verify findings with common DNS lookup tools, and how to turn the audit into a repeatable quarterly process.
Overview
DNS is often changed in small increments: a new website is connected, an email platform adds verification records, a staging system receives a subdomain, or an old service is replaced. Over time, the zone can contain records that no longer have an owner or purpose. That makes troubleshooting slower and can leave forgotten services reachable from the public internet.
A DNS audit is not simply a search for records that look unfamiliar. The objective is to connect each record to a current business or technical requirement, confirm that its value is correct, and remove or correct anything unsupported. The audit should cover the authoritative DNS provider, the complete zone, delegated subdomains, and the public results visible through DNS lookup tools.
Before making changes, export or copy the current zone and record the date, reviewer, and DNS provider. If the domain supports production email or a live website, use a change window and make one logical change at a time. DNS edits can affect unrelated services when records are shared or when a provider manages several functions under one configuration.
What to track
Build a records inventory
Create a working table with one row for every record. Include the following fields:
- Name: the hostname, such as
@,www,mail, orstaging. - Type: A, AAAA, CNAME, MX, TXT, NS, CAA, or another supported type.
- Value: the address, target hostname, mail server, verification token, or policy text.
- TTL: the time-to-live configured for the record.
- Purpose: website, email, authentication, verification, hosting, development, or unknown.
- Owner: a person or team responsible for confirming the record.
- Source and evidence: the service documentation, ticket, deployment configuration, or account that requires it.
- Status: keep, correct, investigate, or remove.
Exporting the zone from the DNS provider is a useful starting point, but it may not reveal every dependency. Ask website, infrastructure, email, analytics, security, and development owners which hostnames they use. Compare those answers with the zone inventory rather than assuming that an unfamiliar record is automatically obsolete.
Check common record groups
Review the root domain and web records first. Confirm that the A and AAAA records point to the intended hosting environment, and check whether www is meant to be an alias, a separate destination, or redirected by the web server. A CNAME that points to a retired platform is a strong candidate for investigation, but do not delete it until the related account and deployment have been checked.
Next, review MX records and email-related TXT records. Confirm that every listed mail exchanger is still used and that SPF, DKIM, and DMARC records match the current email services. An old SPF include or DKIM selector may no longer be necessary, while an accidental SPF replacement can disrupt mail authentication. Use the business email authentication guide when documenting these records.
Look for verification records created by hosting, certificate, analytics, collaboration, and developer platforms. Keep a note of the account or project that owns each token. A token with no known owner should be investigated rather than retained indefinitely.
Audit subdomains as assets
List every visible subdomain and classify it as production, internal, staging, development, marketing, redirect, or unknown. Pay particular attention to names such as dev, test, old, demo, vpn, and portal. These names can reveal systems that were created for a temporary purpose but never formally retired.
Check for dangling CNAMEs: records that point to a provider or project that no longer exists. Also review delegated subdomains with NS records. A delegated zone may be managed somewhere other than the main DNS provider, so deleting or changing its parent record without understanding the delegation can make an entire service unreachable.
Use a simple risk rating
| Rating | Typical finding | Action |
|---|---|---|
| High | Unknown delegation, abandoned service target, incorrect MX, or production record pointing to an unapproved destination | Escalate to the owner and investigate promptly; do not make an unreviewed destructive change |
| Medium | Stale verification token, unclear subdomain ownership, duplicate record, or inconsistent TTL | Assign an owner and resolve during the next controlled change window |
| Low | Missing documentation, an unnecessary but harmless record, or an outdated description | Document and clean up as part of routine maintenance |
Cadence and checkpoints
A quarterly audit is a practical baseline for an active domain. A smaller monthly review can focus on recent changes, new subdomains, email authentication, and records added by deployment tools. Run an additional audit before a hosting migration, domain transfer, major email change, or website relaunch. The website launch and migration checklist can help coordinate DNS with SSL, backups, and uptime testing.
At each review, compare the current zone with the previous inventory. Record additions, deletions, value changes, and ownership changes. A basic change log should include:
- Date and time of the change
- Hostname and record type
- Previous value and new value
- Reason for the change
- Requester, approver, and implementer
- Validation performed and result
- Rollback plan or previous configuration
After an edit, query the authoritative nameservers and at least one independent recursive resolver. Test the affected service directly: load the website, send and receive a test email where appropriate, validate the subdomain, or confirm that the provider recognizes its verification record. For a broader explanation of checking changes and delays, see the DNS propagation checker guide.
How to interpret changes
Not every difference is an error. DNS providers may display records in different formats, automatically add records, or use aliases that resolve through several layers. Focus on the effective result and the service requirement, not only on how the provider formats the entry.
Investigate conflicting records when two entries appear to claim the same function. Examples include an A record and CNAME at the same name, multiple competing MX sets, duplicate TXT policies, or both an old and new verification method left in place. Some record types allow multiple values, so the correct action depends on the protocol and the service documentation. Do not remove one merely because another value exists.
TTL should reflect operational needs. A shorter TTL can make planned changes easier to roll out, while a longer TTL can reduce repeated lookups for stable records. The appropriate value depends on the provider, record purpose, and change process. Avoid changing TTL as a substitute for fixing an incorrect record, and remember that existing cached answers may remain available until their previous TTL expires.
When you find a stale record, first identify its owner and verify that the associated service is no longer required. If the owner cannot be found, document the investigation and consider a staged response: lower the TTL during a planned window, remove the record, then monitor the affected hostname and service. Preserve the old value in the change log so it can be restored if an undocumented dependency appears.
When to revisit
Schedule the next DNS health audit at least quarterly, with a lightweight monthly check for domains that support frequent deployments or multiple cloud services. Revisit the zone immediately after a new service is connected, a provider account is closed, a team changes ownership, or a hosting, email, or domain transfer begins. The domain transfer guide is useful when separating registrar changes from DNS hosting changes.
End each audit with three concrete outputs: an updated records inventory, a prioritized list of unresolved findings, and a dated next-review reminder. If a record has no purpose, owner, or supporting evidence, mark it for investigation rather than allowing it to become permanent by default. If a change affects the root domain, email, or a widely used subdomain, require a second review and test the service after the change.
DNS stays healthy through small, documented reviews. A current inventory, clear ownership, cautious cleanup, and repeatable verification workflow make it easier to find stale DNS records before they become outages, confusing conflicts, or forgotten entry points into your infrastructure.
