Hosting and DNS Audit Checklist for Agencies When Onboarding New Clients

When an agency takes over a website, the riskiest part is rarely the design or content. It is the messy combination of domains, DNS, email routing and half-documented hosting that has grown over years. If you do not standardise how you audit these pieces on day one, you inherit every hidden problem: broken email, slow sites, mixed SSL, orphaned subdomains and surprise downtime during the first change you make. In this guide, we share a practical hosting and DNS audit checklist we use at dchost.com when onboarding new clients and agency partners. You can adapt it to your own process, tick through it on every project and massively 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 solves these problems before they bite you. 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 you discover domains are not owned by the client, make it a priority to transfer them to an account controlled by the client (with your agency as a technical contact). 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 DNS changes you see in the panel match what public DNS resolvers return.
• 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 actual current hosting server 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 and can hide caching issues.

Checklist:

• ☐ Note current TTLs for A/AAAA, CNAME, MX and NS records.
• ☐ For upcoming migrations, plan to lower TTLs 24–48 hours before the cut‑over.
• ☐ 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

Email is where DNS mistakes hurt the most. 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 record listing IPs and services allowed to send mail for the domain.
• DKIM – Public keys in DNS that match private keys used by mail servers to sign messages.
• DMARC – Policy (none/quarantine/reject) and reporting addresses for handling failed SPF/DKIM.
• rDNS / PTR – Reverse DNS mapping sending IPs back to a valid hostname.

Checklist:

• ☐ SPF record exists, uses a sane policy (e.g. ~all or -all) and includes all legitimate senders.
• ☐ No duplicate or conflicting SPF TXT records.
• ☐ DKIM is active for main sending systems (transactional email, newsletter, ticketing, etc.).
• ☐ DMARC record exists with appropriate policy level for the client’s risk tolerance.
• ☐ For self‑hosted mail on VPS/dedicated, PTR records are set correctly for outbound IPs.

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; at dchost.com we provide both options, plus dedicated servers and colocation 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) and ensure it is not misapplied to temporary domains.

Checklist:

• ☐ A valid SSL certificate covers all active hostnames.
• ☐ HTTP requests redirect to HTTPS exactly once (no redirect chains or loops).
• ☐ 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 slow queries, timeouts or 500 errors.

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 at dchost.com when needed.

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, PHP‑FPM settings, Nginx micro‑caching, Varnish).
• CDN caching rules (HTML caching, static assets, API paths excluded).

Checklist:

• ☐ Confirm which layer is responsible for HTML caching (server vs CDN vs plugin).
• ☐ Ensure admin areas, carts and checkouts bypass full‑page caches.
• ☐ 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 the CDN is in full proxy mode (orange cloud style) or DNS‑only.
• 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, disable direct root SSH login and enforce strong credentials.
• ☐ 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 clients hosted on VPS or dedicated servers with dchost.com, we can help you apply a hardened baseline similar to what we describe 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 staging) to verify backups are actually usable.
• ☐ Document who is responsible for monitoring backup jobs (client, agency, hosting provider).

At dchost.com, we strongly recommend a 3‑2‑1 approach: multiple copies, on different media and at least one 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 (another dchost.com VPS, different region, etc.).
• 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 dchost.com 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, you will have a stable, predictable environment for all your projects.

7.3 Plan Future Improvements After the Audit

The audit itself should not block urgent projects, but it should generate a backlog of improvements, such as:

• Migrating from fragile shared hosting to a right‑sized VPS or dedicated server.
• 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 with dchost.com

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 cobbled together from multiple providers. 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”.

At dchost.com, we work with many agencies that have formalised this exact process. They use a simple audit to decide when to leave existing hosting in place, when to move to an agency reseller plan, and when a dedicated VPS or physical server (or even colocation) makes more sense for performance or compliance reasons. Because we also provide domains and DNS hosting, you can gradually centralise key pieces under one roof while still keeping clear lines of ownership for your clients.

If you want help adapting this checklist to your agency’s workflow or planning a safe migration path from a messy legacy stack, our team is happy to share real‑world examples from projects we host. Start with one new client: run through the audit, document everything, and then refine the template. Within a few months, onboarding a new website will feel routine instead of risky—and you will spend your time on strategy, design and growth, not on emergency DNS detective work.