CNAME Drift Explained for Agencies: Why Client Domains Break After DNS Changes

CNAME drift is what happens when a CNAME record that was correctly configured at some point stops pointing at the right target — because the client changed their DNS provider, the hosting platform changed its infrastructure, or a subdomain was never cleaned up after a platform migration.

It is the most common DNS failure for agencies managing client domains across multiple hosting platforms, and it is consistently the failure mode that standard uptime monitoring misses.

What a CNAME Record Does

A CNAME record — Canonical Name record — maps one hostname to another. When you configure a client's custom domain on Vercel, Netlify, Cloudflare Pages, or Shopify, you set a CNAME record in their DNS that points their domain at the hosting platform's hostname:

www.clientdomain.com → cname.vercel-dns.com
shop.clientdomain.com → shops.myshopify.com
api.clientdomain.com → api-prod.clientapp.com

When a browser requests www.clientdomain.com, DNS resolves the CNAME chain: www.clientdomain.com → cname.vercel-dns.com → the actual IP address of Vercel's infrastructure. Vercel reads the incoming hostname, matches it to the project configured for www.clientdomain.com, and serves the site.

The CNAME record is the delegation: it tells DNS that the canonical address for this hostname lives somewhere else. Everything downstream — SSL certificate provisioning, CDN routing, platform routing — depends on that delegation being intact.

What CNAME Drift Is

CNAME drift is when the delegation breaks. The CNAME record either no longer exists, now points at the wrong target, or points at a target that no longer responds correctly for that hostname.

The "drift" framing is useful because the break usually does not happen instantly. It happens through a sequence of changes — often on the client's side — that incrementally move the DNS configuration away from its original correct state. By the time the symptoms appear, the root cause happened days or weeks earlier.

The most common causes

DNS provider migration. A client migrates their domain registrar or switches DNS providers — often as part of a broader IT consolidation or because they found a cheaper registrar. They export their DNS records and import them into the new provider. The import is incomplete: some records transfer correctly, others are dropped, and CNAMEs for subdomains the client doesn't actively use are skipped entirely. The client does not notice because the subdomains they are not actively using appear fine — until the CDN cache expires or the SSL certificate tries to renew.

Hosting platform infrastructure changes. Hosting platforms occasionally change their CNAME target hostnames as they update infrastructure or rebrand services. Vercel has changed its CNAME target format. Shopify has updated its custom domain CNAME targets. Platforms typically communicate these changes and provide a migration window, but clients who do not actively manage their DNS may miss the notification. When the old CNAME target stops responding for a hostname, the break surfaces.

Migration residue. A client moves from one hosting platform to another. The agency updates the CNAME for the primary domain to point at the new platform. Subdomains that were used by the old platform — blog.clientdomain.com on a WordPress multisite, media.clientdomain.com on a legacy CDN — are not cleaned up. They continue to point at the old platform. When the old platform decommissions the client's account or reassigns the server behind that hostname, the CNAME now resolves to the wrong place. If the SSL certificate on the other end does not cover the original hostname, browsers show a certificate mismatch error.

Subdomain squatting. A variation of migration residue that is increasingly common: when an old CNAME target is decommissioned and the hostname is later assigned to a new tenant on the same platform, requests to the original CNAME are served by whatever is now configured for that hostname. This is sometimes called subdomain takeover. An attacker who registers a new service at the old platform hostname and claims the dangling CNAME target can serve content under the client's subdomain. This is a security issue as well as a reliability issue.

Nameserver override. A client's IT department adds a nameserver record or changes the SOA that overrides DNS resolution for a subdomain. Nameserver records at a subdomain level can delegate DNS authority for that subdomain to a different DNS provider, effectively bypassing the CNAME records configured in the primary DNS zone.

Why Uptime Monitoring Misses CNAME Drift

Standard uptime monitoring checks whether a URL returns a successful HTTP response. It sends an HTTP request to the URL and checks the status code. If the status is 200, the monitor reports "up."

CNAME drift breaks the DNS layer — not the HTTP layer. When a CNAME record is misconfigured, the resolution chain either fails (DNS NXDOMAIN) or resolves to the wrong IP address. The correct failure response at the DNS layer is for the URL check to fail with a connection error or a DNS resolution error.

