DNS Monitoring for Marketing Agencies: Catching Changes Before They Break Client Sites

DNS changes are the silent disasters of agency client management. Unlike a server outage, which produces an immediate and obvious error, DNS problems often take hours or days to propagate, degrade gradually across different networks, and are nearly impossible to diagnose if you did not know the correct records before the change happened.

This guide covers what DNS monitoring means in an agency context, what types of changes cause the most damage, and how to catch them before your clients do.

What DNS Monitoring Actually Is

DNS monitoring is the practice of recording the authoritative DNS records for a domain at regular intervals and alerting when those records change unexpectedly.

The key word is unexpectedly. Not all DNS changes are bad — agencies make planned DNS changes constantly, when launching new sites, migrating hosts, or configuring email. Monitoring is not about blocking changes; it is about distinguishing planned changes from unplanned ones, and knowing about both within minutes rather than days.

A complete DNS monitoring setup tracks:

A and AAAA records — where the domain resolves (the hosting IP)
CNAME records — aliases pointing to CDNs, load balancers, or SaaS platforms
MX records — where email is delivered
TXT records — SPF, DKIM, DMARC, and domain verification tokens
NS records — which nameservers are authoritative for the domain
CAA records — which certificate authorities are allowed to issue SSL certificates

Why DNS Changes Break Things for Agencies

Hosting migrations gone wrong

When a client switches hosting providers, the new provider gives them new IP addresses and asks them to update their A records. The client (or sometimes the outgoing hosting provider) makes the change. If the change is incorrect — wrong IP, missing www record, missing redirects — the site breaks.

The agency often does not find out until a client calls. By then the TTL may have propagated the bad record to most resolvers worldwide, making a quick fix slow to take effect.

Registrar-level changes

Clients sometimes change their DNS settings at the domain registrar without telling the agency. They move nameservers to Cloudflare. They add a new subdomain using the registrar's basic DNS panel. They change a record that the agency set up years ago, not realising it serves an active function.

NS record changes are particularly dangerous because they effectively move all DNS control to a different provider, which may not have the correct records configured.

Third-party platform changes

CDN providers, email platforms, and SaaS tools sometimes change their infrastructure and require customers to update records. Sendgrid changes their sending IP ranges. Shopify deprecates a CNAME. Cloudflare rotates verification TXT records. These changes have legitimate notices, but those notices go to the account email, which may not be the agency or the account manager.

Domain hijacking and DNS attacks

More serious but less common: attackers sometimes gain access to domain registrar accounts and modify nameserver records to redirect a domain to a malicious host. This can happen via credential stuffing, phishing of the client's registrar account, or exploitation of registrar-level vulnerabilities.

DNS monitoring does not prevent this, but it provides the earliest possible detection — the record change will appear in monitoring within minutes of the attack succeeding.

The Propagation Window Problem

DNS changes propagate across resolvers over time, limited by the Time to Live (TTL) of the record being changed. A record with a 3600-second TTL can take up to an hour to propagate globally after the change is made. Records with longer TTLs (some registrars default to 86400 seconds — 24 hours) can take most of a day.

This creates a diagnostic nightmare: some users see the old record, some see the new one, and the problem appears intermittent. Support tickets are hard to reproduce. The client says "it works for me" when it genuinely does not work for their customers in another region.

Agencies that monitor DNS can immediately identify:

What the record was before the change
What it is now
When the change was detected
Whether the change was planned or unexpected

That information compresses a several-hour debugging session into a five-minute diagnosis.

What DNS Monitoring Should Alert On

Not every DNS change warrants the same response. A well-configured monitoring system distinguishes alert severity based on the type of change:

Critical alerts (immediate response required):

NS record changes — full DNS control may have moved
MX record changes — email delivery immediately affected
A record changes to unrecognised IPs — potential redirect attack

Warning alerts (investigation within the day):

CNAME record changes pointing to different platforms
TXT record additions or removals (SPF, DKIM, DMARC changes affect email deliverability)
CAA record changes restricting or expanding SSL issuance rights

Informational (review in weekly cycle):

TTL changes on existing records
CDN reshuffles within the same provider's IP range
Verification record additions for known platforms (Google, Stripe, etc.)

Monitoring DNS Across a Client Portfolio

The workflow problem for agencies is the same as with SSL: individual site monitoring is solved, portfolio monitoring is not.

The failure mode agencies fall into:

They use hosting-provider-level DNS monitoring (Cloudflare gives free DNS monitoring if DNS is on Cloudflare). But half the clients have DNS on Route53, a quarter on their registrar's nameservers, and the rest on a patchwork of providers. Each needs a different login, different alert configuration, and different notification format.

The result is either no monitoring or such inconsistent monitoring that the gaps are worse than acknowledged ignorance — at least acknowledged ignorance is honest about the risk.

A centralised DNS monitoring setup for agencies needs:

Polling frequency — ideally every 5 minutes for critical records, every 15 minutes for lower-priority zones. Real-world DNS attacks and outages propagate fast; hourly polling will miss the first hour of impact.
Baseline capture — the monitoring system needs to know what the correct records look like before a change happens, so it can classify changes as expected or anomalous.
Change history — when a client asks "what did our DNS look like six months ago?", you need a timestamped record, not a guess.
Cross-domain correlation — an NS record change affecting a whole registrar account may show as simultaneous changes across multiple client domains. The monitoring system should surface this as a related pattern, not dozens of independent alerts.

Setting Up DNS Monitoring for Your Agency

Minimum viable setup for agency DNS monitoring:

Enumerate all monitored domains per client — apex, www, mail, and any branded subdomains. Do not assume all clients use www. consistently.
Record the current state of all monitored record types — A, AAAA, CNAME, MX, TXT, NS, CAA. This becomes your baseline.
Set polling frequency at 5 minutes for NS and MX records, 15 minutes for others. Longer intervals miss fast-moving incidents.
Configure severity-appropriate alert routing — NS changes go to a senior technical contact immediately; TXT additions go to the account manager for review.
Keep a change log — every planned DNS change should be recorded with the date, the record, the old value, and the new value. This separates planned changes from unexpected alerts and builds an audit trail.

Merlonix monitors DNS records across your full client portfolio, classifies changes by severity using AI-assisted drift detection, and delivers alerts to the right person within minutes of a change. Start monitoring →

→ Complete guide: The Complete Guide to Digital Certificate Verification for Marketing Agencies → See also: Monitoring for Digital Marketing Agencies → See also: Monitoring for SEO Agencies