This free MX lookup lists a domain's mail servers and who runs them.

Each MX result means one thing, and each has one fix.

The lookup gives one line for the domain's mail servers. Find that line below to see what it means and what to change. When you run a lookup, the row that matches your result is marked.

See which mail provider your domain shares with 13,511 listed companies.

We read the MX records of 13,511 listed companies on 18 October 2026. 32.7% hand their mail to Microsoft 365, 30.4% to another host or their own server, 18.7% to a security gateway that filters it first, 9.6% to Google Workspace, and 8.5% list no mail server at all.

How the example domain compares, so you can see what your own result will show.

The mail host says a lot about how the rest of the domain is set up.

A security gateway reads every message first and then hands it to the mailbox provider behind it, so the MX tells you the filter, not always where the inbox lives. These are large listed companies, not cold email domains, so read the numbers as the standard the people you email already meet, not as a target for your own setup.

Source: Emailchaser DMARC adoption study, 13,511 company domains with a stock exchange listing, read from public DNS on 18 October 2026. See the full study and its data.

A sending server picks the mail server in three steps.

Every MX record carries a priority number, and the lowest number wins.

1. 1

   It looks up the MX records

   The sending server asks DNS for every MX record the recipient's domain publishes.

2. 2

   It sorts by priority

   The record with the lowest number is the primary server. Equal numbers share the load.

3. 3

   It delivers or falls back

   It tries the primary server first, and only moves to a higher number if that one cannot be reached.

Publish MX records at the root of the domain, one for each mail server.

Your email provider gives you the host names and priorities. Use exactly those.

1. Open the DNS settings for the domain and delete any old MX records from a previous provider.
2. Add one MX record for each host your provider lists. The host is @, and the priority is the number the provider gives.
3. Save, then run the lookup above. Lower the old records' TTL a day before a migration to make the cutover faster.

These are the MX records of the two providers most cold email domains use.

1 smtp.google.com

1 aspmx.l.google.com
5 alt1.aspmx.l.google.com
5 alt2.aspmx.l.google.com
10 alt3.aspmx.l.google.com
10 alt4.aspmx.l.google.com

0 yourdomain-com.mail.protection.outlook.com

MX records tell the internet where to deliver mail for a domain.

MX records are the DNS entries that route email to the right servers. Looking them up tells you whether a domain can receive mail at all, and which provider runs it. For your own sending domain, that is the question of whether replies to your campaigns can come back. For a domain you are about to email, it is the first sign of whether the address can exist.

The lookup above runs on our server against live DNS, lists the mail servers in priority order, resolves each one to its address, and names the mailbox provider or security gateway behind them. It also runs the SPF, DKIM, DMARC and blocklist checks on the same domain, because an MX record alone says nothing about whether your mail arrives.

The MX hostname usually gives the provider away.

A security gateway reads every message first and then hands it to the mailbox provider behind it, so the MX tells you the filter, not necessarily where the inbox lives. That matters for cold email: a gateway is one more system that reads your SPF, DKIM and DMARC before a person ever sees the message.

An MX record proves the domain can receive mail, not that an address exists.

A domain having MX records means it can receive email, but not that a specific address is real. Catch-all domains accept everything and tell you nothing. When you need certainty about one address, it has to be checked mailbox by mailbox: the free email checker does that for single addresses, and the bulk email verifier for a list. From your own code, 1Lookup, built by the same team as Emailchaser, offers the same check as a bulk email validation API.

The MX record also tells you nothing about who is on the other end of an address. If that is the question you actually have, you can look up the owner of an address from the address itself.

A domain with no MX record usually cannot receive mail at all.

The most common reason is that the domain simply is not set up for email: a parked domain, a redirect-only domain, or one bought purely for a website. Under the mail-routing rules a server may fall back to the domain's A record when there is no MX, so a handful of domains still accept mail without one, but you should not count on it.

Before assuming a domain is dead, rule out the simple causes. Check the spelling, and make sure the domain was not registered or moved in the last hour. And a single record pointing to a bare dot is a null MX (RFC 7505): a deliberate signal that the domain never accepts mail. Our check fails both cases, because a sending domain that cannot receive replies loses every answer to its campaign.

Your own sending domain needs MX, SPF, DKIM and DMARC before it sends.

If you are troubleshooting your own sending, MX is only the first line of the report above. Gmail, Yahoo and Outlook require SPF, DKIM and DMARC from bulk senders (Google, read 6 October 2026), so read the other four rows, or open the SPF, DKIM and DMARC checkers for the full detail.

Sending history is the part no DNS check can show you. A mailbox that has never sent anything has no reputation to spend, which is why warming up the sending mailbox belongs on the same checklist.

Provider hostnames as matched by our provider classifier, the same one the Inbox Rules Index uses.

Common questions about MX records

Check the rest of your setup with these free tools.