Hosting and DNS Audit Checklist for Agencies

When an agency takes over a website, domains, DNS, email routing and half-documented hosting can pose risks beyond the design or content. Without a structured audit, hidden problems such as broken email, slow sites, mixed HTTP/HTTPS content and orphaned subdomains can cause surprises during the first change. This guide provides a practical hosting and DNS audit checklist for onboarding new clients and agency partners. You can adapt it to your own process and work through it on every project to help reduce surprises later. We will walk through ownership, access, DNS records, email, hosting environment, performance, security, backups and documentation, with concrete questions to ask and items to verify.

Why Agencies Need a Hosting and DNS Audit on Day One

Many agencies jump straight into redesigning the website or connecting analytics, only to discover later that:

• The domain is owned by a former freelancer, not the client.
• DNS is split across several providers and nobody is sure which one is authoritative.
• Email routing depends on a fragile MX setup and outdated SPF records.
• The site is running on an overloaded shared hosting plan with no usable backups.

An early, structured audit helps identify these problems so you can prioritise fixes. It allows you to:

• Clarify who owns what and who can approve critical changes.
• Map domain, DNS, hosting and email so your team is not guessing.
• Spot quick wins: SSL fixes, HTTP to HTTPS redirects, simple performance gains.
• Plan safe migrations, redesigns and campaign launches on top of a stable foundation.

Use the checklist below as a repeatable onboarding template. For deeper background on how these building blocks work together, you can also read our article what is web hosting and how domain, DNS, server and SSL work together.

Step 1 – Map Ownership, Providers and Access

1.1 Identify Who Owns What

Before touching any setting, draw a simple map of ownership. For each item below, write down both the legal owner and the current administrator.

• Primary domain(s) and key subdomains
• Domain registrar account
• DNS provider / nameserver host
• Web hosting account (shared, reseller, VPS, dedicated, or colocation)
• Email service (self-hosted, hosting-based or third-party service)
• CDN / WAF / reverse proxy in front of the site, if any

Questions to ask the client:

• Which email address receives registrar renewal emails and invoices?
• Has any previous agency or freelancer registered domains in their own name?
• Is there any shadow DNS (old nameservers still used by subdomains)?

If domains are registered in someone else’s name, resolve ownership and obtain the necessary authorisation before making changes. Arrange client-controlled account access and any required registrant update, with delegated agency access where supported; moving a domain between accounts alone does not establish ownership. Our article on how to transfer a domain without downtime explains the safest process.

1.2 Collect Logins and Stabilise Access

Once owners are clear, collect credentials in a secure way (password manager, secrets vault, not email threads). You typically need:

• Registrar login
• DNS provider panel login
• Hosting control panel (cPanel, Plesk, DirectAdmin or custom panel)
• Server SSH or RDP access for VPS / dedicated / colocation
• Admin access for email service, CDN / WAF, analytics and tag managers

Security steps to include in your checklist:

• ☐ Enable 2FA on registrar, DNS and hosting accounts.
• ☐ Change passwords previously shared with old agencies or freelancers.
• ☐ Create separate logins for your agency instead of reusing the client’s personal login.

For agencies managing many clients, structured access is crucial. Our guide on DNS and domain access management for agencies shares practical patterns that scale.

Step 2 – Full DNS Health Check

2.1 Confirm Nameservers and DNS Hosting

Your first DNS task is to confirm which nameservers are actually authoritative for the domain. Check at the registrar:

• List the current nameservers (e.g. ns1.example-isp.com, ns2.example-isp.com).
• Verify that the DNS panel matches responses from the authoritative nameservers, then compare public resolver responses while allowing for cached answers and their TTLs.
• Note any legacy nameservers still referenced by subdomains or glue records.

Checklist:

• ☐ Authoritative nameservers identified and documented.
• ☐ Registrar’s nameserver settings match the intended DNS provider.
• ☐ No unexpected third-party nameservers (e.g. left from an old provider).

