When a credit union's domain gets hijacked, everyone stares at the website. Is there a fake login page? Are members being phished? Those are the right questions, but in the incident we worked this summer, the attacker's quietest move was aimed somewhere else entirely: at the mail.
Among the DNS records the attacker published was a new MX record, the record that tells the internet where to deliver a domain's email, pointed at a server they controlled. From that moment, every message sent to any address at the institution's domain was theirs to read: password reset links, multi-factor codes delivered by email, vendor invoices, wire instructions, notices from the online-banking platform, replies from members.
How we knew it was built to intercept
Here is the forensic detail worth internalizing. The attacker's mail setup had no SPF record, no DKIM keys, no DMARC policy. If you intend to send mail that lands in inboxes, you need those records; without them, modern providers junk or reject you. The attacker didn't bother, because sending was never the plan. The mail server was configured for one purpose: to receive. An interception post, not a spam cannon.
That posture matters for defenders because it inverts the usual mental model. Security teams think of email attacks as things that arrive: phishing, spoofing, malware. A domain-layer attacker doesn't need to send anything. They redirect the river. Every credential reset for every SaaS account registered under the domain becomes theirs to trigger and complete. Think through what that means for your vendor portals, your payroll provider, your social accounts, and any admin account anywhere whose recovery path is an email address at your domain.
The three signals that catch it
Watch your MX records from outside. For most institutions, MX records change perhaps once in five years, during a mail migration. That makes them a perfect tripwire: an external monitor that resolves your MX every few minutes and alerts on any change will essentially never false-alarm, and when it fires, it is a five-alarm fire. This is scriptable in an afternoon or available off the shelf.
Watch your DMARC reports for silence. If you have DMARC reporting enabled, receivers around the world send you daily aggregate reports about mail claiming to be from your domain. Those reports arrive by email. If your mail flow is redirected, the reports stop arriving. Silence in a normally chatty feed is itself a signal, if someone is looking.
Notice authentication failures out of nowhere. If your legitimate outbound suddenly starts failing SPF alignment or your MTA-STS policy fetches start erroring, treat it as a DNS-layer event until proven otherwise, not a deliverability gremlin to ticket for next week.
Hardening before the fact
Get your legitimate mail authentication to full strength now, while it is boring: DMARC at p=reject (not the p=none monitoring mode that two-thirds of institutions never graduate from), SPF and DKIM aligned, and MTA-STS published so receiving domains expect encrypted delivery to your declared mail hosts. None of these stop a full DNS takeover by themselves, but they shrink the attacker's options, create the reporting feeds whose silence betrays them, and are exactly the artifacts an examiner reads as program maturity.
Then close the loop operationally. Put "mail may be intercepted" in your incident playbook as an explicit branch: it changes your 72-hour reportability analysis, it means password resets and MFA codes for the duration of the incident are suspect, and it means wire-instruction verification falls back to voice callbacks on known-good numbers, a control your BSA team will recognize. During our incident, the institution kept functioning because its actual mailbox hosting lived with a provider unaffected by the DNS layer, and recovery re-pointed the records. The lesson stands regardless: whoever writes your DNS owns your inbox. Watch the record that proves it.
