The SEG Bypass Playbook: Hardening M365 MX Records

You just spent six figures and a full quarter deploying a new Secure Email Gateway. The dashboards are green, mail is flowing, and leadership is happy. Then a high-quality credential phish lands in your CFO's inbox. You pull the headers and your stomach drops. The message never touched the SEG. It was delivered directly to Microsoft 365, bypassing every advanced filter you just paid for. How?

The culprit is almost always a forgotten Mail Exchanger (MX) record. In the rush to go live, administrators often leave a 'backup' MX record pointing to their old mail environment. They see it as a fail-safe. Attackers see it as a wide-open back door.

This isn't a theoretical attack. It's an active technique used to bypass expensive security controls. Your SEG is only effective if it's the *only* path for inbound mail. This playbook details the precise steps to configure your MX records for a service like Proofpoint over Microsoft 365 and, more importantly, how to slam the back door shut for good.

Your SEG Must Be the Only Door

An MX record is a public DNS resource that tells the world where to send email for your domain. When a remote server wants to send you a message, it performs a DNS lookup for MX records associated with your domain. What many admins forget is that the sending server can try *any* of the hosts listed, not just the one with the lowest priority number.

The priority field is a preference, not a rule. A well-behaved Mail Transfer Agent (MTA) will try the lowest-numbered MX record first. If that connection fails, it will proceed to the next highest number. But an attacker isn't running a well-behaved MTA. They can write a simple script to query all your MX records and intentionally connect to the one that points directly to Microsoft 365's Exchange Online Protection (EOP).

The entire value proposition of a cloud SEG—be it Proofpoint, Mimecast, or another provider—is that it sits *in front* of your mail server, acting as a sophisticated filter. It cleans the mail before passing it to the final destination. If an attacker can simply choose to ignore the SEG and knock on Microsoft's door directly, your investment is nullified for that message. This isn't just about spam; it's about targeted Business Email Compromise (BEC), malware delivery, and phishing campaigns that rely on bypassing advanced inspection.

Pre-Cutover Audit: Finding Your M365 Footprint

Before you can fix the problem, you need to map it out. You cannot secure what you don't know exists. This means auditing your domain's public DNS records to find every mail-related entry.

Locating Your M365 MX Record

Your Microsoft 365 MX record typically follows a standard format: `yourdomain-com.mail.protection.outlook.com`. The `yourdomain-com` part is your domain with the periods replaced by hyphens. You can find this easily with a command-line tool like `dig` or `nslookup`.

dig yourdomain.com MX

; <<>> DiG 9.18.1-1ubuntu1.1-Ubuntu <<>> yourdomain.com MX
;; ANSWER SECTION:
yourdomain.com. 3600 IN MX 0 yourdomain-com.mail.protection.outlook.com.

Document this value. This is the record you will eventually need to remove. If you have other MX records pointing to on-premises servers or old services, document those as well. All non-SEG MX records must go.

Documenting Current TTLs

In the `dig` output above, notice the `3600`. That's the Time To Live (TTL) in seconds. It tells DNS resolvers around the world how long they should cache this record before asking for it again. A TTL of 3600 means resolvers will hold onto that record for one hour. If you make a change, it could take up to an hour for the change to be fully respected across the internet. For a mail routing cutover, an hour is an eternity where mail could be delayed or misrouted. You need to reduce this *before* you make the final switch.

The Cutover: A Staged, Low-TTL Migration

A successful cutover is a non-event. The key is staging the changes and respecting DNS propagation. Don't just rip and replace records in one go.

Step 1: Lower All MX Record TTLs

At least 24 hours before your planned cutover, change the TTL on your existing Microsoft 365 MX record to something very low, like 300 (5 minutes) or 60 (1 minute). This gives the internet's DNS caches a full day to expire their old, long-TTL copies and pick up the new, short-TTL version. When you do the final cutover, the change will propagate in minutes, not hours.

Step 2: Add SEG MX Records and Flip Priorities