If the client uses custom nameservers branded on their own domain (ns1.client.com, ns2.client.com), verify glue records and IPs. For a step‑by‑step approach, see our article on private nameservers and glue records.

2.2 Inventory All DNS Records

Next, take a snapshot of all DNS records. Export them from the DNS panel or manually copy them into your documentation. Pay special attention to:

• A / AAAA – IPv4 and IPv6 for root domain (example.com), www and key subdomains.
• CNAME – Aliases for app.example.com, cdn.example.com, tracking and third-party tools.
• MX – Email routing and any backup MX servers.
• TXT – SPF, DKIM, DMARC, verification records (Google, Meta, Microsoft, etc.).
• SRV – VOIP, chat, Office/Teams and other services.
• CAA – Which certificate authorities are allowed to issue SSL for the domain.

Questions to ask while reviewing:

• Do A and AAAA records point to the intended hosting server, CDN or reverse proxy, or to an obsolete IP?
• Are there multiple A records with different IPs (intentional load balancing or a misconfiguration)?
• Is www an A record or a CNAME to the root, and is it consistent with your redirect strategy?
• Do MX records match the client’s real email platform?
• Are there leftover TXT or CNAME records from old tools that can be removed?

For a friendly deep dive into each record type (including common mistakes), you can refer to our article DNS records explained like a friend: A, AAAA, CNAME, MX, TXT, SRV, CAA and the gotchas.

2.3 Check TTLs and Plan Change Windows

Time To Live (TTL) controls how long resolvers cache DNS answers. For new clients, you often find:

• Very high TTLs (e.g. 24 hours) that slow down propagation during migrations.
• Very low TTLs (e.g. 60 seconds) that increase DNS query load.

Checklist:

• ☐ Note current TTLs for A/AAAA, CNAME, MX and NS records.
• ☐ For upcoming migrations, lower the TTLs of records that will change at least one existing TTL before the cut‑over; 24–48 hours is sufficient only if it covers that interval.
• ☐ After stabilisation, raise TTLs again to reasonable defaults (e.g. 1–4 hours for critical records).

We share practical TTL patterns and migration timing in our guide the TTL playbook for zero‑downtime migrations. It fits perfectly as a follow‑up to this audit.

2.4 DNS Security: DNSSEC, Dangling Records and Subdomain Takeover

As part of your audit, capture the DNS security posture:

• DNSSEC – Is DNSSEC enabled at the registrar and correctly configured on the DNS provider?
• Dangling DNS – Any CNAMEs pointing to decommissioned services that could be hijacked?
• Wildcard records – Are there broad wildcard A/CNAME records that expose test subdomains?

Checklist:

• ☐ Confirm whether DNSSEC is enabled and not in a broken state (mismatched DS records).
• ☐ Identify DNS records pointing to services the client no longer uses.
• ☐ Remove or correct dangling records to reduce subdomain takeover risk.

For clients with higher security requirements, consider planning DNSSEC activation after any immediate migration work is done. Our piece what is DNSSEC and when should you enable it walks through a practical rollout process.

Step 3 – Email and Deliverability Audit

3.1 MX Setup and Redundancy

DNS mistakes can disrupt business‑critical email. Start by documenting:

• Current MX records, priorities and target hosts.
• Whether there is a backup MX server and if it is still maintained.
• Any split delivery or forwarding rules between services.

Questions to clarify with the client:

• Which inboxes are business‑critical (billing, support, sales, HR)?
• Have they had recurring issues with emails going to spam or bouncing?
• Are there legacy mailboxes still receiving important mail (e.g. info@ used on old invoices)?

Checklist:

• ☐ MX records accurately represent the real, in‑use email platform.
• ☐ No obsolete MX records pointing to decommissioned servers.
• ☐ If redundancy is needed, backup MX servers are documented and tested.

3.2 SPF, DKIM, DMARC and Reverse DNS

Modern deliverability depends heavily on DNS‑side authentication:

