How to Find What Email Provider a Company Uses (Free)

Every domain that receives email publishes the answer in public DNS: its MX records name the servers that accept its mail, and those servers give away the provider. Hosts ending in google.com mean Google Workspace, mail.protection.outlook.com means Microsoft 365, and names like pphosted.com or mimecast.com mean the mail runs through an enterprise security gateway before any human sees it. One lookup, free, about ten seconds — no Clay subscription, no data provider, no browser extension.

The lookup is the easy part. The useful part is what the answer changes about how you sell to that company, and cold emailers in particular leave real deliverability on the table by not segmenting lists this way.

What an MX record tells you

When any mail server sends to jane@acme.com, it first asks DNS: who accepts mail for acme.com? The MX (mail exchange) records are the reply. They have to be public and they have to be accurate, or the company stops receiving email — which is what makes this the one enrichment signal that's never stale, never guessed, and never behind a paywall.

We've written before about MX records on your own sending domains, where a missing record silently eats your replies. This is the same record read in the other direction: instead of checking your plumbing, you're reading your prospect's.

The ten-second check

Three free ways, pick whichever fits where you're working:

In a browser. Open https://dns.google/resolve?name=acme.com&type=MX and read the Answer field. This is Google's public DNS-over-HTTPS endpoint — JSON out, no key, no signup.

In a terminal. On macOS or Linux, dig mx acme.com +short. On Windows, nslookup -type=mx acme.com. Either prints the exchange hosts directly.

In Clay. This one matters if you're already enriching lists there: add an HTTP API enrichment, point it at the dns.google/resolve URL above with your company-domain column mapped into name=, and extract the answer with a formula column. That's the whole trick behind the "find ESPs in Clay for free" videos making the rounds — it works, and it costs nothing, because it's the same public DNS query. You don't need a Clay-specific data provider for it, and honestly you don't need Clay for it either.

Reading the answer: MX suffix → provider

The exchange host's suffix identifies the provider. This covers the overwhelming majority of B2B domains:

Two readings that trip people up. A gateway in front doesn't tell you what's behind it — a Proofpoint domain usually has Microsoft or Google underneath, but the gateway does the filtering, so the gateway is what you plan around. And no MX record at all means the domain can't receive email, full stop: every send to it is a guaranteed bounce.

What each bucket means for your sending

Google Workspace. The friendliest mainstream filter for cold email, because Google leans on engagement signals over rigid rules. It's also where most agencies' sending mailboxes live, and same-ecosystem delivery is a quiet advantage: Google trusts mail arriving from Google infrastructure more than mail crossing over from Microsoft's. If your list skews Google, Google-hosted senders are working with the grain.

Microsoft 365. The hardest mainstream filter. Authentication has to be flawless, volume tolerance is lower, and Microsoft's habit is to junk silently rather than bounce — so a Microsoft-heavy segment that "isn't replying" is often a segment that never saw your email. When a quarter or more of a list is Microsoft-hosted, sending part of your volume from Microsoft mailboxes stops being optional and starts being the fix.

Security gateways. Proofpoint, Mimecast, Barracuda and friends exist to stop exactly what you're sending. Plenty of people behind them still reply — the point isn't that these leads are dead, it's that the deliverability bar is higher: mail gets scanned and often quarantined, and complaints from these environments carry disproportionate reputation damage. The rational move is to give gateway domains their own low-volume campaign from your strongest-reputation senders, or work those accounts through another channel — the gateway itself signals a larger org where a single thread rarely closes the deal anyway.

No MX. Remove these before launch. Bounces are the fastest reputation killer in cold email — past about 3% they start compounding — and no-MX domains are free bounces you could have caught with a lookup. A list with many of them usually means stale data, which is its own warning about the rest of the list.

Segmenting by provider won't rescue copy that's landing in spam for other reasons, but it decides where careful sending effort actually pays: match infrastructure to the Google and Microsoft buckets, cut the gateways and no-MX rows, and your bounce and placement numbers improve without touching a single word of the email.

Checking a whole list at once

Manual lookups are fine for one prospect and useless for four hundred. For a list, you want every domain resolved once, classified, and totaled — which is mechanical enough that it shouldn't cost money. We built a free email provider lookup that takes up to 50 emails or domains per batch and returns the split — Google vs Microsoft vs gateway vs no-MX — with each domain's primary MX host, and nothing gets stored. Clay users can keep the HTTP-API version above inside their existing table; the result is identical because the underlying DNS answer is identical.

One step further, for agencies: the provider mix of a lead list only matters in relation to the mailboxes sending to it, and both change over time. ColdOps checks that relationship automatically on live campaigns — it samples each campaign's lead domains, compares the mix against the sending mailbox pool, and raises an alert when a mismatch appears, like a Microsoft-heavy list being worked entirely by Google senders. The manual lookup is how you scout a list before launch; the automated version is how you notice the drift you'd otherwise catch three weeks late in a reply-rate graph.