MX Lookup

An MX (mail exchanger) record tells the rest of the internet which servers accept email for a domain. When someone sends a message to anna@example.com, their mail server looks up the MX records of example.com and delivers to one of the servers listed there. Each record holds two things: a priority number and the host name of a mail server (RFC 1035 §3.3.9), for example 10 mx1.example.com.

Lower numbers come first. Sending servers try the record with the lowest number first and move to higher numbers when it cannot be reached (RFC 5321 §5.1). Records with the same number share the load: senders pick among them at random. The numbers themselves mean nothing beyond their order, so 1 and 10 work the same when there is only one record.

This MX record check goes one step further than listing the records. For the domain you enter it:

1. asks a recursive DNS resolver for the MX records and sorts them by priority;
2. looks up the IPv4 (A) and IPv6 (AAAA) addresses of each mail server, up to 10 servers, the most preferred first;
3. checks the reverse DNS (PTR record) of each public address, up to 32 addresses, and whether the name it gives points back to the same address;
4. recognizes a null MX, which says that a domain accepts no email, and a domain without MX records, whose mail then goes to the domain's own address.

Every DNS answer behind the result, with the resolver that gave it, is in the Raw evidence panel under the result. The lookup only reads DNS: it never connects to the mail servers. To see whether a server answers on port 25 and offers encryption (STARTTLS), use the SMTP test. The whole email setup of a domain (SPF, DMARC, DKIM and more, MX included) is in the email domain check.

The panel at the top of the result is the verdict: a colored icon and a short label. An MX lookup can end in Pass, Warning, Fail or Could not check. The verdict follows the most serious finding in the list under it (Fail first, then Could not check, then Warning), except reverse DNS, which never changes it (see below). Every finding links to its explanation here. Under the verdict, a table lists each MX record with its priority, the mail server's addresses and their reverse DNS.

The MX records and their mail servers

• Pass: the domain has MX records, and every mail server we checked has a public IP address. The records are listed in the order senders use them, lowest number first. A domain with more than 5 different mail servers gets a note: that is allowed, but RFC 5321 §5.1 lets senders limit how many addresses they try (it only asks them to try at least two), so the most preferred servers matter most.
• Fail: none of the mail servers is usable. MX records exist, but none of them leads to a server with a usable public address. RFC 5321 §5.1 says senders must report this as an error, so mail sent to the domain bounces. When a record holds a public IP address instead of a host name, that is true of senders that follow the standard, while some others deliver to the address anyway (see an IP address instead of a host name); the finding says so, and it stays a Fail.
• Fail: no MX records and no address. Without MX records senders fall back to the domain's own address (see below). When there is none either, email to the domain cannot be delivered. Publish your provider's MX records, or a null MX if the domain should not receive email.
• A value that is not a valid host name, for example one with an empty part between two dots, cannot be used by senders, and we do not look it up. It is a Fail when no other mail server works, a Warning otherwise.
• Could not check: the MX query or the address lookup of a server got no usable answer, or the domain lists more than 10 mail servers and the rest were not checked. That is not a verdict about the records; see Could not check below.

Null MX: the domain accepts no email

A null MX is a single MX record with priority 0 and the value . (a lone dot). It tells senders that the domain accepts no email (RFC 7505 §3), so a mistyped address fails when the message is sent rather than hours or days later (§4.1). The lookup shows it as Pass: it is the right setup for a domain that never receives mail, such as example.com.

• Warning when the null MX is not in that exact form, for example 10 . or two such records. Some senders may not recognize it and keep retrying.
• Fail when the null MX sits next to ordinary MX records. RFC 7505 says a domain with a null MX “MUST NOT advertise any other MX RR”, and what senders do with the mix is unpredictable. Keep one or the other.

A domain with a null MX should not send email either. RFC 7505 §4.2 says mail systems should not publish a null MX for domains they use in sender addresses, and one that does “risks having its mail rejected”.

Warning: no MX records, so mail goes to the domain's own address

When a domain has no MX records at all, senders do not give up. RFC 5321 §5.1: “If an empty list of MXs is returned, the address is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host.” Mail then goes to the domain's own A or AAAA address, which is often just a web server. If nothing there accepts mail on port 25, messages fail or wait in queues.

Publish an explicit MX record: your provider's records, an MX pointing to the server at that address if it really is your mail server, or a null MX if the domain should not receive email. Some DNS dashboards have a “no email” setting that only removes the MX records (Namecheap's No Email Service does), which leaves the domain in exactly this state.

