It starts with a client message. Something like: "Our emails are going straight to spam. Did someone hack us?"

They sound convinced. Password changed, they say. Must have been breached. They've already started calling their IT person. One of them had already filed a police report.

But here's what I find when I actually look at the DNS: nothing was hacked. The DMARC record is just gone. Quietly. Without a trace. And the business has been haemorrhaging email deliverability for days — sometimes weeks — without knowing it.

This happens more often than it should. And it almost never involves a stolen password.


Three Scenarios. All Real. All Preventable.

Scenario A — The Invisible SPF Failure

A marketing agency connects a new CRM to their domain. The CRM requires adding an SPF include. Someone adds it. Nobody checks the total lookup count.

The SPF record now has 12 DNS lookups. The hard limit is 10. The record silently fails — not partially, but completely. Every email sent through their Mailchimp account, their helpdesk, their newsletter tool — all of it lands in spam. Overnight. Nobody touched the DMARC. Nobody touched the DKIM. The SPF broke because it was one lookup too long, and the whole authentication stack collapsed with it.

Scenario B — The MX Record That Vanished

A small e-commerce business migrates their website to a new hosting provider. The hosting provider imports DNS records automatically. Most of them transfer correctly.

The MX record doesn't. It gets overwritten with the hosting provider's default placeholder — one that points nowhere useful. For four days, every single email sent to the business owner disappears into a void. No bounce messages. No delivery failures. Complete silence. Customers believe they're being ignored. One supplier cancels a contract. The business owner has no idea anything is wrong until a client calls on the phone to ask why nobody has replied.

Scenario C — The DMARC Record That Got "Cleaned Up"

A security platform is added to a domain for monitoring. It has auto-manage DNS enabled by default. During its initial sweep, it identifies the DMARC record as a "non-standard format" — the record was valid, just slightly unconventional in structure. The platform deletes it and schedules a replacement. The replacement never arrives. The domain runs without DMARC for six weeks. During that time, someone spoofs the domain to send phishing emails to the business's own customer list. The business finds out because a customer calls to say they nearly clicked a malicious link that appeared to come from a trusted sender.


I've Seen This Pattern Too Many Times to Stay Quiet About It

These aren't hypothetical edge cases. Variations of all three scenarios have crossed my desk in the past year alone. The specifics change. The pattern doesn't.

What makes this particularly frustrating is how invisible it is. A broken SPF record produces no error message in your email platform. A missing DMARC record doesn't send you a notification. A deleted MX record doesn't trigger an alert. The system fails silently, and the business owner interprets the silence as normal — until something catastrophic makes it visible.

I work on email infrastructure every day. DNS records are the foundation everything else sits on. When that foundation shifts — even slightly, even for reasons that seem unrelated — the consequences travel fast and far. Which is why, when one of my clients forwarded me a response from their ESP provider explaining why their DMARC record had simply disappeared one day, I wasn't surprised by the cause. I was surprised they admitted it in writing.

"Since I regularly deal with exactly these situations on behalf of clients, I felt this was too important not to share publicly — because most business owners don't know this is even possible until it happens to them."

Read point two again. "They may have made changes without notifying you."

That's an ESP provider, in writing, acknowledging that a third-party service — one their customer likely trusted and paid for — can delete critical DNS infrastructure without telling the business owner. Not a hack. Not a breach. Just a service that assumed it knew better than the person whose domain it was managing.

Security incidents — actual breaches — are listed last, as the rare case. The common cases are all system-level: maintenance, migrations, auto-cleanup scripts, accidental overwrites. Normal platform activity that nobody was watching.


Your DNS Records Are Moving While You're Not Looking

Most business owners check their DNS records once — when they set them up. Then they assume the job is done. It isn't.

DNS is not a set-and-forget system. Every new integration potentially touches it. Every platform migration risks it. Every registrar backend update might affect it. And almost none of these changes come with a notification to the domain owner.

The first sign is usually a deliverability problem. Emails going to spam. Reply rates dropping for no apparent reason. A client who "never received" a proposal. A campaign that performed half as well as the previous month's. By the time the pattern is visible, the damage is already done — reputation points don't recover overnight.

How to Actually Protect Your DNS Records

  • Run a full DNS audit every 30 days — SPF, DKIM, DMARC, and MX. Takes 10 minutes with any DNS lookup tool.
  • Enable DMARC aggregate reporting (rua= tag) so you receive data when something fails authentication.
  • Use Google Postmaster Tools for your sending domain — it reports domain reputation, IP reputation, and delivery errors directly from Gmail's infrastructure.
  • Before adding any new platform or integration, check whether it touches DNS. If it does, document the record state before and after.
  • Disable auto-manage DNS on any third-party security or monitoring tool unless you fully understand what it will and won't touch.
  • If your registrar or DNS provider offers change logs or version history, enable them and review them monthly.

The businesses that handle this well aren't the ones with the most sophisticated tech stacks. They're the ones treating DNS the way they'd treat a bank account: something that requires a confirmed audit trail for every change, and an alert when something moves without authorisation.

Your emails are only as reliable as the records underneath them. Check them. Then check them again next month.