Detect a company’s email provider from DNS

One dig query and you usually have it. MX records are public, they change rarely, and every large mail platform hands its customers a hostname you can recognise on sight. The complication is that plenty of business domains put a security gateway in front of the mailbox, and the gateway answers the MX query. When that happens the MX tells you who filters the mail, not who stores it — and you need a second lookup.

What does an MX record actually tell you?

RFC 5321 Section 5.1 describes how a sending SMTP client finds where to deliver: it queries the destination domain for MX records and tries the resulting hosts in order of preference value, lowest number first. If the domain has no MX records at all, the client falls back to the domain’s A or AAAA record — the "implicit MX" — and delivers there.

So an MX record is a statement about inbound delivery and nothing else. It is the address a stranger’s mail server is told to knock on. It says nothing directly about where the domain sends mail from, what the users’ mail client connects to, or who owns the mailbox storage. Those often coincide. Increasingly they do not.

One special case is worth recognising because it saves you an email. RFC 7505 defines a "null MX": a single MX record with preference 0 and a zero-length label — written as a bare dot in a zone file. It exists to make delivery attempts fail immediately. example.com publishes one.

$ dig +short MX example.com
0 .

What do the common MX signatures look like?

Each platform publishes a documented hostname its customers must set. That is what makes this readable at a glance. The table below gives the pattern each vendor documents, plus a real domain currently using it — verified with dig while writing this, which is the only kind of example worth printing.

Two honest caveats about that table. First, Microsoft documents the MX target only as <MX token>.mail.protection.outlook.com and tells admins to read the real token out of the admin centre. The token is often the domain with its dots turned into hyphens — github.com gives github-com — but that is an observation rather than a documented guarantee, and it does break: bt.com answers with btgroupcloud-mail-onmicrosoft-com.mail.protection.outlook.com. Second, we could not find a public Proofpoint or Mimecast page that states these hostname patterns; Proofpoint’s support site redirects an anonymous request to a login page, and Mimecast’s documentation host did not resolve for us at all. So those two rows are what the hostnames resolve to today, not what a vendor document says. Every other row traces to the vendor doc linked at the foot of this page.

A vendor’s own domain is also not always a good template. Zoho tells customers to publish mx.zoho.com, mx2.zoho.com and mx3.zoho.com; zoho.com itself answers with smtpin.zoho.com. Match on the registrable domain, not on an exact hostname.

Why does the MX often name a gateway instead of the mailbox?

Because that is how a pre-delivery email security product is deployed. You point your MX at the vendor, the vendor scans everything, and the vendor relays what survives to your real mail platform over a connector. Barracuda’s documentation is explicit that you "modify all your MX records to point to Barracuda Networks mail servers". Cloudflare’s Email Security setup guide for Microsoft 365 shows the same shape: sender → Cloudflare MX → Exchange Online.

The consequence for anyone reading DNS is direct. A Mimecast MX means Mimecast. It does not mean Exchange, or Google, or an on-premises Postfix — all three sit behind Mimecast at different companies. If your classifier stops at the MX, every gateway customer lands in an "unknown" bucket — two of the five domains sampled later in this article among them.

How do you find the mailbox host behind a gateway?

Three more lookups, in rough order of how much they prove. None of them is conclusive on its own; together they usually settle it.

The autodiscover CNAME is the strongest of the three because it exists for a client-side purpose that only a real Exchange Online tenant has. Microsoft’s DNS reference lists it as one of the three primary records every Microsoft 365 email customer sets: alias autodiscover, target autodiscover.outlook.com. Google has nothing equivalent, so its absence is not evidence of anything by itself.

SPF and DKIM are weaker on purpose. An include: mechanism in SPF authorises a platform to send as the domain. A resolving DKIM selector means that platform holds a key that can sign for the domain. Neither says the platform holds the mailboxes. basecamp.com runs its own MX at mx1.basecamp.com and still publishes a google._domainkey TXT record — Google signs some of its mail without hosting it.

Microsoft 365’s DKIM records are CNAMEs at the fixed hostnames selector1._domainkey and selector2._domainkey. The target has two documented shapes: the older selector1-<domain-with-dashes>._domainkey.<tenant>.onmicrosoft.com, and a newer form ending in <tenant>.<partition>-v1.dkim.mail.microsoft, which Microsoft introduced for new custom domains in May 2025 while existing domains keep the old shape. Either target confirms a Microsoft 365 tenant, and both carry the tenant’s initial onmicrosoft.com prefix — github.com’s selector1 points at microsoft.onmicrosoft.com.

$ dig +short MX github.com
0 github-com.mail.protection.outlook.com.

$ dig +short CNAME autodiscover.github.com
autodiscover.outlook.com.

$ dig +short selector1._domainkey.github.com
selector1-github-com._domainkey.microsoft.onmicrosoft.com.

A shell function that classifies a domain

This is the whole thing. It reads the MX, matches a signature, and — only when it hits a gateway or an unrecognised host — runs the fall-through checks. It needs dig plus the usual command-line text tools — sort, awk, paste, tr and grep — and it runs identically in bash and zsh.