• SPF – TXT policy authorising sending IPs for the envelope MAIL FROM or HELO domain, not the visible From address.
• DKIM – Public keys in DNS that match private keys used by mail servers to sign messages.
• DMARC – Policy (none/quarantine/reject) and reporting settings for messages that fail DMARC. Passing requires at least one successful SPF MAIL FROM or DKIM check aligned with the visible From domain; failure of just one mechanism does not necessarily mean DMARC failure.
• rDNS / PTR – Reverse DNS mapping sending IPs back to a valid hostname.

Checklist:

• ☐ SPF record includes all legitimate senders, stays within the 10 DNS‑causing term limit across nested evaluation, and uses an intentional policy (e.g. ~all for softfail or -all for fail).
• ☐ No duplicate or conflicting SPF TXT records.
• ☐ DKIM is active for main sending systems (transactional email, newsletter, ticketing, etc.).
• ☐ DMARC record exists; policy selection considers the client’s risk tolerance, authentication alignment for legitimate senders and report findings before enforcement is tightened.
• ☐ For self‑hosted mail on VPS/dedicated, each outbound IP has a PTR hostname whose forward A/AAAA record resolves back to that IP.

Improving email authentication is often a quick win early in an engagement. If you want a deeper playbook, see our detailed explanation of how to improve email deliverability with SPF, DKIM, DMARC and rDNS.

Step 4 – Hosting Environment and Server Configuration

4.1 Identify the Hosting Type and Capacity

Understanding the current hosting environment is essential before planning any redesign or marketing campaigns. For each site or application, capture:

• Hosting type: shared hosting, reseller hosting, VPS, dedicated server or colocation.
• Control panel: cPanel, Plesk, DirectAdmin, custom panel or none (pure SSH).
• Resource limits: vCPU, RAM, storage, inode limits, bandwidth quotas.
• Current average and peak usage (CPU, RAM, disk IO, bandwidth, database load).

Checklist:

• ☐ Hosting type and plan documented for each domain or project.
• ☐ Server location (country/region) noted for performance and data‑protection reasons.
• ☐ Any upcoming campaigns or traffic spikes considered in capacity planning.

If you manage many client sites, consider standardising on an agency‑friendly stack like reseller hosting or an agency VPS cluster. Our article on reseller hosting vs VPS for agencies discusses realistic architectures; dedicated servers and colocation are further design options for larger setups.

4.2 Platform Versions: PHP, Database, OS

Outdated software is a security risk and a barrier to performance tuning. For each hosting environment, note:

• PHP version(s) in use per site.
• Web server: Apache, Nginx, LiteSpeed and their version.
• Database engine and version: MySQL, MariaDB, PostgreSQL.
• Operating system: e.g. AlmaLinux, Debian, Ubuntu, plus major version.

Checklist:

• ☐ PHP version still supported and compatible with site CMS/framework.
• ☐ Database version supported and receiving security updates.
• ☐ OS still within vendor support window.

Document any blockers (custom code requiring older PHP, legacy extensions) and plan upgrades as a separate mini‑project. Our library includes in‑depth pieces like choosing the right Linux distro for VPS web hosting and tuning PHP OPcache settings for WordPress and Laravel once the basics are clean.

4.3 SSL/TLS, Redirects and Canonical URLs

Misconfigured SSL and redirects are common on inherited projects. For each domain:

• Check if a valid SSL/TLS certificate is installed (not expired, correct hostname, full chain).
• Test HTTP → HTTPS redirects for both root and www/non‑www.
• Check that canonical host (with or without www) is consistent across redirects, sitemap and SEO settings.
• Verify HSTS configuration (if used), including policy lifetime and whether all covered hostnames, including subdomains when included, can maintain valid HTTPS.

Checklist:

• ☐ A valid SSL certificate covers all active hostnames.
• ☐ HTTP requests redirect to the canonical HTTPS URL without loops; avoid unnecessary redirect chains and aim for a single hop where feasible.
• ☐ A single canonical hostname is enforced for SEO consistency.

