MX Record Lookup
Run an MX lookup on any domain to see the mail servers that receive its email, in the order senders try them.
How to check MX records for a domain
- To find MX records for a domain, type it into the box above. A full email address or a website link works too. The tool keeps only the domain.
- Click Look up MX records. The MX lookup reads the records from public DNS, so you see what a sender sees right now.
- Read the summary first. It tells you whether the domain can receive email.
- Then read the table. Each row is one mail server, with its priority number, its IP addresses and its TTL.
If you changed your records recently and still see the old ones, wait for the TTL shown in the table to run out. TTL is the number of seconds resolvers may keep the previous answer. The link in your address bar runs the same MX record check again. You can send it to a colleague or to your DNS host.
What an MX record is
An MX record (mail exchanger record) is the DNS entry that tells other mail servers where to deliver email for a domain. When someone writes to anna@example.com, their mail server looks up the MX records for example.com and connects to the server named there. Reading those records is what an MX lookup, or mail server lookup, does. For a plain explanation with a step-by-step example, see the MX record entry in our glossary.
Each record has two parts: a priority number and the name of a mail server. Google Workspace's setup guide asks for a single record like this one:
example.com. 3600 IN MX 1 smtp.google.com.
Older Workspace domains often still have five records instead, starting with ASPMX.L.GOOGLE.COM. Google still supports those, so there's no need to change them.
MX records only handle incoming mail. Outgoing mail is covered by other records, mainly SPF, DKIM and DMARC. For how those three work, see SPF, DKIM and DMARC explained.
What the priority number means
Senders try the server with the lowest number first. If it doesn't answer, they move on to the next lowest. When two servers have the same number, senders pick between them at random, which spreads the load (RFC 5321, section 5.1).
Only the order matters, not the size of the numbers. Priorities of 10 and 20 behave the same as 1 and 2. Gmail's own domain, for example, lists five servers at 5, 10, 20, 30 and 40.
What your MX lookup result means
| Result | What it means | What to do |
|---|---|---|
| Can receive email | The domain has MX records and every mail server has an IP address. | Nothing. If mail still doesn’t arrive, look at the mail server itself or at spam filtering. |
| Has MX records, but something needs fixing | At least one record has a problem. The tool lists it under the server. | Fix the record at your DNS host. The common problems are explained below this table. |
| Has no MX records | Senders fall back to the domain’s own address (its A or AAAA record). | Add MX records if the domain should receive email. Your email provider gives you the values. |
| Can’t receive email | No MX records and no address to fall back to. | Add MX records, or leave it if the domain isn’t used for email. |
| Accepts no email | The domain publishes a null MX record (0 .). It tells senders not to try (RFC 7505). | Nothing, if the domain isn’t used for email. Don’t keep one on a domain you send from, because replies and bounces can’t come back. |
| Doesn’t exist | DNS has no record of the domain at all. | Check the spelling, and check that the domain is registered. |
The tool also flags four problems with individual records. A record can point to an IP address instead of a host name. The server name can be an alias (a CNAME), which RFC 2181 doesn't allow. The server name can have no IP address, so mail sent to it can't be delivered. Or the domain can publish a null MX next to normal MX records, which contradicts itself.
MX records for Google Workspace, Microsoft 365 and other providers
If an MX records lookup shows one of these server names, you know who handles the domain's email. The number before each name is its priority. When you set up a provider, copy the values from its own setup page. Some of them depend on your domain or your region.
| Provider | MX records |
|---|---|
Google Workspace Older setups use ASPMX.L.GOOGLE.COM plus four ALT servers. Google still supports them. | 1 smtp.google.com |
Microsoft 365 The first part is unique to your domain. Domains with DNSSEC get a name ending in mx.microsoft. Copy the exact value from the admin center. | yourdomain-com.mail.protection.outlook.com |
Zoho Mail The ending follows your data center, for example mx.zoho.eu for the EU. | 10 mx.zoho.com 20 mx2.zoho.com 50 mx3.zoho.com |
Proton Mail | 10 mail.protonmail.ch 20 mailsec.protonmail.ch |
Fastmail | 10 in1-smtp.messagingengine.com 20 in2-smtp.messagingengine.com |
iCloud Mail For custom domains on iCloud+. | 10 mx01.mail.icloud.com 10 mx02.mail.icloud.com |
Namecheap Private Email | 10 mx1.privateemail.com 10 mx2.privateemail.com |
Cloudflare Email Routing Forwards mail to another inbox. Cloudflare sets the priorities for you. | route1.mx.cloudflare.net route2.mx.cloudflare.net route3.mx.cloudflare.net |
Amazon SES For receiving mail. The middle part is your AWS region. | 10 inbound-smtp.us-east-1.amazonaws.com |
Hostinger | 5 mx1.hostinger.com 10 mx2.hostinger.com |
IONOS Some countries use their own ending, such as mx00.ionos.de. | mx00.ionos.com mx01.ionos.com |
OVHcloud | 1 mx0.mail.ovh.net 5 mx1.mail.ovh.net 50 mx2.mail.ovh.net 100 mx3.mail.ovh.net 200 mx4.mail.ovh.net |
Yandex 360 | 10 mx.yandex.net |
Sometimes the MX records point to Proofpoint, Mimecast or Barracuda instead. Those are security gateways. Mail goes through them first, gets filtered, and then moves on to the real mailbox provider, which the lookup can't see. Gateways also make email verification harder, because they answer for every address. Here is how to verify emails behind a security gateway.
Changing your MX records
To move your email to a new provider, add the new provider's MX records at your DNS host and remove the old ones. Senders follow whatever DNS returns, so mail starts arriving at the new server as cached answers expire.
How long that takes depends on the TTL of the old records. If you plan a move, lower the TTL to a few minutes beforehand. Do it at least one full TTL period ahead, so the old, longer TTL has run out by the day you switch. Raise it again once everything works. Keep the old mailbox open for a few days anyway, in case some mail still lands there.
Providers often quote up to 48 or 72 hours for changes to show up. That's a safe outer limit, not the usual wait. Adding MX records to a domain that had none can take a little longer, because resolvers may also have cached the empty answer. How long they keep it is set by the domain's SOA record.
After the switch, update your SPF record so the new provider may send for you, and turn on its DKIM signing. If you send from your own server, the DKIM generator creates a key, and the DMARC generator builds the DMARC record that ties both together.
An MX lookup doesn't check the mailbox
MX records tell you the domain accepts mail. They don't tell you that a particular address exists. jane@example.com can still bounce when example.com has perfect MX records, because Jane left the company or the address never existed.
Checking the mailbox means asking the mail server, which is what an email verifier does. Use the email checker for one address, or the bulk email verifier for a whole list before a campaign.
Frequently asked questions
It’s the DNS record that names the mail servers for a domain. When someone emails an address at that domain, their mail server looks up the MX records. That tells it where to deliver the message.
Type your domain into the MX lookup at the top of this page. From a terminal, nslookup -type=mx example.com works on Windows, and dig mx example.com works on macOS and Linux.
Yes, and most do. Senders try the record with the lowest priority number first and keep the others as backups. Records with the same number share the load.
Senders fall back to the domain’s own A or AAAA record and try to deliver there. That only works if a mail server runs on that address, so a domain that should receive email needs MX records.
No. It has to name a host that has its own A or AAAA record. An IP address in the record breaks the standard, and RFC 2181 says the name must not be an alias. Some senders cope with an alias, but you can’t count on it.
Whoever runs your domain’s DNS. That’s usually the registrar you bought the domain from, or a service like Cloudflare if you moved your name servers there. The records themselves are public, because every sender needs to read them.
Up to the TTL of the old record. Resolvers that cached it keep the old answer until the TTL runs out, so a TTL of 3600 means up to an hour. Your DNS host may also take a few minutes to publish the change.
No. MX records are for receiving mail. Sending depends on SPF, DKIM and DMARC. Some receiving servers do reject mail from a domain with no MX or A record at all. A domain like that can’t receive the reply.
Check the mailbox, not just the domain
MX records show that a domain can receive mail. Giggal checks whether the address itself exists, catch-all domains included. 1,000 free credits.