# mxwho <domain> — guess a domain's mail platform from DNS alone.
mxwho() {
  local d=$1 mx spf

  mx=$(dig +short MX "$d" | sort -n | awk '{print tolower($2)}' | paste -sd' ' -)
  spf=$(dig +short TXT "$d" | tr -d '"' | grep -m1 '^v=spf1')

  echo "domain:  $d"
  echo "mx:      ${mx:-(none)}"

  case $mx in
    *mail.protection.outlook.com*)          echo 'verdict: Microsoft 365'; return;;
    *aspmx.l.google.com*|*smtp.google.com*) echo 'verdict: Google Workspace'; return;;
    *zoho*)                                 echo 'verdict: Zoho Mail'; return;;
    *messagingengine.com*)                  echo 'verdict: Fastmail'; return;;
    *pphosted.com*|*ppe-hosted.com*)        echo 'verdict: gateway - Proofpoint';;
    *mimecast*)                             echo 'verdict: gateway - Mimecast';;
    *barracudanetworks.com*)                echo 'verdict: gateway - Barracuda';;
    *cf-emailsecurity.net*)                 echo 'verdict: gateway - Cloudflare';;
    '.')                                    echo 'verdict: null MX (RFC 7505) - accepts no mail'; return;;
    '')                                     echo 'verdict: no MX - implicit MX on the A record, or no mail'; return;;
    *)                                      echo 'verdict: unrecognised - self-hosted or niche';;
  esac

  # A gateway answered. It says nothing about the mailbox behind it.
  echo '--- fall-through checks ---'
  case $(dig +short CNAME "autodiscover.$d") in
    *autodiscover.outlook.com*) echo 'autodiscover: Microsoft 365';;
  esac
  case $spf in *spf.protection.outlook.com*) echo 'spf:          Microsoft 365';; esac
  case $spf in *_spf.google.com*)            echo 'spf:          Google Workspace';; esac
  [ -n "$(dig +short selector1._domainkey."$d")" ]  && echo 'dkim:         Microsoft 365 (selector1)'
  [ -n "$(dig +short TXT google._domainkey."$d")" ] && echo 'dkim:         Google Workspace (google)'
  [ -n "$(dig +short CNAME fm1._domainkey."$d")" ]  && echo 'dkim:         Fastmail (fm1)'
  return 0   # the && chain above would otherwise leave a false non-zero status
}

Run against five real domains, this is the actual output. Note the last two: barracuda.com sits behind its own product with Microsoft 365 underneath, and atlassian.com sits behind Proofpoint with Google Workspace underneath. Neither is visible from the MX alone.

$ for d in github.com hubspot.com atlassian.com barracuda.com example.com; do mxwho $d; echo; done

domain:  github.com
mx:      github-com.mail.protection.outlook.com.
verdict: Microsoft 365

domain:  hubspot.com
mx:      smtp.google.com.
verdict: Google Workspace

domain:  atlassian.com
mx:      mxa-001d9801.gslb.pphosted.com. mxb-001d9801.gslb.pphosted.com.
verdict: gateway - Proofpoint
--- fall-through checks ---
spf:          Google Workspace
dkim:         Google Workspace (google)

domain:  barracuda.com
mx:      d160221a.ess.barracudanetworks.com. d160221b.ess.barracudanetworks.com.
verdict: gateway - Barracuda
--- fall-through checks ---
autodiscover: Microsoft 365
dkim:         Microsoft 365 (selector1)

domain:  example.com
mx:      .
verdict: null MX (RFC 7505) - accepts no mail

Why would you want to know before you contact a company?

Two reasons, and they pull in opposite directions.

The first is what happens to mail you send them. A gateway in front of a mailbox changes the receiving behaviour you should expect. It terminates the SMTP connection itself and applies its own policy before deciding what to relay onward. Some of these products also analyse or rewrite the URLs in a message, though exactly what they do varies by vendor and by configuration. If you are debugging why a message to one domain bounced and an identical message to another arrived, the MX is the first place to look, because a pphosted.com or mimecast.com answer means the rejection text you are reading was written by the gateway vendor, not by Exchange or Gmail.

The second is whether a mailbox integration is even possible. Any product that sends through a customer’s own mailbox rather than through a shared relay is bound by what that mailbox’s API allows. Microsoft Graph’s POST /me/sendMail needs the delegated Mail.Send permission and returns 202 Accepted; Gmail has its own send scope. If a prospect’s domain resolves to Zoho, Fastmail or a self-hosted Postfix, a product built only on Graph and the Gmail API cannot connect to it at all — which is a fact worth establishing before a sales conversation, not during one. Decknative connects Microsoft 365 and Gmail mailboxes over OAuth for exactly this reason, and everything else is a "not supported" answer we would rather give up front.

Where does this go wrong?

It is inference, not ground truth, and it fails in recognisable ways. Split-domain and hybrid deployments route some users to a cloud tenant and others to on-premises Exchange, and the MX shows you one path. Large organisations run different platforms per subsidiary while sharing a parent domain. Some companies publish MX records for a domain they never actually receive on. A gateway can front another gateway. And nothing in DNS distinguishes a Microsoft 365 tenant that has Exchange Online licences from one that has only Entra ID.

The other limit is freshness. These records change — the whole point of an MX cutover is that it is a DNS edit — so a classification cached six months ago is a guess about the past. Respect the TTL, re-resolve before you act on the answer, and use a resolver you control rather than a third-party lookup API if the volume is anything but trivial.

Finally: everything here reads records the domain owner published to the public DNS for the express purpose of being read by strangers’ mail servers. That is not a comment on what you may lawfully do with the result. Rules on contacting the people at those domains — the UK and EU GDPR, the UK’s PECR, CAN-SPAM in the US, CASL in Canada — apply regardless of how you discovered the provider, and this article is not legal advice.