But in practice, the failure is often not immediate. CDN caches warm the correct IP address. Clients on networks with aggressive DNS caching continue to resolve the old, correct answer for hours or days. The uptime monitor, making requests from its own resolver on its own network, may hit the break immediately — or it may also cache the old answer.

The more subtle failure is when the CNAME drift resolves but resolves to the wrong target. The DNS lookup succeeds. A server responds. But the server behind the new CNAME target is serving content for a different domain, returning a 404 for requests to the original hostname, or presenting an SSL certificate that does not cover the original hostname. A status code check from a standard monitor may see a 200 from the new server and report "up" — while the site is effectively broken from the client's perspective.

CNAME integrity monitoring — specifically checking whether the CNAME record's target matches the expected value — detects drift at the DNS level, before the HTTP layer is affected, and before CDN caching masks the break from URL-based checks.

How to Detect CNAME Drift

What to check

For each CNAME record you are responsible for monitoring, you need:

The expected target value — the hostname the CNAME should point at (e.g., cname.vercel-dns.com)
The current resolved value — what the CNAME actually resolves to right now
Whether they match

If they do not match — or if the CNAME no longer exists — that is drift.

Checking manually

You can check CNAME records manually using dig or nslookup:

dig CNAME www.clientdomain.com

The ANSWER SECTION shows the current CNAME target. Compare it against what it should be. This works for one-off checks but does not scale to a client portfolio.

Using multiple resolvers

DNS propagation means that different resolvers may return different answers for a recently changed record. Checking from a single resolver can give you the cached old answer for a record that has already been changed. Effective CNAME integrity monitoring queries multiple independent resolvers and flags divergence between them as well as divergence from the expected value.

Frequency

CNAME drift can happen at any time — the DNS change that causes it happens on the client's side without any notification to the agency. Checking every 5 to 15 minutes is sufficient to catch drift within a monitoring interval. Checking once per hour means that a CNAME record can break and partially recover via CDN caching before you detect it.

What to Do When You Detect Drift

Identify when the change happened. Most DNS providers log changes. If the client has access to their DNS provider dashboard, check the change history. This establishes whether the drift was an accidental deletion during a migration, a deliberate change the client made and forgot to mention, or an unexpected platform change.

Restore the correct CNAME record. Add the correct CNAME record back in the client's DNS provider with the expected target value. If the client migrated DNS providers, add it to the new provider.

Check for certificate impact. If the CNAME has been broken for more than a few hours, the hosting platform's SSL certificate renewal may have failed. Verify that the SSL certificate is still valid and that the hosting platform has re-provisioned or renewed it after the CNAME was restored. Some platforms re-provision automatically within minutes; others require a manual trigger.

Check for subdomain takeover risk. If the CNAME was pointing at a decommissioned service and the drift has been in place for a significant time, verify that no other tenant has claimed the target hostname. If a takeover has occurred, the priority is removing the dangling CNAME record entirely until you can confirm a safe new target.

Document the incident. Record what broke, when, how it was caught, and how it was resolved. This documentation belongs in the client report and in your own records. If it was caused by a client action, note that clearly — not accusatorially, but factually. If the client's IT team changed the DNS provider without notifying the agency, that is context that matters for future DNS changes.

Preventing CNAME Drift Before It Happens

The most effective prevention for CNAME drift is monitoring — you cannot reliably prevent clients from making DNS changes without notifying you, and you cannot prevent hosting platforms from updating their infrastructure. What you can control is how quickly you detect the drift and how much damage it causes before you act.

For agencies managing CNAME records across multiple clients and multiple hosting platforms, the practical prevention steps are:

Document the correct CNAME target value for every subdomain you are responsible for monitoring at project handoff
Run CNAME integrity checks on every monitoring interval, not just daily
Set up alerts that fire on target mismatch, not just DNS resolution failure
Include CNAME integrity status in monthly client reports so clients understand that their DNS is being actively watched

The monitoring goal is to know about a CNAME change within minutes — before CDN caching hides the break, before SSL certificate renewal fails, and before a client or their customer encounters an error.