How to find out which email provider a company uses

To find out which email provider a company uses, look up the MX records of its email domain. The hostnames name the provider: smtp.google.com or aspmx.l.google.com means Google Workspace, a host ending in mail.protection.outlook.com means Microsoft 365, and mx.zoho.com means Zoho Mail. When MX points to a security gateway or to the company’s own server, the SPF record, a few well-known DKIM selectors and Microsoft’s public tenant discovery usually reveal what sits behind it. It’s all public DNS, it takes a minute, and it never touches anyone’s mailbox.

Why it’s worth knowing

The provider tells you more than where mail goes:

• Integrations. If your product connects to Google Drive, Gmail, Outlook, SharePoint or Teams, the company’s suite decides which connector they need and whether an admin has to approve it. See onboarding integrations.
• Sales routing. A Microsoft 365 shop and a Google Workspace shop often want a different demo, rep or integration story. See sales routing by workspace.
• Qualification. A company that pays for a business suite or a mail security gateway runs a real mail setup. That’s one of the signals behind telling a business email from a personal one.
• IT and security conversations. If you sell email, security or deliverability tooling, knowing the suite and the gateway saves a round of questions.

All you need is the company’s email domain, the part after the @. You never need a person’s address.

Step 1: Look up the MX records

An MX (mail exchanger) record names a server that accepts mail for the domain, with a priority number. Lower numbers are tried first.

From the command line

On macOS or Linux:

dig +short MX acme.io

On Windows:

Resolve-DnsName acme.io -Type MX
# or: nslookup -type=mx acme.io

Illustrative output for a domain on Google Workspace:

1 smtp.google.com.

With a web tool

The MX lookup tool lists the hosts by priority and names the provider it recognizes behind each one. If you type an email address, it uses only the domain.

Before you read the answer

• Look up the main domain. Subdomains like eu.acme.io occasionally have their own MX, but the organization’s suite almost always shows on the main domain.
• Start with the lowest priority number. That’s the primary route. Backup hosts with higher numbers are sometimes a different service.
• No MX, or MX 0 . A null MX (0 .) means the domain explicitly accepts no mail. With no MX record at all, the domain almost certainly doesn’t receive email either.

Read the MX hostnames

Each provider uses recognizable hostnames. These are patterns isBusinessEmail matches on the end of each hostname (so mx2.zoho.com matches zoho.com), with the mail.provider value our API returns:

MX host looks like	Provider	mail.provider
smtp.google.com, aspmx.l.google.com, alt1.aspmx.l.google.com	Google Workspace	google_workspace
gmail-smtp-in.l.google.com	Consumer Gmail	gmail
acme-io.mail.protection.outlook.com, hosts ending in mx.microsoft	Microsoft 365	microsoft_365
*.olc.protection.outlook.com	Consumer Outlook.com	outlook_consumer
mx.zoho.com, mx.zoho.eu, mx.zoho.in	Zoho Mail	zoho
mail.protonmail.ch, mailsec.protonmail.ch	Proton Mail	proton
in1-smtp.messagingengine.com	Fastmail	fastmail
mx.yandex.net	Yandex 360	yandex_360
*.pphosted.com, *.ppe-hosted.com	Proofpoint (gateway)	proofpoint
*.mimecast.com	Mimecast (gateway)	mimecast
*.iphmx.com	Cisco Secure Email (gateway)	cisco_secure_email
*.secureserver.net, *.ionos.com, *.mail.ovh.net	Web-hosting mailboxes	godaddy, ionos, ovh
route1.mx.cloudflare.net, mx1.improvmx.com	Forwarding only	cloudflare_email_routing, improvmx

Treat mail.provider as an open set: new values appear as we fingerprint more hosts.

Google Workspace vs Gmail

Google uses different mail servers for its business and consumer products. smtp.google.com is the single record Google gives newer Workspace accounts; older setups list aspmx.l.google.com plus alt1 to alt4. gmail-smtp-in.l.google.com is consumer Gmail, and seeing it on a company domain is odd. More in Google Workspace vs Gmail in DNS.