Aliases: a CNAME at the domain or at a mail server

The domain you entered is an alias (a CNAME record points it to another name). Senders then use the MX records of the name it points to, so the result shows those, with a note. This is information, not a problem. A name with a CNAME can have no other records, so to change where its mail goes you change the MX records of the target, or replace the CNAME with records of your own.

Warning: a mail server name is an alias. The host name in an MX record should be the real name of the server: RFC 2181 §10.3 says the value of an MX record “must not be an alias”, and RFC 5321 §5.1 puts such records outside the standard, so senders are not required to follow them. Put the name the alias points to into the MX record instead. If your mail provider told you to use the alias, check with them first.

Fail: an IP address instead of a host name

An MX record must name a server, as in 10 mail.example.com, and that name must have an address record (RFC 5321 §5.1). A value such as 10 203.0.113.25 is an IP address, and a valid host name never has that form (RFC 1123 §2.1). Senders that follow the standard cannot use it: Exim, for example, rejects such a record with an error unless its administrator has switched on an option for it. Some other mail servers accept a public IP address there anyway, so mail may reach you from some senders and fail from others. That is why it is a Fail even if some mail arrives. We do not look the value up. Add an A record (AAAA for an IPv6 address) for a name such as mail.example.com with the server's public IP address, then point the MX record to that name. If the address in the MX record is a private or reserved one, which cannot be reached from the internet, do not copy it: the new record needs the server's public address.

A mail server without an IP address

The MX record names a server whose name has no A or AAAA record, so nobody can connect to it. It is a Fail when no other mail server of the domain works, and a Warning when others do, because senders skip it and use them. Give the server its address, or delete the MX record if the server is gone. A name like mail.example.com.example.com is a classic slip: in a zone file, a name without a final dot is relative, so the zone's own name is added to it (RFC 1035 §5.1). Some dashboards do the same with a name typed without the final dot.

Private, reserved or tunnel addresses

• Only private or reserved addresses (such as 10.0.0.5 or 192.168.1.10): they work inside one network, but senders on the internet cannot reach them. Fail when no other mail server works, Warning otherwise. Publish the server's public address and keep private ones in internal DNS.
• Warning: public and private addresses mixed. Senders that try the private address first lose time before they move on. Remove it from public DNS.
• Warning: an IPv6 tunnel address (6to4 in 2002::/16 or Teredo in 2001::/32). These tunnels are unreliable: the IETF deprecated anycast 6to4 because of its high failure rates (RFC 7526), and Teredo is meant only as “IPv6 access of last resort” (RFC 4380 §3.2). Give the server a native address instead.

Warning: no mail server has an IPv4 address

All mail servers that work have only IPv6 addresses. Mail servers that send over IPv4 only cannot deliver to them. Add an A record with a public IPv4 address for at least one mail server; RFC 3974 §4.1 recommends that a site reachable over both protocols publish A and AAAA records for its MX hosts.

Reverse DNS (PTR) of the mail servers

For each public address we look up its reverse DNS name (the PTR record) and then check that this name has an A or AAAA record with the same address. When both directions match (forward-confirmed reverse DNS), the address gets a green tick in the table.

• No PTR record, or a PTR name that does not point back: listed with a Pass mark, because it does not change the verdict, and with a fix that shows the PTR record to set; in the table the address gets no tick. No standard requires reverse DNS for a server that only receives mail, and large providers do not always set it: on September 26, 2026, none of the addresses we got for the mail server of outlook.com had a PTR record. RFC 1912 §2.1, an informational RFC, recommends a matching PTR record for every IP address. Reverse DNS matters for sending: Gmail requires the IP address of a server that sends mail to have a PTR record whose name resolves back to that address, and Yahoo asks for reverse DNS on all sending IPs. If your MX server also sends your mail, as self-hosted servers often do, fix it. The deliverability test checks the reverse DNS of the server that actually sent your test message.
• Could not check: a reverse lookup got no usable answer, the PTR record lists more than 3 names and none of the ones we checked matched, or the domain has more than 32 mail server addresses and the rest were not checked. Like a missing PTR record, this does not change the verdict.

The PTR record is set by whoever owns the IP address, which is your hosting provider or network operator, not at your DNS provider. Ask them to set it to the mail server's host name.

Could not check

