Your Client Called. Their Email Stopped Working. You Had No Idea Why.

DNS: the phone book no one watches

DNS — the Domain Name System — is the infrastructure that translates domain names into IP addresses and routes email, validates domain ownership, and controls where subdomains point. Every website, every email system, and every SaaS integration that uses a custom domain depends on DNS working correctly.

Yet for most agencies, DNS is "set and forget" infrastructure. Records are configured when a project launches, and then largely ignored. This creates a significant blind spot: illegitimate or accidental changes to DNS records can have severe consequences that take hours or days to discover.

The most dangerous DNS changes

MX record changes — email hijacking

MX records control where email for a domain is delivered. If an attacker gains access to a DNS provider account and changes the MX record, all inbound email is silently redirected to their server. Outbound email continues to work normally, making the attack invisible to the victim for days. This is a primary vector for business email compromise (BEC) attacks.

A record changes — website takeover

Changing the A record for a domain — or its www CNAME — redirects all web traffic to a different IP. This can be used to serve phishing pages under a legitimate domain, or can happen accidentally during a botched migration when old records aren't cleaned up.

NS record changes — full domain hijack

Nameserver (NS) record changes are the most severe. Changing the NS records effectively hands over control of the entire DNS zone to whoever controls the new nameservers. An attacker with NS record access can create any records they like, including valid SSL certificates via DNS-01 ACME challenges.

TXT record changes — SPF/DMARC breakdown

SPF and DMARC policies are stored as TXT records. An attacker who removes or weakens these protections can send email that appears to come from your client's domain. Legitimate email also starts landing in spam folders, often days after the change, making diagnosis difficult.

How DNS attacks happen in practice

DNS changes in the wild follow several patterns:

• Credential compromise — phishing or password reuse targeting DNS provider login credentials
• Domain registrar attacks — targeting registrar accounts that control both registration and DNS
• Accidental changes by developers — the most common cause; migration scripts, provider changes, or typos
• Expired subdomain hijacking — CNAME records pointing to services the client no longer uses, enabling a third party to claim the subdomain
• Supply chain changes — a SaaS tool the client uses changes their infrastructure and the client's DNS is outdated

Why detection matters more than prevention

DNS access credentials will eventually be compromised — it's a question of when, not if. The difference between a minor incident and a major breach is detection speed. An attacker who controls DNS for 4 hours can cause very different damage than one who controls it for 4 days.

Monitoring introduces a hard upper bound on how long changes can go undetected. If you run hourly checks, attackers have at most an hour of undetected access — even if login alerts are bypassed or delayed.

What a monitoring workflow looks like

With Aideworks, the workflow is straightforward:

• Add a domain — we take a DNS snapshot of all records
• On each check, we compare current DNS against the snapshot
• If anything changes, you get an alert with a before/after diff
• You review the diff, confirm whether it was intentional, and update the baseline if so

The before/after diff is the critical piece. It tells you exactly what record changed, from what value to what value, and when. That's the information you need to diagnose and respond quickly.

Practical recommendations for agency DNS monitoring

• Monitor every client domain — not just the "important" ones. Attackers target the path of least resistance.
• Pay extra attention to MX and TXT records — email infrastructure is the highest-value target.
• Set up alerts for NS record changes — these are rare in normal operation, so any NS change should trigger immediate investigation.
• Review subdomain CNAME records periodically — any CNAME pointing to a third-party service that no longer exists is a dangling subdomain takeover risk.
• Document intentional changes — when you make a DNS change for a client, update the baseline in your monitoring tool so the alert doesn't create noise.