Skip to content

DNS incidents

A DNS Change Broke a Client's Email — and Nobody Noticed for Days

The website was up the whole time. That's what made it so bad. A single MX record changed during an unrelated migration, and the client's inbound email started bouncing — silently, for days, while every uptime check stayed green. DNS is the one layer where a one-character edit can take down email, APIs, and subdomains without touching the homepage. Here's how these changes break things quietly, how to confirm the cause, and how to get alerted the moment a record drifts.

  • How MX/CNAME changes silently break email & services
  • How to confirm a DNS change is the cause
  • How to get alerted when a record drifts
Monitor your DNS records Check your site now

The failure

Why a DNS change is the quietest outage there is

DNS is the layer almost nobody watches, because most monitoring is pointed at the website — the A record, the homepage, the HTTP status. But a domain's DNS zone holds far more than that: MX records route email, CNAME records point subdomains and third-party services, TXT records carry SPF/DKIM that decide whether your mail is trusted, and NS records control the whole zone.

Change any of those and the website never flinches. The homepage keeps returning 200 OK. The padlock stays green. And yet:

  • A changed or deleted MX record means inbound email stops arriving — and senders may get bounces, or worse, nothing at all.
  • A removed CNAME breaks a subdomain: app., mail., status., or a third-party service that pointed at it.
  • An edited TXT/SPF record means your outbound email starts landing in spam — technically delivered, functionally invisible.

Why it's an "up but broken" problem: the thing everyone monitors (the site) is fine, and the thing that actually broke (email, a subdomain, an API endpoint) isn't being checked at all. This is the same blind spot website monitoring closes for the front end — extended to the DNS zone underneath it.

20

Detection rules

5–30 min

Check intervals

Free

1 site

The usual suspects

How DNS changes break things without warning

Nameserver migration drops records

Critical

Moving DNS to a new provider (or a new host's "we'll manage your DNS" offer) imports the A record but misses the MX, TXT, and CNAME records. The website moves cleanly; email and subdomains silently break.

Email provider switch, half-finished

Critical

Migrating from one mail provider to another means updating MX, SPF, DKIM, and DMARC. Miss one MX line or leave a stale SPF entry and mail bounces or gets flagged as spam.

A typo in a single record

Critical

One wrong character in an MX hostname or a CNAME target, and the record resolves to nothing. DNS doesn't validate that the target actually works — it just serves what you typed.

A "cleanup" that deleted a live record

Moderate

Someone tidies the zone and removes a CNAME they assumed was unused — the one pointing a client's booking subdomain at a SaaS tool. It was very much in use.

TTL and propagation masking the change

Moderate

Long TTLs mean a bad change can look fine for hours (cached) and then break everywhere at once when caches expire — long after the person who made the change has logged off.

Registrar auto-changes

Low

A registrar "parks" a domain, resets nameservers on renewal, or applies a default zone after a billing hiccup — wiping custom records you set up months ago.

Diagnosis

How to confirm a DNS change is the cause

1. Query the records directly

Don't trust the registrar dashboard — query what the world actually sees. For email: dig MX yoursite.com +short. For a subdomain: dig CNAME app.yoursite.com +short. For mail trust: dig TXT yoursite.com +short and look at the SPF line. Compare what you get against what should be there.

2. Check from multiple resolvers

Run the same query against Google (dig @8.8.8.8 MX yoursite.com) and Cloudflare (dig @1.1.1.1 MX yoursite.com). If they disagree, you're mid-propagation — a recent change hasn't fully rolled out yet.

3. Confirm the symptom matches the record

Email bouncing → look at MX and SPF/TXT. A dead subdomain → look at its CNAME/A record. Outbound mail going to spam → look at SPF, DKIM, DMARC TXT records. The record type tells you exactly which service the change took down.

4. Find out when it changed

This is the expensive part. DNS changes rarely come with a changelog, and the symptom (bounced email, a quiet subdomain) often goes unreported for days. The fix is usually a one-line edit; the damage is everything that silently failed in between. That gap is why DNS belongs in continuous monitoring — see DNS monitoring — rather than something you only check when a client complains.

Start monitoring today

Free plan. No credit card.

Get started free

Recovery

How to fix it and stop it recurring

1

Restore the correct record

Re-add the missing MX/CNAME/TXT record with the exact correct target. If you have an export of the old zone file, use it as the source of truth rather than rebuilding from memory.

2

Account for TTL

The fix propagates on the record's TTL. If TTLs are long, the broken value may still be cached for some users. During migrations, lower TTLs in advance so changes (and rollbacks) take effect fast.

3

Verify the affected service, not just DNS

Send a test email end-to-end. Load the subdomain. Confirm the actual service recovered — DNS resolving correctly and email actually flowing are two different checks.

4

Add record-level monitoring

Snapshot the full zone — MX, CNAME, TXT, A, NS — and alert on any drift. The next time a record changes, you find out the same day, not when a client asks why they stopped getting emails.

Never again

How to catch DNS drift before clients do

Record-level change detection

Sitewatch tracks your MX, CNAME, TXT, A, and NS records and alerts on any change with a before/after diff — so a silent edit becomes an immediate, actionable signal.

Pairs with SSL & domain expiry

DNS, certificates, and domain registration are the three "invisible infrastructure" failures that take a site or service down without an error. Sitewatch watches all three on every plan — see SSL certificate monitoring and domain expiry monitoring.

Built for agencies and freelancers

Watching DNS across a portfolio of client domains means you catch the broken MX record before the client emails you — which is the difference between looking proactive and looking asleep.

Alerts on the channels you check

Slack, email, or webhook — with the record name and the exact change, so you know whether it's email, a subdomain, or the whole zone that just moved.

Common questions

Know the moment a DNS record changes

Free plan available. Continuous DNS, SSL, and domain monitoring — so a silent record change can't take down client email.

Start free monitoring