On cutover day, you'll perform two actions. First, add the new Proofpoint MX records (e.g., `mx1-us1.ppe-hosted.com`) with the lowest priority number, typically 10. Second, change the priority of your existing Microsoft 365 MX record to a very high number, like 1000. Do not delete it yet.

Now, your DNS instructs all compliant MTAs to send mail to Proofpoint. The M365 record exists only as a high-priority, non-preferred route. Let this configuration sit for a few hours and monitor mail flow through your new SEG. Once you've confirmed mail is routing correctly, you can proceed to the final step: deleting the M365 MX record entirely. There is no valid security reason to leave it in place.

The Fallacy of the 'Backup' M365 MX Record

This is the single most common and dangerous misconfiguration we see. An admin, wanting to be cautious, leaves the Microsoft 365 MX record in place with a high priority number (e.g., 50), thinking, 'If my SEG goes down, mail can still be delivered directly.' This logic is flawed and fundamentally misunderstands the threat model.

Your SEG provider already builds in redundancy. They provide multiple MX records of their own (e.g., mx1-us1, mx2-us1) across geographically diverse data centers. Their entire business model relies on high availability. In the extraordinarily rare event of a total SEG outage, mail delivery from well-behaved senders would be deferred and retried later. It wouldn't be lost.

However, by leaving that 'backup' record, you are providing a public, authenticated route directly to your mailboxes that bypasses all security filtering. An attacker doesn't need the SEG to be down. They will simply query your MX records, see the `yourdomain-com.mail.protection.outlook.com` entry, and connect to it directly. Your 'backup' route has become their primary attack vector.

Locking the Back Door: The Inbound Connector Rule

Cleaning up public MX records is the first, essential step. The second, definitive step is to configure Microsoft 365 to reject any mail that doesn't come from your SEG. This makes your infrastructure actively hostile to bypass attempts.

Building the Trusted IP Wall

In the Exchange Admin Center, you need to create an inbound connector. This connector's purpose is to identify mail coming from a trusted source—your SEG. You will configure it to only accept mail from the specific IP ranges provided by your SEG vendor (Proofpoint publishes these publicly). You can set it to be partner-based or IP-based.

Next, you create a mail flow rule. This rule is simple but powerful: 'If the message is received from 'Outside the organization' AND the sender's IP address is NOT in the range of my SEG's IPs, THEN reject the message and do not deliver it.' This rule effectively makes your inbound connector the *only* allowed path for external mail. Even if an attacker uses your old MX record to connect directly to EOP, this rule will see the connection did not originate from a Proofpoint IP and will drop it before it ever reaches a user's inbox.

Post-Change Validation

Now, validate everything. Send a test email from an external account (like a personal Gmail). Open the delivered message in Outlook and view the original message headers. You should see `Received:` headers showing the message passing through your SEG's servers before hitting Microsoft's servers.

Received: from mx1-us1.ppe-hosted.com (148.163.129.1) by DB5PR04CA0340.outlook.office365.com (2603:10b6:408:98::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) ... — Example Received Header

This header proves the path was correct. Conversely, try to telnet to your `yourdomain-com.mail.protection.outlook.com` host on port 25 from an external machine. The mail flow rule you created should cause the connection to be rejected once you issue the `MAIL FROM` command, confirming your hardening is active.

The takeaway

Leaving a 'backup' MX record pointing to Microsoft 365 is not a safety net; it's a hole in your perimeter. Attackers are not bound by your preferred mail routes. They will enumerate every public entry point and exploit the weakest one. The only secure configuration is one where your SEG's MX records are the *only* MX records for your domain, and your mail server is configured to reject any traffic that doesn't come from that SEG.

This is a fixable problem, but it requires diligence. Once you've implemented these changes, don't just set it and forget it. Regularly audit your inbound mail paths and inspect headers on suspicious messages. Using a tool like MailSleuth.AI to parse and visualize these headers can quickly surface anomalies that might indicate a new, unmitigated bypass route. The question isn't if an attacker can find your backup MX record. It's whether you've made it impossible for them to use it.