MX Records Don't Lie: Fingerprinting an Email Security Stack

Pop open a terminal and run `dig mx a-big-company.com`. What you get back isn't just a list of server hostnames; it's a public declaration of trust and architecture. That raw text tells a story about who handles their email, how resilient their setup is, and what kind of security gateway stands guard at the perimeter.

Most IT and security pros see an MX record and think 'mail routing'. That's not wrong, but it's incomplete. For an analyst, threat hunter, or red teamer, that record is the first thread to pull. It’s open-source intelligence of the highest order, freely given, and almost always accurate. You just have to know the patterns.

Let's break down the distinct fingerprints left by the biggest players in email: Google, Microsoft, and the third-party Secure Email Gateways (SEGs) like Proofpoint and Mimecast. By the end, you'll never see an MX record as just a technical necessity again.

An MX Record is a Public Confession

Before we get into vendor specifics, let's reset on what we're looking at. A Mail Exchanger (MX) record is a type of resource record in DNS that specifies the mail servers responsible for accepting email messages on behalf of a domain name. Simple enough.

The key is that MX records have two crucial parts: a priority (a number) and a hostname (the server). The lower the number, the higher the priority. A mail transfer agent (MTA) trying to deliver a message to `somecorp.com` will try the server with the lowest priority number first. If that server is unavailable, it moves to the next lowest, and so on.

somecorp.com. 3600 IN MX 10 mail1.somecorp.com.
somecorp.com. 3600 IN MX 20 mail2.somecorp.com.

This priority system is the basis for failover and load balancing. But for our purposes, the *pattern* of priorities and, more importantly, the *structure* of the hostnames, is where the intelligence lies. A single, high-priority record tells a different story than a set of five records with identical hostnames but varying priorities.

The Google Workspace Tell: Redundancy is the Signal

If a company uses Google Workspace (formerly G Suite) for their email, their MX records have an unmistakable signature. You won't see one record; you'll see five.

The primary record is almost always `ASPMX.L.GOOGLE.COM` with a priority of 1. This is followed by four other records, typically pairs of `ALT1.ASPMX.L.GOOGLE.COM` and `ALT2.ASPMX.L.GOOGLE.COM` with priority 5, and `ALT3` and `ALT4` with priority 10. This isn't an accident; it's a deliberate architectural choice broadcast to the world.

What does this tell you? It screams 'massive, horizontally-scaled cloud infrastructure.' Google isn't giving you the IP of a specific server cluster. They're giving you a set of anycast entry points into their global network. The multiple records ensure that even if one entry point has issues, or an entire sending MTA has a bizarre routing preference, the mail gets in. When you see this pattern, you can be highly confident that the organization's mailboxes live on Google's servers.

The Microsoft 365 Fingerprint: '<tenant>.mail.protection.outlook.com'

Microsoft's pattern is just as unique, but in a completely different way. Where Google uses a generic, redundant array, Microsoft 365 uses a single, highly specific MX record tailored to the customer tenant.

Decoding the Microsoft 365 MX Record Format

The format is always the same: `<tenant-name>.mail.protection.outlook.com`. The domain's own name, with dots replaced by hyphens, becomes the subdomain. For a company with the domain `bigcorp.com`, their tenant name is `bigcorp-com`, and their MX record points to `bigcorp-com.mail.protection.outlook.com`.

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

This record will almost always have a priority of 0, indicating it's the only one that should be used. Unlike the Google model, there are no backup records. This is because, like Google, `protection.outlook.com` is a massive, anycast-fronted service. The reliability is handled behind that single hostname, not exposed in DNS. Seeing this format is a definitive sign that the company uses Microsoft 365 for its mailboxes and, at a minimum, its default Exchange Online Protection (EOP) for initial filtering.

The Secure Email Gateway Intercept

This is where reconnaissance gets interesting. When an organization puts a third-party Secure Email Gateway (SEG) in front of their cloud mailboxes, the MX records stop pointing to Google or Microsoft. They point to the SEG. The SEG's job is to receive all mail first, perform advanced analysis—sandboxing, URL rewriting, impersonation detection—and then, if the mail is clean, forward it to the real destination inbox.

Proofpoint's Proxy Pattern

Proofpoint often uses a pattern that wraps the final destination's MX record within its own. For that same `bigcorp.com` using M365, their MX record might change from the Microsoft default to something like `bigcorp-com.mail.protection.outlook.com.ppe-hosted.com`. See what happened? The original M365 address is now a subdomain of a Proofpoint address. This tells you two things instantly: they use Proofpoint, and their mailboxes are on Microsoft 365. The SEG is acting as a proxy, and the MX record transparently shows the next hop.

Mimecast's Regional Gateway Model

Mimecast's pattern is different. It typically doesn't wrap the destination hostname. Instead, a company's MX records will point to a set of regional Mimecast datacenters. For a US-based company, you'll likely see something like `us-smtp-inbound-1.mimecast.com` and `us-smtp-inbound-2.mimecast.com` with different priorities.

This pattern confirms Mimecast is the SEG, but unlike the Proofpoint example, it doesn't explicitly reveal the final mailbox provider in the DNS record itself. You know mail goes to Mimecast first, but you have to infer where it goes next. However, given market share, if you see a Mimecast MX record, there's a very high probability the mailboxes themselves live in either Microsoft 365 or Google Workspace.

From Recon to Risk Assessment

So why does any of this matter? Because knowing the mail stack is a critical piece of intelligence for multiple operational disciplines.

Red Team and Attacker Recon

If I'm planning a phishing campaign against `bigcorp.com` and their MX record is `bigcorp-com.mail.protection.outlook.com`, I know exactly what login page to spoof. My pretext can be about session timeouts or mailbox migrations, and I can link to a perfect replica of the Microsoft 365 login portal. I also know that I have to get past Exchange Online Protection. If, however, I see a Mimecast or Proofpoint MX record, my job is harder. I have to craft a payload that can bypass a more advanced SEG. Maybe I'll try a QR code phish or a link to a file on a trusted sharing site to evade their URL analysis.

M&A Due Diligence and Supply Chain Risk

During a merger or acquisition, a quick `dig mx` on the target company provides instant insight into their IT maturity. Are they on a modern cloud platform? Great. Do their MX records still point to `mail.old-server.local`? That's a red flag. It suggests legacy infrastructure, potential security gaps, and a costly migration project in the future.

The same applies to vendor risk management. If a critical supplier's MX records point to an unpatched, on-premise Exchange server from 2013, their risk of a breach that could impact you is significantly higher than a supplier using M365 with a SEG in front. It's a simple, non-intrusive check on your supply chain's cyber hygiene.

The takeaway

An MX record is the public-facing entry point to an organization's most critical communication tool. Its structure is a direct result of architectural decisions made by their security and IT teams. By learning to read these patterns, you can gain immediate, actionable intelligence without sending a single packet to their network. The hostname and priority aren't just for MTAs; they're a fingerprint.

But remember, this is only the front door. DNS tells you where the email *should* go. Once it arrives, email authentication headers like `Authentication-Results` (RFC 8601) and the `Received` chain tell the true story of the path it took and how each hop judged its legitimacy. Analyzing these headers is the next step, turning external recon into ground-truth incident data, which is precisely what platforms like MailSleuth.AI are built to automate.