What does the MX priority number mean?

Lower numbers are tried first. Servers with the same number share the load, because senders must pick among them at random. Higher numbers act as backups when the primary servers don't answer.

What is a null MX record?

A single MX record pointing to '.' with priority 0 (RFC 7505). It announces that the domain deliberately accepts no email, which is good practice for domains that never receive mail. Don't use it on a domain you send from: receivers may reject mail from it.

What happens if my domain has no MX record?

Senders fall back to the domain's own A or AAAA record, called an implicit MX, and try to deliver to whatever server answers there. That may not be a mail server at all, so publish MX records if you receive mail, or a null MX if you don't.

Do MX records affect whether my email lands in spam?

Not directly; MX records control receiving. But a domain that can't receive mail looks suspicious to some filters, and without working MX you also can't receive DMARC reports sent to that domain.

Can I use two mail providers at once?

Not by mixing their MX records. Every sender picks servers by preference alone, so mail would be split between the two in a way you don't control. Keep one provider's MX records and use the other's forwarding or routing features if you need both.

How long does an MX change take to work?

Senders keep the old answer until its TTL runs out, which your DNS host shows next to each record. If you plan a move, lower the TTL first and wait for the old TTL to pass; the switch then spreads quickly.

MX Lookup — Find a domain's mail servers

List the mail servers that receive email for a domain, in priority order, and see which mailbox provider runs them.

By Ahmet Karaca · Updated October 17, 2026 · Checked against RFC 5321 (SMTP), RFC 7505 (null MX) and RFC 7208 (SPF) on October 17, 2026

Receiving versus sending

MX records only decide where incoming mail is delivered. Whether your outgoing mail is trusted depends on SPF, DKIM and DMARC. That's why a domain can receive mail perfectly and still have its messages flagged as spam, or be spoofed by anyone.

How MX records are written

An MX record has two parts: a preference number and the name of a mail server. A domain usually has several:

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

Under RFC 5321, sending servers sort the records by preference and try the lowest number first. Records with the same number share the load: a sender must pick among them at random rather than always using the first. A higher number is a fallback, used when the preferred servers don't answer. In the example, mail goes to mx1 or mx2, and to the backup only when both fail.

The second part must be a host name, not an IP address, and that name must resolve to at least one A or AAAA record. The RFC also leaves a name that returns a CNAME outside the standard, so point MX records at the real server names your provider gives you.

Null MX: saying "no mail here"

A domain that never receives email can say so with a null MX, defined in RFC 7505: a single record with preference 0 and a lone dot as the server.

example.com.  MX  0  .

It must be the only MX record on the domain. Sending servers then fail a message to that domain at once instead of retrying for days, and the RFC suggests the reply code 556 with the status 5.1.10. It works in the other direction too: receivers may reject mail whose sender address uses a null-MX domain, with 550 and 5.7.27. So publish a null MX only on domains that also send no mail, and RFC 7505 suggests pairing it with an SPF record of v=spf1 -all.

No MX at all: the implicit MX

If a domain exists but publishes no MX records, RFC 5321 tells senders to treat the domain's own address records as an implicit MX with preference 0. Mail then goes to whatever server answers at the domain's A or AAAA address, which may be a web server that doesn't accept email. As soon as one MX record exists, the A records are no longer used for mail. And if the domain doesn't exist at all, the sender reports an error.

What each part of the result means

Mailbox provider. Shown when the mail server names belong to a provider in our sender catalog, such as Google Workspace or Microsoft 365. It is recognized from the names alone; no line means we didn't recognize them, not that something is wrong.
Priority and mail server. Every MX record, lowest preference first, and alphabetically within the same preference. That is the order senders work through.
Implicit MX note. Appears when the domain exists but has no MX records, and explains where senders will try to deliver instead.
Findings. A missing MX is a warning, a null MX a note, and a domain that doesn't exist or a DNS failure a problem. A domain with working MX records shows "No problems found".

Common errors and how to fix them

The lookup reports these findings, with the message you see in the result:

Warning: "example.com has no MX records, so it can't receive email reliably (including DMARC reports sent to it)." Add the MX records your mailbox provider lists. If the domain should never receive mail, publish a null MX instead, so senders stop trying.
Note: "example.com publishes a null MX: it deliberately accepts no email." Right for a domain that neither sends nor receives. If you do send from it, remove the null MX, because receivers may reject your mail.
Problem: "example.com doesn't exist in DNS. Check the spelling." DNS says the name doesn't exist. Check for a typo, and if the domain is new, that its registration and nameservers are active.
Problem: "We couldn't query MX records for example.com. Try again in a minute." The DNS servers didn't answer in time. We don't keep this result, so the next check asks again.

Other mistakes break delivery but aren't flagged here, because the lookup reads the MX records and nothing behind them. Look out for them in the server list:

Records left over from an old provider. Senders use them by preference like any other record, so some or all of your mail can land on servers you no longer read. After a move, delete every MX record you no longer use.
An IP address as the server. RFC 5321 requires a host name. Create an A record for the server and point the MX record at that name.
A null MX next to other records. RFC 7505 says a null MX must be the only MX record. Decide whether the domain receives mail and keep one or the other.
The backup with the lowest number. The lowest preference is tried first, so give your main servers the smallest number.

How we check

We send one MX query for the domain you enter and read the answer the way a sending server would. A "name does not exist" answer means the domain isn't in DNS. An answer with no MX records means the domain exists without MX, so we warn and explain the implicit MX. A single record whose server is a lone dot is a null MX. Otherwise we list every record, sorted by preference and then by name.

To name the mailbox provider, we compare the server names with the mail server domains we know for the providers in our setup guides. A check has 10 seconds to finish, and we reuse a finished result for 5 minutes unless DNS failed.

What it doesn't check

The addresses behind each server name, or whether a server accepts mail. We don't connect to port 25. The PTR checker and the Blacklist checker resolve the servers' addresses and check their reverse DNS and blocklist status.
Whether the servers offer encrypted delivery. The MTA-STS checker checks whether your MTA-STS policy covers every MX host.
Your outgoing mail. MX records only decide where mail to you is delivered.

MX Lookup