Microsoft 365 vs Outlook.com

Exchange Online gives each domain its own host, built from the domain name with dots turned into dashes: acme.io becomes acme-io.mail.protection.outlook.com. Domains that turn on DNSSEC for inbound mail can get newer hostnames ending in mx.microsoft. Consumer Outlook.com and Hotmail use *.olc.protection.outlook.com instead. See Microsoft 365 tenant vs Outlook.com for what that difference means for integrations.

Zoho, Proton, Fastmail and Yandex 360

These are business-capable suites too. A company on mx.zoho.com is still a company; it just won’t work with a Google-only or Microsoft-only integration. Our API reports these in workspace.other_suite. Proton and Fastmail host many companies and also many individuals with a personal domain, so on their own they say less about company size. Their own shared domains, such as proton.me or fastmail.com, are personal addresses like any other free email provider.

Hosting companies, forwarding and self-hosted mail

• Web-hosting mail (GoDaddy, IONOS, OVH and many regional hosts) usually means a smaller business that bought email together with its website.
• Forwarding services such as Cloudflare Email Routing or ImprovMX have no mailboxes. They pass mail on to another inbox, which may well be a personal Gmail account, and DNS can’t tell you which.
• The company’s own hostname, such as mail.acme.io, means self-hosted mail (on-premises Exchange, a Linux mail server) or a branded name for a hosted service. The next steps help here.

When a security gateway hides the provider

Many mid-size and large companies send inbound mail through an email security gateway: Proofpoint, Mimecast, Cisco Secure Email, Barracuda, Trend Micro and others. The gateway filters spam and malware, then hands clean mail to the real mailbox provider. MX shows only the gateway:

$ dig +short MX bigcorp.example
10 mx0a-001234.pphosted.com.
10 mx0b-001234.pphosted.com.

A gateway is a strong sign of a company with an IT budget, but it says nothing about the suite. For that, look at how the domain sends mail and where it signs in. Outgoing mail usually leaves straight from Google or Microsoft, so SPF, DKIM and Microsoft’s tenant records still point at the real provider.

Step 2: Check the SPF record

SPF is a TXT record listing which servers may send mail for the domain. Each include: names a sender, and the mailbox provider is almost always one of them.

dig +short TXT acme.io | grep spf1
# "v=spf1 include:spf.protection.outlook.com include:mail.zendesk.com -all"

SPF include	Provider
_spf.google.com	Google Workspace
spf.protection.outlook.com	Microsoft 365
zohomail.com (older setups: zoho.com)	Zoho Mail
_spf.protonmail.ch	Proton Mail
spf.messagingengine.com	Fastmail
_spf.yandex.net	Yandex 360

Treat SPF as medium evidence. It proves the provider sends mail for the domain, not that the mailboxes live there: a company may send through Google while receiving elsewhere, and includes left over from an old provider are common. The other includes are useful too. HubSpot, Salesforce, Zendesk or SendGrid sending on the domain’s behalf is a hint of a working business. The SPF & DMARC checker parses the includes for you.

Step 3: Probe well-known DKIM selectors

DKIM public keys live at <selector>._domainkey.<domain>. DNS can’t list them, so you can only ask for selector names you can guess. Several providers use fixed or default names:

Query	Found means
TXT google._domainkey.acme.io	Google Workspace (the admin console’s default selector)
CNAME selector1._domainkey.acme.io and selector2	Microsoft 365, when they point to a Microsoft hostname (onmicrosoft.com, or dkim.mail.microsoft on newer setups)
CNAME protonmail._domainkey.acme.io	Proton Mail
CNAME fm1._domainkey.acme.io	Fastmail

dig +short TXT google._domainkey.acme.io
dig +short CNAME selector1._domainkey.acme.io

DKIM is the best way to see past a gateway, because mail is signed by the service that sends it. A hit is strong evidence. A miss proves little: admins can pick other selector names (Zoho lets them name their own), and some domains don’t set up DKIM at all.