If you discover browser warnings or mixed‑content issues, prioritise fixing SSL early. Our posts on common SSL certificate errors and full HTTP to HTTPS migration with 301 redirects and HSTS can guide your remediation plan.

Step 5 – Performance, Caching and CDN

5.1 Baseline Performance from the Server Side

Before changing code or design, capture how the current hosting responds:

• Measure TTFB (Time To First Byte) from multiple regions.
• Check CPU, RAM and disk IO usage during peak traffic times.
• Review web server and PHP error logs for timeouts or 500 errors; use database slow‑query logs or query profiling to investigate slow queries.

Checklist:

• ☐ Identify whether slowness is due to hosting limits, database issues or application code.
• ☐ For WordPress / PHP sites, note if object cache (Redis/Memcached) is enabled.
• ☐ Confirm if HTTP/2 or HTTP/3 (QUIC) is enabled on the server and CDN.

Your audit does not need to fix everything immediately, but documenting baseline performance informs your future hosting choices, such as moving heavy stores to a VPS or dedicated server when measured resource needs justify it.

5.2 Caching Layers: Application, Server and CDN

Inherited projects often have overlapping or conflicting cache layers. Identify:

• Application‑level caching (WordPress plugins, Laravel caching, Magento FPC).
• Server‑side caching (OPcache, Nginx micro‑caching, Varnish).
• CDN caching rules (HTML caching, static assets, API paths excluded).

Checklist:

• ☐ Map all HTML cache layers (server, CDN and plugin) and document how updates invalidate each layer.
• ☐ Ensure admin areas, carts, checkouts and other personalised or authenticated responses bypass shared full‑page caches unless safe isolation is explicitly configured and verified.
• ☐ Verify Cache‑Control headers, ETags and stale-while-revalidate policies are not contradictory.

During onboarding, your goal is to understand the existing stack and spot critical misconfigurations (e.g. pages that should not be cached). Later, when you stabilise the site, you can apply more advanced tuning such as server‑side Core Web Vitals improvements or specialised HTTP cache‑control and CDN rules.

5.3 CDN, WAF and Edge Configuration

If the client already uses a CDN or WAF in front of the site, document:

• Which domains and subdomains are on the CDN.
• Whether each hostname routes web traffic through the CDN/WAF or points directly to the origin.
• Any custom page rules, caching rules or WAF rules that could affect new features.

Checklist:

• ☐ Origin IPs noted for each CDN‑protected hostname.
• ☐ WAF level, rate‑limiting and bot protection settings documented.
• ☐ Any important firewall or WAF exceptions recorded to avoid breaking existing integrations.

Step 6 – Security, Backups and Disaster Recovery

6.1 Hosting‑Side Security Basics

As an agency, you might not own the infrastructure, but you are responsible for not leaving obvious doors open. During your audit, check:

• Is SSH access enabled with password login, or key‑based only?
• Is root login allowed directly on VPS/dedicated servers?
• Is a firewall (ufw, firewalld, iptables/nftables) configured?
• Are control panel logins protected with 2FA?

Checklist:

• ☐ At minimum, enforce strong credentials and disable direct root SSH login after verifying a non-root account with administrative privileges and a recovery access method.
• ☐ Ensure critical ports are restricted to necessary IPs where possible.
• ☐ For shared/reseller hosting, confirm file permissions are sane (no world‑writable 777 folders).

For VPS or dedicated server hardening, use the baseline described in our VPS security hardening guides.

6.2 Backup Coverage and Recovery Testing

Backups are only useful if you know where they are, how often they run and how to restore them. Document for each project:

• What backup system is used: hosting panel backups, custom scripts, external object storage, etc.
• Backup frequency: daily, hourly, weekly.
• Retention: how many days/weeks/months kept.
• What is actually backed up: files, databases, email, DNS configs.

Checklist:

