DNS Record Audit Template for Agencies: A Per-Client Checklist

DNS records are the foundation that everything client-facing depends on. SSL certificates, email delivery, website availability, form submissions, and CDN performance all depend on the correct DNS records being in place at the client's registrar. When DNS breaks, everything breaks — usually silently and often not immediately.

Web agencies accumulate DNS surface across clients faster than it can be manually tracked. A client who migrates to a new registrar, hands DNS management to their IT team, or "cleans up" their DNS zone can introduce breaks across their production site, staging environment, email delivery, and SPF records in a single operation — without the agency knowing until something stops working.

This template is designed to run against each client in your portfolio on a monthly basis. It takes 10–15 minutes per client with command-line access, or can be partially automated with DNS monitoring tooling. The sections are ordered from highest-impact (site availability) to supporting infrastructure (email, security records).

How to Use This Template

Run each check against the client's primary domain and any subdomains your agency manages. Note the current record value next to each check and flag any deviation from the expected value. At the end, record findings and send a brief summary to the client contact with any action items.

Tools needed:

dig (available on macOS/Linux; on Windows, use nslookup or the Windows Subsystem for Linux)
whois for domain registration checks
openssl for SSL chain verification

Substitute clientdomain.com with the client's actual domain in every command.

Section 1: Domain Registration

1.1 Domain registration expiry

whois clientdomain.com | grep -i "expir"

Expected: Expiry date more than 60 days from today.

Flag: Within 60 days — contact client to confirm renewal is scheduled. Within 30 days — escalate; request confirmation of renewal completion.

1.2 Registrar and nameserver set

whois clientdomain.com | grep -i "name server"