If you’ve received an email from the company, its DKIM-Signature header shows the real selector (s=) and signing domain (d=), which saves the guessing.

Step 4: Check for a Microsoft 365 tenant

Microsoft publishes an OpenID Connect discovery document for every Entra ID tenant (the directory behind Microsoft 365) and resolves it by domain name. It’s the most reliable Microsoft signal, and gateways don’t affect it:

curl -s https://login.microsoftonline.com/acme.io/v2.0/.well-known/openid-configuration \
  | jq -r .issuer
# https://login.microsoftonline.com/<tenant-id>/v2.0

If the domain is verified in a tenant, the issuer contains the tenant ID (a GUID) and tenant_region_scope shows the region. If it isn’t, you get an error. Microsoft documents the endpoint in its OpenID Connect guide. Smaller Microsoft breadcrumbs: a TXT record MS=ms12345678 (domain verification) and an autodiscover CNAME pointing to autodiscover.outlook.com.

Two cautions:

• A tenant isn’t a mailbox. Plenty of companies have a tenant for Teams, Azure or sign-in while their mail runs on Google. Combine the tenant with MX and SPF before you conclude “Microsoft 365 mail”.
• Stay at the domain level. Microsoft’s sign-in endpoints can also be asked about individual usernames. That’s user enumeration, it isn’t needed to identify a provider, and we don’t do it.

Google has no equivalent public lookup, so Google Workspace detection is DNS-only. The Microsoft tenant lookup shows the tenant ID, region, and whether sign-in is managed or federated to another identity provider such as Okta, ADFS or Ping.

Other clues, and what DNS can’t tell you

• Message headers. In an email you received from the company, Received: lines name the servers it passed through, and Microsoft 365 adds headers starting with X-MS-Exchange-.
• Verification records. google-site-verification= is weak on its own, because Google Search Console uses it too. MS=ms… is a medium Microsoft signal.
• Mixed setups are normal. Microsoft identity with Google mail, or a company mid-migration, shows signals from both. Report both instead of picking one.

What none of this tells you:

• Whether a specific person has a mailbox or a license on that provider.
• Who the admin is, or whether they’ll approve an integration.
• Anything about an individual. These are facts about the domain.

Putting it together

Read the signals in order and stop as soon as you have a confident answer.

1. MX names a suite (Google, Microsoft, Zoho, Proton, Fastmail, Yandex 360): that’s the provider. SPF is a quick second opinion.
2. MX is a gateway, a web host or the company’s own server: check DKIM selectors and SPF includes, then Microsoft tenant discovery.
3. Signals disagree: report both suites, or “unknown”, rather than guessing.
4. No MX: the domain doesn’t receive mail, and addresses on it are invalid.

Do it in one call

For one domain at a time, use the free tools: MX lookup, Google Workspace checker and Microsoft tenant lookup. In code, POST https://api.isbusinessemail.com/v1/check with {"domain":"bigcorp.example"} runs the MX fingerprinting, the Google DKIM check, the Google and Microsoft SPF checks and Microsoft tenant discovery in one call, and returns the evidence for each verdict:

{
  "domain": "bigcorp.example",
  "category": "business",
  "mail": { "has_mx": true, "provider": "mimecast" },
  "workspace": {
    "google_workspace": { "detected": false, "evidence": [] },
    "microsoft_365": {
      "detected": true,
      "tenant_id": "00000000-0000-0000-0000-000000000000",
      "auth": "managed",
      "evidence": ["spf_microsoft", "entra_tenant"]
    },
    "other_suite": null,
    "pending": false
  }
}

(Trimmed; values illustrative.) MX shows Mimecast, while SPF and the Entra tenant reveal Microsoft 365 behind it. Field meanings are in response fields and the evidence rules in Workspace detection. Results are cached per domain for 30 days, and no individual person is ever looked up.

If you still need to reach someone at that company, how to find someone’s business email address covers doing it responsibly.