• ☐ Confirm at least one off‑site backup exists (not only on the same server).
• ☐ Perform at least one test restore to an isolated staging environment, with outbound email, payments and production integrations disabled, to verify that the restored data and application work.
• ☐ Document who is responsible for monitoring backup jobs (client, agency, hosting provider).

At dchost.com, we strongly recommend a 3‑2‑1 approach: three copies of your data, including the production copy, across two different media types, with at least one backup copy off‑site. Our article on the 3‑2‑1 backup strategy and automation on cPanel/Plesk/VPS can help you standardise this across clients.

6.3 Simple Disaster Recovery Plan

Even a one‑page DR outline is better than nothing. As part of your audit, sketch:

• Recovery objectives: acceptable downtime (RTO) and data loss window (RPO).
• Where you would restore if the current server is lost (a replacement VPS or a server in another region, subject to availability and data residency requirements).
• Critical dependencies: database servers, object storage, external APIs.

Checklist:

• ☐ Agree a simple RTO/RPO expectation with the client.
• ☐ Note which backups would be used and where they are stored.
• ☐ Keep DR notes in the same shared documentation as your audit.

Step 7 – Documentation, Standards and Go‑Live Checklist for Agencies

7.1 Create a Living Hosting and DNS Sheet

All your audit work is wasted if it lives only in your head. Standardise a template (spreadsheet, ticket system, or internal wiki) with sections like:

• Domain and registrar details (ownership, renewal dates, contacts).
• DNS provider, nameservers, exported record set with timestamp.
• Hosting details: type, plan, resources, location, control panel.
• Email topology: MX, SPF/DKIM/DMARC, key mailboxes.
• SSL/TLS and redirect map (HTTP → HTTPS, www vs non‑www).
• Backups and DR notes.

This becomes your single source of truth. Every time you change something (e.g. move hosting to a new VPS), update the sheet and attach any migration notes.

7.2 Standard Agency Rules for New Clients

Use the audit findings to define your minimum standards for onboarding:

• All domains moved under client‑controlled registrar accounts, not personal accounts.
• 2FA enabled on registrar, DNS and primary hosting accounts.
• DNS cleaned of dangling records and documented.
• SPF/DKIM/DMARC configured for the primary sending domain.
• HTTPS enforced, with a valid certificate and clean redirect logic.
• At least daily backups with one off‑site copy.

These rules help you say “no” when a client asks for risky shortcuts. Over time, applying and maintaining these standards can make your project environments more stable and predictable.

7.3 Plan Future Improvements After the Audit

Separate findings that must be resolved before launch, such as critical security or recovery gaps, from improvements that can enter a backlog, such as:

• Migrating to a right‑sized VPS or dedicated server when the current hosting cannot meet measured resource or isolation requirements.
• Consolidating multiple small hosting accounts into an agency‑managed stack.
• Implementing staging environments for complex sites.
• Upgrading outdated PHP/DB versions in a controlled manner.

Our guide on hosting architecture for agencies managing 20+ WordPress sites shows how to turn those individual checklists into a coherent, scalable platform.

Turning Your Checklist into a Repeatable Onboarding Process

Once you have run this hosting and DNS audit for a few clients, patterns emerge. You see the same weak points: domains split across old registrars, DNS panels nobody remembers, shared hosting with no backups, email authentication missing, or SSL certificates with unclear renewal ownership. The goal is not to make every client’s infrastructure identical, but to bring each one up to a stable, well‑documented baseline where your team can move quickly without fear of “breaking the internet”.

An agency can use this audit to decide when to leave existing hosting in place, when to choose a reseller plan, and when a VPS, dedicated physical server or colocation arrangement better fits its performance, operational or compliance requirements. Consolidating domain registration, DNS and hosting is another option, provided client ownership remains clear and the chosen services meet the project’s requirements.

Start with one new client: run through the audit, document everything, and then refine the template. Use subsequent onboardings to identify recurring gaps and improve the checklist, so fewer issues reach launch unresolved.