Expected: Nameservers match the current DNS provider (Cloudflare, the registrar's own DNS, or the DNS provider the agency manages on behalf of the client).

Flag: Nameservers have changed since the last audit without agency notification — investigate why and confirm the DNS zone has been fully migrated.

Section 2: Website DNS — A and CNAME Records

2.1 Apex domain resolution

dig A clientdomain.com +short

Expected: IP address resolving to the hosting platform — Shopify's IP range, Webflow's load balancer, WordPress hosting provider, etc.

Flag: IP changed without notification. IP resolves to previous hosting platform (nameserver migration carried old records). Record missing.

2.2 www subdomain CNAME

dig CNAME www.clientdomain.com +short

Expected: CNAME pointing to the correct platform endpoint — shops.myshopify.com, proxy-ssl.webflow.com, [site].netlify.app, cname.vercel-dns.com.

Flag: CNAME target has changed. CNAME is missing (www returning NXDOMAIN). CNAME points to a decommissioned platform project (common when agencies migrate clients between platforms without DNS cleanup).

2.3 Platform-specific CNAME targets

List every subdomain your agency has configured for this client and verify each CNAME:

Subdomain	Expected CNAME Target	Actual	Status
www	proxy-ssl.webflow.com
staging	[branch].netlify.app
api	[gateway].vercel-dns.com
shop	shops.myshopify.com

Flag: Any deviation from expected CNAME target. A CNAME pointing to a previous platform is particularly important — it means the old hosting platform could theoretically serve content for the client's domain if the old project still exists.

2.4 Propagation consistency check

dig CNAME www.clientdomain.com @8.8.8.8 +short
dig CNAME www.clientdomain.com @1.1.1.1 +short
dig CNAME www.clientdomain.com @208.67.222.222 +short

Expected: All three resolvers return the same CNAME target.

Flag: Inconsistent results across resolvers — may indicate a recent DNS change that has not fully propagated, or a split-horizon DNS configuration that needs documentation.

Section 3: SSL Certificate Records

3.1 SSL certificate expiry

echo | openssl s_client -connect clientdomain.com:443 2>/dev/null | openssl x509 -noout -dates

Expected: notAfter date more than 30 days from today.

Flag: Within 30 days — schedule renewal. Within 14 days — escalate; initiate renewal immediately.

3.2 SSL chain completeness

openssl s_client -connect clientdomain.com:443 -showcerts 2>/dev/null | grep "BEGIN CERTIFICATE" | wc -l

Expected: 2 or more certificates in the chain (leaf + at least one intermediate). For some platforms, 3 is standard.

Flag: 1 certificate only — the intermediate chain is missing. This will cause SSL errors in some clients even though the certificate is valid and unexpired.

3.3 CAA record check

dig CAA clientdomain.com +short

Expected: No CAA records (open issuance, common for SME clients), or CAA records that include the platform's certificate authority.

Flag: CAA records exist that do not include letsencrypt.org (if the platform uses Let's Encrypt), digicert.com, or the relevant CA. This will block the next certificate renewal.

Section 4: Email DNS Records

4.1 MX records

dig MX clientdomain.com +short

Expected: MX records pointing to the client's email provider — Google Workspace (aspmx.l.google.com), Microsoft 365 (clientdomain-com.mail.protection.outlook.com), etc.

Flag: MX records missing. MX records pointing to previous email provider. Priority values incorrect (should have a low-number primary and higher-number fallbacks, not equal priorities across all records).

4.2 SPF record

dig TXT clientdomain.com +short | grep "v=spf1"

Expected: SPF record includes the client's email sending providers — Google Workspace (include:_spf.google.com), Microsoft 365 (include:spf.protection.outlook.com), CRM tools, transactional email services.

Flag: SPF record missing — email delivery will be impaired and phishing risk increases. Multiple SPF records — only one SPF TXT record is valid per domain; duplicates cause the SPF check to fail. SPF +all qualifier — allows anyone to send as the domain; should be ~all or -all.

4.3 DKIM record

For each email provider configured on the domain, check the DKIM record. The selector depends on the provider.

Google Workspace: dig TXT google._domainkey.clientdomain.com +short Microsoft 365: dig TXT selector1._domainkey.clientdomain.com +short

Expected: A valid DKIM public key record.

Flag: Record missing. Record returns NXDOMAIN. Record is syntactically malformed (common after DNS zone migrations that truncate long TXT records).

4.4 DMARC record

dig TXT _dmarc.clientdomain.com +short

Expected: v=DMARC1 record with a p= policy of none, quarantine, or reject.

Flag: Record missing — no DMARC policy in place. Policy is p=none with no aggregate reporting address (rua=) — no visibility into spoofing attempts.

Section 5: Security and Verification Records

5.1 Domain verification TXT records

Many platforms require TXT records for domain ownership verification — Google Search Console, Bing Webmaster Tools, SSL certificate authorities, SaaS platforms. These records are often added once and never audited again.

dig TXT clientdomain.com +short

Expected: TXT records for currently-active platform integrations only.

Flag: TXT records for platforms the client no longer uses (old analytics platforms, decommissioned SaaS tools, previous email providers). These are low-risk but add clutter and should be cleaned up. More importantly, note any TXT records you cannot identify — they may have been added by the client or a previous agency without documentation.

5.2 _dmarc and _domainkey subdomains for decommissioned services

dig TXT _domainkey.clientdomain.com +short
dig TXT mail._domainkey.clientdomain.com +short

Check for DKIM selectors from services the client no longer uses — old ESPs, previous marketing automation platforms. These are harmless but signal DNS zone drift and should be noted.

Recording Findings

At the end of each client audit, record:

Date of audit
Domain expiry date (so you know when to alert the client)
SSL expiry date (so you know when renewal is needed)
CNAME targets for all managed subdomains (so you have a baseline for future comparisons)
Any flags raised and action taken (or pending client action)

A simple spreadsheet with one row per client and these five columns is sufficient for most agencies. The goal is a baseline that makes the next audit faster — you are comparing current values against the recorded baseline rather than reconstructing expected values from memory.

What to Monitor Between Audits

Monthly audits catch drift that accumulated since the last check. Between audits, the conditions that warrant immediate investigation are:

A client mentions their site is "acting weird" or emails are going to spam
A client migrates to a new registrar, IT provider, or DNS management tool
A platform sends an SSL renewal notification (investigate DNS before the renewal)
A client decommissions a hosting platform or switches email providers

Automated DNS monitoring — checking CNAME integrity and SSL expiry continuously — catches these conditions as they happen rather than at the next monthly audit.

Merlonix monitors CNAME records using three independent resolvers, tracks full SSL chain integrity, and alerts on domain registration expiry 30 days in advance. The automated monitoring covers sections 2 and 3 of this template continuously — so the monthly audit can focus on email records, security records, and the documentation step.

Start a free 14-day trial — no credit card required.