A DNS query got no usable answer: it timed out, the resolver reported a server failure (SERVFAIL) or refused the query, or the answer could not be decoded safely. This says nothing about your MX records. We never turn a missing answer into a pass or a fail, and neither do senders: when the MX lookup fails temporarily, RFC 5321 §5.1 has them queue the message and retry later. Try again in a minute. If it keeps happening, check that your domain's DNS servers answer and that DNSSEC is not broken, for example after a change of DNS provider.

Could not check: a fault on our side

Rarely, the result says the check could not be completed because of an internal error. That is a fault in our software, not a finding about your domain and not a network problem, so trying again will most likely give the same result. Please write to support@mxverdict.com with the address of the result page, and we will fix it.

The same rules apply at every DNS provider:

1. Change the records where your DNS is hosted: at the provider your domain's NS records point to, which is not always the company you bought the domain from.
2. Name: enter @ (or leave the field empty, if the provider allows it) for the domain itself. MX records live at the domain name, with no prefix.
3. Value: the host name your mail provider gives you, never an IP address and never an alias. Some dashboards want a final dot, as in smtp.google.com.; follow your provider's format.
4. Priority: the lowest number is tried first. Remove the MX records of a provider you no longer use: if they keep a lower number, mail keeps going there.
5. One provider receives the mail for a name. To receive mail at a second service, give it a subdomain such as parse.example.com with its own MX records.
6. Check the result by looking up the domain here. Senders that looked up the old records may keep using them until their TTL runs out.

Google Workspace

Google's current setup is a single MX record:

Type: MX   Name: @   Priority: 1   Value: smtp.google.com

Google asks you to remove any other MX records and says it can take up to 72 hours for the new records to be recognized. After that, activate Gmail in the Google Admin console (Menu > Account > Domains > Manage domains). Domains set up before 2023 may use the older records that start with aspmx. Google says: “If your email is working, no changes are required. Any account can use the new single MX record value, but the legacy MX record values are still supported.” The older set, as Cloudflare's guide lists it:

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

Use one set or the other, not both.

Microsoft 365

The MX value is specific to your domain: copy it from the Microsoft 365 admin center (Settings > Domains, then your domain and its DNS records). It ends in mail.protection.outlook.com, or for many domains added since July 2026 in mx.microsoft:

Type: MX   Name: @   Priority: 0   TTL: 3600
Value: <MX token>.mail.protection.outlook.com

Microsoft's instructions say to set the priority to “the highest value available, typically 0”, which means the most preferred one: the lowest number among your MX records. Exchange Online supports TTL values below 6 hours. Remove the MX records of your previous provider, or give them a larger number than the Microsoft 365 record, so that mail starts arriving in Microsoft 365.

Zoho Mail

Zoho's help shows these values as the generic setup:

10 mx.zoho.com
20 mx2.zoho.com
50 mx3.zoho.com

The ending of the host names depends on the Zoho data center that hosts your account, so copy the exact values from Tools & Configurations in the Zoho Mail Admin Console. Delete the records of your previous provider: Zoho warns that with other MX records at a lower number, such as 0 or 5, mail is not delivered to Zoho Mail.

SendGrid, Mailgun and Amazon SES

These services are mostly used to send mail. They need MX records in the cases below, each time on a name of its own, usually a subdomain, so that your domain itself keeps receiving mail at your mailbox provider:

• Mailgun (receiving and routes): 10 mxa.mailgun.org and 10 mxb.mailgun.org; a domain in Mailgun's EU region uses the hosts mxa.eu.mailgun.org and mxb.eu.mailgun.org instead. Mailgun's FAQ: “Only one email server can receive messages for a given domain name”, so if Google or Microsoft receives mail at your domain, give Mailgun a subdomain.
• SendGrid (Inbound Parse): 10 mx.sendgrid.net on a host name used for nothing else, such as parse.example.com.
• Amazon SES, email receiving: 10 inbound-smtp.us-east-1.amazonaws.com, with the AWS Region you use in place of us-east-1. These are not IMAP or POP3 servers, so they do not go into a mail app.
• Amazon SES, custom MAIL FROM domain for sending (such as bounce.example.com): an MX record 10 feedback-smtp.us-east-1.amazonses.com, again with your Region, together with the SPF record the SES console shows.

Your own mail server

Give the server a name with an address record, then point the MX record to that name:

mail.example.com.   A    203.0.113.25
example.com.        MX   10 mail.example.com.

Ask your hosting provider to set the reverse DNS (PTR) of 203.0.113.25 to mail.example.com, then test the server itself with the SMTP test.

