Anatomy of a BEC Attack: The Ghost in the MX Record

The alert landed just after lunch. High-confidence phish in the CEO’s inbox. It was a classic Business Email Compromise (BEC) attempt—an urgent, vaguely worded wire transfer request from a known vendor. The problem? Our brand-new, top-tier secure email gateway (SEG) hadn't flagged it. In fact, it hadn't even touched it.

This is the sort of incident that erodes trust. You spend six figures on a platform that promises to sanitize your mail flow, and the most critical payload sails right through to the most critical inbox. My first thought wasn't that the SEG had failed, but that the email had somehow found another way in. The laws of email physics are unforgiving. Mail has to come from somewhere.

What followed was a swift but methodical forensic deep dive that started in the email headers and ended in a dusty corner of our DNS zone file. The culprit wasn’t a zero-day or a sophisticated evasion technique. It was a ghost. A forgotten mail exchange (MX) record left over from a vendor migration three years prior.

The Contradiction in the Authentication-Results Header

When you're triaging a suspicious email, your first stop is always the `Authentication-Results` header. This is where the receiving mail server stamps its verdict on the core email authentication standards: SPF (RFC 7208), DKIM (RFC 6376), and DMARC (RFC 7489). It's the mail server's sworn testimony about the message's origins.

I expected to find a `fail` or `softfail` somewhere. Maybe a DKIM signature mismatch caused by a mailing list mangling the body hash, or an SPF failure from a poorly configured sender. Instead, I saw this:

Authentication-Results: mta.old-vendor.com; dkim=pass (signature was verified) header.d=vendor.com; spf=pass (sender IP is 198.51.100.24) smtp.mailfrom=notifications@vendor.com; dmarc=pass action=none header.from=vendor.com — Sanitized header from the incident

Clean passes across the board. SPF passed because the sender's IP was in their published record. DKIM passed because the cryptographic signature was intact and verified. DMARC passed because the `header.from` domain (`vendor.com`) aligned with the domains used for SPF and DKIM. According to the server that processed this email, the message was perfectly legitimate.

But the server that processed the email, `mta.old-vendor.com`, was not our secure email gateway. It was a name I hadn't seen in years. That was the thread. The entire investigation unraveled from that one hostname.

Tracing the Path Through a Labyrinth of `Received` Headers

The `Authentication-Results` header tells you what happened, but the chain of `Received` headers tells you where it happened. Think of them as postal stamps, applied by every server that handles the message. To trace the path, you read them from the bottom up.

The Expected vs. The Actual Mail Flow

A normal inbound email to our organization should have a clear, predictable path. The sender's mail transfer agent (MTA) connects to our SEG's public-facing MX endpoints. The SEG does its analysis—AV scans, sandboxing, URL rewriting—and then forwards the clean email to our internal Microsoft 365 Exchange Online servers. The `Received` chain should look something like: Sender MTA -> Our SEG -> Microsoft EOP -> User's Mailbox.

But this email's path was different. The bottom-most headers showed it originating from the vendor's servers, as expected. But the next hop wasn't to our shiny new SEG. Instead, the sender's MTA connected directly to that old server, `mta.old-vendor.com`. From there, it was relayed directly to our Exchange Online environment. It completely bypassed the SEG.

Why the Bypass Matters

This bypass is operationally catastrophic. All the advanced threat protection, all the URL detonation and attachment sandboxing we were paying for, was rendered useless. The attacker didn't have to craft a sophisticated payload to evade our defenses; they just had to find a different door. And the email's pristine authentication record made perfect sense in this context. The old appliance, which we thought was decommissioned, was still configured to accept mail for our domain. It ran its simple, outdated checks, saw passing SPF and DKIM, and dutifully forwarded the message on, blissfully unaware it was laundering a BEC attack.

Pivoting to DNS: The Zombie MX Record

A receiving mail server's hostname in a `Received` header is a flashing neon sign pointing directly to a DNS record. An external server can only know where to send your email by looking up your domain's Mail Exchange (MX) records. A quick `dig mx ourcompany.com` from an external resolver told the whole story.

;; ANSWER SECTION:
ourcompany.com. 3600 IN MX 10 mx1.new-seg-vendor.com.
ourcompany.com. 3600 IN MX 10 mx2.new-seg-vendor.com.
ourcompany.com. 3600 IN MX 50 mta.old-vendor.com.

There it was. Priority 10 for our primary and secondary gateway endpoints—the correct ones. And then, a priority 50 record pointing to the legacy appliance. In DNS, a lower number means higher priority. A sending MTA is supposed to try the lowest-numbered record first. If that connection fails or times out, it moves to the next highest priority, and so on.

Exploiting the Fallback Mechanism

Most MTAs are well-behaved and will stick to the primary records. But nothing requires them to. An attacker, or a misconfigured server, can choose to connect to any published MX record. By probing our domain, the attackers likely enumerated all our MX records and discovered the higher-priority (lower-numbered) ones were hardened, but the lower-priority (higher-numbered) one was a soft target. They simply instructed their sending server to connect directly to `mta.old-vendor.com`, bypassing the intended mail flow entirely.

This is a classic downgrade attack. The infrastructure was configured to be secure, but a legacy entry provided a less-secure fallback path that attackers could—and did—exploit.

Remediation and Hardening Against Downgrade Attacks

Once you've found the root cause, the immediate cleanup is straightforward. But the long-term fix requires building resilience, not just patching the hole. You have to assume attackers are constantly enumerating your external attack surface.

Step 1: Clean Up DNS

The first call was to our network team. The priority 50 MX record pointing to `mta.old-vendor.com` was deleted from our public DNS zone file immediately. Propagation can take time depending on TTLs, but this shuts the door for any new attempts. This is simple DNS hygiene, but it's amazing how often it's forgotten during complex vendor migrations.

Step 2: Harden the Perimeter with Firewall Rules

Just removing the MX record isn't enough. What if another record, like an A record for `mail.ourcompany.com`, points to an internal mail server? The definitive fix is to create firewall rules that only allow inbound SMTP traffic (TCP port 25) to your mail servers from the specific IP addresses of your secure email gateway. This makes it impossible for an external server to bypass the SEG and connect directly to your internal MTAs, regardless of what's in DNS.

Step 3: Enforce Secure Transit with MTA-STS

The strategic solution is MTA-STS (SMTP MTA Strict Transport Security), defined in RFC 8461. It's a policy you publish via DNS and a web server that tells sending mail servers *which* MX hosts are valid for your domain and that they *must* use encrypted connections. A compliant sender will fetch this policy and refuse to deliver email to any MX host not listed in the policy—like our ghost server. It effectively prevents MX downgrade attacks by turning a sender preference (use the priority 10 server) into a security requirement. Implementing MTA-STS alongside DMARC should be standard procedure for any security-conscious organization.

The takeaway

Your security is only as strong as its most forgotten component. In email, that's often a piece of legacy infrastructure—an old relay, a forgotten appliance, or a zombie DNS record—that wasn't properly decommissioned. These aren't just technical debt; they are active, exploitable liabilities on your attack surface.

This incident drove home the need for continuous, automated auditing of our external posture. Don't just trust your migration checklists. Verify. Run external scans, query your own DNS records as if you were an attacker, and check your firewall logs for anomalous connections. Tools that map your email infrastructure, like MailSleuth.AI, can help automate this discovery process, turning a painful post-mortem into a proactive security check.