Skip to content
StoutNook
Menu

MX lookup

Enter a domain to list its MX records: the mail servers that accept its email, in the order they're tried. Common providers such as Google Workspace and Microsoft 365 are recognized.

Public DNS lookup. Only the domain and record names (such as example.com) are sent, to Cloudflare's DNS resolver.

You'll see the mail servers in the order senders try them, their addresses, the email provider, and any problems with fixes.

  • Looks up public DNS records only
  • Free, no sign-up
  • Works on phone and desktop

How to look up MX records

  1. 1

    Type a domain, such as example.com, or paste an email address.

  2. 2

    Click Look up MX to list its mail servers in the order senders try them.

  3. 3

    See which provider handles the mail and the addresses each server resolves to.

  4. 4

    Fix anything flagged, such as a server that no longer exists, then look up again.

Features

  • Priority order

    Mail servers sorted by preference, the order every sending server follows, with their IPv4 and IPv6 addresses.

  • Provider recognized

    Google Workspace, Microsoft 365, Zoho, Proton, Fastmail, iCloud, Cloudflare Email Routing, Mimecast, Proofpoint and more.

  • Mistakes flagged

    MX records pointing at an IP address, an alias or a host that no longer exists, plus null MX and missing MX explained.

  • Public DNS only

    Looked up through Cloudflare's resolver. Nothing is sent to the mail servers themselves.

What MX records do

MX (mail exchanger) records answer one question: where should email for this domain be delivered? When a server has a message for jane@example.com, it looks up the MX records of example.com, sorts them by preference, and connects to each in turn until one accepts the message. RFC 5321, the standard for SMTP, describes this process in section 5.1.

MX records only cover receiving. They say nothing about which servers may send mail as your domain; that is SPF's job, with DKIM and DMARC alongside it.

How to read MX records

A fictional company with its own mail server and a backup might publish:

example.com.  MX  10 mx1.example.com.
example.com.  MX  10 mx2.example.com.
example.com.  MX  20 backup.example.net.

Senders split mail between mx1 and mx2, which share preference 10, and use the backup only when neither answers. The numbers are relative: 10 and 20 work exactly like 1 and 2. Each host name must have its own A or AAAA record with the server's address, which this lookup shows next to every server.

Most businesses use a hosted provider instead, and the host names reveal which one:

ProviderMX host names look like
Google Workspacesmtp.google.com, or aspmx.l.google.com and alt1–alt4 on older setups
Microsoft 365example-com.mail.protection.outlook.com
Zoho Mailmx.zoho.com, mx2.zoho.com, mx3.zoho.com
Proton Mailmail.protonmail.ch, mailsec.protonmail.ch
Fastmailin1-smtp.messagingengine.com, in2-smtp…
Cloudflare Email Routingroute1.mx.cloudflare.net to route3

Security gateways such as Mimecast, Proofpoint and Barracuda sit in front of the mailbox provider, so their names appear in the MX records instead of Microsoft's or Google's.

Null MX, implicit MX and domains without mail

A domain that never receives email should say so with a null MX: one record, 0 ., as defined in RFC 7505. Senders then reject mail to it immediately rather than retrying for days. Pair it with v=spf1 -all and a DMARC p=reject record so nobody can send as the domain either.

With no MX records at all, senders fall back to the domain's own A or AAAA address, called an implicit MX. That is usually a web server, so the mail waits in queues and eventually bounces. This lookup tells you which of these cases applies.

Common MX mistakes

  • Pointing at an IP address. 10 192.0.2.25 is invalid; create a name such as mail.example.com with an A record and point the MX at it.
  • Pointing at an alias. RFC 2181 forbids an MX host that is a CNAME. Use the name the alias points to.
  • Leftovers from an old provider. MX records for two mailbox providers split your mail between them unpredictably.
  • A host that no longer exists. Senders skip it, and if every host is broken, mail bounces.
  • Forgetting the TTL. Lower it a day before switching providers, so the change spreads within minutes.

MX records and email authentication

Changing where you receive mail often changes how you send it too. After a move, update the SPF record so the new provider may send (check it with the SPF checker), publish the new provider's DKIM key (verify it with the DKIM checker), and confirm your DMARC report address still reaches a working mailbox with the DMARC checker. An mx term in your SPF record allows your receiving servers to send, which is only right if they really do send your mail; with hosted providers they usually don't.

Frequently asked questions

What is an MX record?

A DNS record that names a server accepting email for a domain, with a preference number. When someone emails you@example.com, their mail server looks up example.com's MX records and delivers to the server with the lowest number first.

What does the MX priority (preference) number mean?

Lower numbers are tried first; only the order matters, not the size of the numbers. Servers with the same number share the load at random. Higher numbers act as backups when the first choice is busy or down.

What is a null MX record?

A single MX record of "0 ." (preference 0, host a single dot), defined in RFC 7505. It says the domain accepts no email, so senders give up at once instead of retrying for days. Use it on domains that never receive mail.

What happens if a domain has no MX records?

Senders fall back to the domain's own A or AAAA address, the "implicit MX" of RFC 5321. If that address is a web server that doesn't accept mail, messages sit in queues and then bounce. Add MX records, or a null MX if the domain shouldn't get mail.

How do I change my email provider without losing mail?

Lower the MX records' TTL a day ahead, create the mailboxes at the new provider, replace the MX records with the new provider's, and keep the old mailboxes for a few days to catch mail sent before the change spread. Then update SPF and DKIM for the new provider.

Can an MX record point to an IP address or a CNAME?

No to both. RFC 5321 requires a host name, so an address like 192.0.2.1 is read as a name that doesn't exist. RFC 2181 says the host must not be an alias (CNAME); many senders cope, but some don't. Point the MX at a host with its own A or AAAA record.

More free tools