A domain that never receives email

Publish a null MX instead of leaving the domain without MX records: one MX record with priority 0whose value is a single dot. In a zone file:

example.com.   MX   0 .

If the domain sends no email either, RFC 7505 §4.2 suggests an SPF record that says so, v=spf1 -all (a TXT record at @).

Cloudflare

1. In the Cloudflare dashboard, open your domain and go to the DNS Records page.
2. Select Add record and choose MX as the Type.
3. In Name, enter @. In Mail server, enter the host name, and in Priority the number from your provider. Leave TTL on Auto and select Save.

MX records are always DNS-only at Cloudflare, but the host name they point to must be DNS-only too: a proxied name resolves to Cloudflare's addresses, and mail (SMTP) does not work through Cloudflare's standard proxy. If Email Routing is turned on, Cloudflare manages the MX records itself; turn it off before you set up another mail provider.

GoDaddy

1. Sign in to your GoDaddy Domain Portfolio and select the domain to open its Domain Settings.
2. Select DNS, then Add New Record, and choose MX in the Type menu.
3. Enter @ in Name, the number in Priority and the host name in Value. The default TTL of 1 hour is fine.
4. Select Save. If Domain Protection is on, GoDaddy asks you to confirm your identity first.

If the domain uses GoDaddy's nameservers and one of GoDaddy's own email services, GoDaddy adds the MX records for you.

Namecheap

1. Sign in, open Domain List and select Manage next to your domain.
2. Open the Advanced DNS tab and find the Mail Settings section.
3. Choose Custom MX for Google Workspace, Microsoft 365, Zoho and other providers, and add each record with Host @, the host name as Value and its Priority. (Namecheap's own Gmail choice is marked as temporarily not working; it asks Google Workspace users to use Custom MX.)
4. Save the changes. Namecheap says it normally takes 30 minutes for new records to take effect.

The No Email Service choice leaves the domain with no MX records at all. That is not a null MX: senders then try the domain's own address (see Warning: no MX records above). Namecheap also warns that a CNAME record on the bare domain stops email from working.

To find and check the MX records of your domain:

1. Enter the domain in the form at the top of this page: the part of your email address after the @. MX records belong to the domain itself, so enter example.com, not www.example.com or mail.example.com, unless you receive mail at that subdomain.
2. Read the table from the top. The first row is the server that senders try first; each server shows its addresses and whether their reverse DNS is set.
3. Compare the host names with the values your email provider gives you (the provider sections above list the common ones). A leftover MX record of a previous provider sends mail to the wrong place.
4. Read the findings under the verdict: each one says what is wrong and links to how to fix it.
5. After a change, check again. This page reuses a result for 60 seconds, so wait a minute. Under the table, the result also shows the TTL: how long the resolver we asked may keep reusing the records it has.

To see whether a change has reached other resolvers, compare the answers of several of them with the DNS propagation checker or with the commands below.

On macOS and Linux, dig prints the MX records of a domain; +short leaves out everything but the records, and @1.1.1.1 asks that public resolver instead of your network's own:

dig MX example.com +short
dig @1.1.1.1 MX example.com +short

On September 26, 2026, one run of dig MX gmail.com +short returned:

20 alt2.gmail-smtp-in.l.google.com.
30 alt3.gmail-smtp-in.l.google.com.
40 alt4.gmail-smtp-in.l.google.com.
5 gmail-smtp-in.l.google.com.
10 alt1.gmail-smtp-in.l.google.com.

We ran it five times in a row and got the same five records in five different orders; asked three times, 1.1.1.1 kept one order, but not a sorted one. Tools print the records as the resolver sends them, not sorted. Sort them by the number yourself; here gmail-smtp-in.l.google.com with priority 5 is tried first. The final dot only marks a complete name. For example.com the same command returned 0 ., a null MX.

In the Windows Command Prompt, and on macOS and Linux too, use nslookup; add a resolver address at the end to ask a specific one:

nslookup -type=MX example.com
nslookup -type=MX example.com 1.1.1.1

It prints one line per record, such as gmail.com mail exchanger = 5 gmail-smtp-in.l.google.com. In Windows PowerShell:

Resolve-DnsName -Name example.com -Type MX
Resolve-DnsName -Name example.com -Type MX -Server 1.1.1.1

These commands show the records only. To see the addresses of a mail server, look up its A and AAAA records (dig A gmail-smtp-in.l.google.com +short); this page does that for every server at once.