MX Lookup

Why You Are Here

MX records decide where email for a domain is delivered. When they are wrong, mail either bounces or goes somewhere nobody is watching, and neither failure announces itself clearly.

Email has stopped arriving. Messages bounce, or senders report delivery failures, and you need to confirm the domain still has valid mail servers configured. This is the first check in almost any inbound mail problem.

You are migrating email providers. Moving from one platform to another means replacing MX records, and you need to verify the change has taken effect before assuming mail is flowing to the new host.

You are checking someone else's domain. Confirming which provider handles a company's email, verifying a client's setup before a project, or investigating why mail to a partner organisation keeps failing.

What This Tool Does

The MX Lookup tool queries the DNS records for any domain you enter and returns its mail exchange configuration.

Enter a domain name and the tool returns every MX record published for it, showing each mail server's hostname and its priority value, ordered by which the sending server would try first.

The results tell you whether a domain can receive email at all, which provider handles it, and what happens if the primary server is unavailable.

How Email Routing Works

Understanding the sequence explains why MX records matter and what a lookup is actually telling you.

When someone sends a message to user@example.com, the sending mail server does not simply connect to example.com. That domain may not run a mail server at all: it might delegate email to Google, Microsoft, a dedicated host, or a chain of servers across several countries. So the sending server takes these steps:

Query DNS for the domain's MX records to find out which hosts accept its mail
Read the priority values and sort them lowest to highest
Resolve the hostname of the preferred server to an IP address, since the MX record contains only a name
Connect over SMTP and attempt delivery
Fall back to the next priority if that server is unreachable, refuses the connection, or returns a temporary error

The MX record contains a hostname, not an IP address

This catches people out. Every delivery requires a second DNS lookup to resolve that hostname, which is why an MX record pointing at a name with no A or AAAA record fails even though the MX record itself looks correct.

Reading Priority Values

Priority is the most misread part of an MX record, because the numbers work backwards from how people expect.

The lowest number is tried first

A server at priority 10 is preferred over one at priority 20. Priority 0 is the highest possible preference.

Configuration	Meaning
One record at priority 0	Single server, always used, provider handles redundancy internally
10, 20, 30	Fallback chain, tried in that order
Two records both at 10	Load balancing, mail distributed roughly evenly
5, 10, 20, 30, 40	Deep fallback chain across multiple data centres

Equal priority means load balancing, not redundancy

When two servers share a number, senders distribute mail between them. Large providers use this to spread inbound volume across capacity.

There is nothing special about zero

It is simply the lowest available number. Microsoft 365 publishes a single record at priority 0 because it manages failover inside its own infrastructure rather than exposing it through DNS.

Fallback only triggers on failure

A sender does not rotate through your servers. It uses the lowest-priority host every time and only moves down the list when that host is unreachable, refuses the connection, or returns a temporary error.

Common MX Configurations

What a lookup result typically tells you about a domain's email setup.

Result pattern	What it indicates
Hostnames ending google.com	Google Workspace
Hostnames ending outlook.com	Microsoft 365
A single record at priority 0	Provider-managed redundancy
Several records, ascending priorities	Self-managed fallback chain
Hostnames on the domain's own name	Self-hosted mail server
Hostnames belonging to a security vendor	Mail filtered before delivery
A single record reading 0 followed by a dot	Domain explicitly accepts no email
No MX records at all	Domain has no mail configuration

The Null MX Record

Most domains that cannot receive email simply have no MX records. There is a better way to say so, and almost nobody uses it.

A null MX record is a single record with priority 0 and a hostname of a bare dot

Defined in RFC 7505, it explicitly declares that a domain accepts no email at all.

example.com.    IN    MX    0    .

Why this is better than publishing nothing

No MX records	Null MX records
Senders may fall back to the A record	Senders reject immediately
Bounces are slow and inconsistent	Rejection is fast and unambiguous
Spoofing your domain looks plausible	Declares no mail infrastructure exists
Backscatter can still reach you	No delivery attempts to backscatter

Where it belongs

Parked domains, domains registered only for brand protection, domains used purely for redirects, and any subdomain that should never receive mail. If your organisation holds registrations it never uses for email, each one is a spoofing opportunity that a null MX record closes.

Backup MX Servers Are Usually a Liability Now

Standard advice for years was to configure a backup mail server on a higher priority number. That advice has aged badly, and it is worth stating plainly.

Spammers deliberately target the highest-numbered MX

Backup servers historically run lighter spam filtering than primaries, so sending directly to the last entry in the fallback chain is a known technique for bypassing filters. Attackers query MX records precisely to find that weak point.

A backup that queues mail adds risk rather than resilience

If it accepts messages and holds them, it becomes a store of mail outside your primary filtering, and if it is misconfigured it can generate backscatter by bouncing spam to forged senders.

Modern hosted providers already handle this

