FindLeadEmails
Email intelligence
Try it for free
Tool

MX lookup

See which mail server a domain uses, and whether it looks like Google Workspace, Microsoft 365, or something else.

This tool only reads public DNS or runs in your browser. It does not spend verification credits.

What MX lookup is for

Mail eXchanger records tell the internet which servers receive mail for a domain. If you are about to verify addresses, send a campaign, or debug "why did this bounce," the MX record is the first fact, not a footnote.

Paste a domain. We resolve MX (and you can switch to the combined SPF / DKIM / DMARC checker when you need authentication, not just routing). This is public DNS. It does not spend verification credits. It is uncapped.

How to read what comes back

MX records have a priority (lower number = more preferred) and a hostname. Typical shapes:

  • Google Workspace: aspmx.l.google.com and several altN.aspmx.l.google.com backups.
  • Microsoft 365: domain-com.mail.protection.outlook.com.
  • A transactional provider (Mailgun, SendGrid, Amazon SES) mixed with a Workspace record — meaning marketing mail and people-mail are split on purpose.
  • Nothing. No MX means the domain is not set up to receive mail. Do not verify people@that-domain expecting an inbox.

Priority 0 vs 10 vs 20 is failover, not "which one is the real company." Senders should let their MTA walk the list.

Why outbound teams care

  • You are verifying the wrong domain. The marketing site is getbrand.com and mail lives on brand.com. MX tells you in one lookup.
  • You think they are on Google because the website says Gmail, and they migrated to Microsoft last quarter. The finder talks to whatever MX says *now*.
  • Catch-all behaviour differs by host. Knowing it is Microsoft 365 vs Google vs a custom Postfix box changes how you interpret a timeout.

None of this is a substitute for mailbox verification. MX says mail *can* be received at the domain. It says nothing about jane.doe@.

MX vs A vs CNAME

People paste a website, get a CNAME CDN, and wonder why mail lookup looks empty. Mail is not web hosting. www.company.com can point at Vercel while company.com MX points at Google. Always look up the domain you would put after the @.

If you only have a LinkedIn company page and a brand name, find the website first, then strip it to the registrable domain, then look up MX.

A fictional walkthrough

You are not sure whether Jane Doe's company receives at company.com or company.io.

  1. Look up both here.
  2. company.com returns Google Workspace MX. company.io returns nothing.
  3. Use company.com in the finder.

Jane Doe is not a real person. The point is the domain choice.

Common mistakes

  • Looking up https://company.com/ with the scheme still attached.
  • Looking up mail.company.com because you saw it in an SPF include. SPF includes are *senders*. MX is *receivers*. They are often different companies.
  • Assuming "has MX" means "has this employee." That is the domain vs mailbox confusion again.

Related DNS

Once you know who receives mail, authentication is the next layer: SPF, DKIM and DMARC explained, the combined checker, and per-provider setup under /dns.

Related