Google Workspace and Microsoft 365 publish either a single record or a small set at equal priority, because failover happens inside their infrastructure where it belongs. Adding your own backup in front of that gains nothing.

When a backup still makes sense

Self-hosted mail on a single server where an outage means lost delivery attempts. In that case the backup must run the same spam filtering rules as the primary, or it becomes the easiest way in.

TTL and Propagation

MX changes do not take effect instantly, and this is the most common reason a migration appears to fail.

Every DNS record has a TTL, a time-to-live value in seconds telling resolvers how long to cache the answer. With a common TTL of 3600, senders may continue delivering to your old mail servers for up to an hour after you change the record.

TTL	Cache duration
300	5 minutes
3600	1 hour
14400	4 hours
86400	24 hours

Lower the TTL before a migration, not during it

Reduce it to 300 at least a full TTL period ahead of the change, make the switch, confirm delivery, then raise it again. Lowering the TTL at the same moment you change the record achieves nothing, because resolvers are still holding the old value with the old TTL.

Keep the old mailbox live during the overlap

Mail delivered to the previous server during propagation still needs somewhere to land.

Common Mistakes to Avoid

Pointing an MX Record at a CNAME

The specification requires MX records to point at a hostname that resolves through an A or AAAA record. Pointing one at a CNAME violates that, and while some mail servers tolerate it, others reject the delivery outright. The resulting failures are intermittent and appear to depend on who is sending, which makes them unusually hard to diagnose. Always point MX records at a hostname with a direct address record.

Assuming a Higher Number Means Higher Priority

The numbers work in reverse. A server at priority 10 is preferred over one at priority 20, and priority 0 is the strongest preference of all. Setting your primary server to a large number and your backup to a small one silently inverts your intended routing, sending all mail to the server you meant to use only as a fallback.

Changing MX Records Without Lowering the TTL First

Senders cache MX records for the duration of the TTL, so a change made with a 24-hour TTL still in effect means up to a full day of mail continuing to the old server. Lower the TTL to a short value at least one full TTL period before the migration, then switch. Lowering it at the moment of the change has no effect on records already cached elsewhere.

Quick Reference

Item	Detail
MX record	Where mail for a domain goes
Priority	Lowest number is tried first
Priority 0	Highest possible preference
Equal numbers	Load balancing
Different numbers	Fallback chain
Fallback	Only on failure, not rotation
MX contents	A hostname, never an IP
CNAME	Never point an MX at one
Null MX	Domain accepts no email
No MX at all	Most senders bounce
TTL	Controls how long changes take
Migrating	Lower TTL before, not during
Backup MX	Usually a liability now

Frequently Asked Questions

What is an MX lookup?

An MX lookup queries a domain's DNS records to find its Mail Exchange records, which specify the servers that accept email for that domain. This MX Lookup tool returns each server's hostname and priority value, showing you which server a sender would try first and what the fallback order is.

What does the priority number mean?

It sets the order in which mail servers are tried, and lower numbers are preferred. A server at priority 10 is used before one at priority 20, and priority 0 is the strongest preference available. When two records share the same number, mail is distributed between them, which is load balancing rather than fallback.

What happens if a domain has no MX record?

The original specification says senders should fall back to the domain's A record and attempt delivery there, but most modern mail servers no longer do this and will simply bounce the message. Any domain that should receive email needs an explicit MX record. Domains that should never receive email are better served by a null MX record.

Why can I not point an MX record at a CNAME?

The specification requires MX records to reference a hostname that resolves through an A or AAAA record. Some mail servers tolerate a CNAME and others reject it, so the result is intermittent delivery failures that vary by sender. Point MX records at hostnames with direct address records instead.

How long do MX record changes take to take effect?

As long as the TTL on the record, since senders cache the answer for that duration. A TTL of 3600 means up to an hour of continued delivery to the old servers. Lower the TTL to a short value at least one full TTL period before making a change, then restore it afterwards.

What is a null MX record?

A single MX record with priority 0 and a hostname of a bare dot, which explicitly declares that a domain accepts no email. Defined in RFC 7505, it causes senders to reject immediately rather than attempting delivery. It suits parked domains, brand protection registrations, and redirect domains, and it reduces their usefulness for spoofing.

Should I configure a backup mail server?

Usually not. Spammers deliberately target the highest-numbered MX because backup servers commonly run weaker filtering than primaries, which makes a backup a documented bypass route. Hosted providers such as Google Workspace and Microsoft 365 handle failover internally. A backup only makes sense for self-hosted mail, and it must run identical filtering rules to the primary.

Can I check the MX records of any domain?

Yes. MX records are public DNS information, published so that any mail server on the internet can find out where to deliver messages. Use this MX Lookup tool with any domain name to see its mail servers, priority values, and fallback order, whether or not the domain belongs to you.

Search