Free tool
Which servers receive mail for this domain?
The MX records a domain publishes, in the order a sending server tries them, with a check that every server named exists and resolves to an address. No sign-up, no email to leave.
A wrong MX is mail that never arrives
Not late mail. Refused mail. The sending server reads the MX, tries to connect, fails, retries for a few hours, then hands the message back. Your recipient never hears that anyone wrote. Your sender finds out four days later that nobody read it.
What this check looks at beyond the list
Listing MX records tells you nothing about their health, so the tool follows every target. Is it a name, or an IP address dropped in by mistake. Does it resolve to anything. Is it an alias itself. Those three faults leave the MX looking immaculate in the registrar panel while mail keeps bouncing.
The mechanism
A message's route, server by server
The number in front of a server is not a score. It is the order in which the server gets tried. The sending server walks down the list and stops at the first one that answers. Switch one off and watch the fallback happen.
- 10mail.example.comconnecting…
- 20backup.example.netwaiting
- 30last.example.orgwaiting
The sending server is trying mail.example.com…
Running order and fallback come from RFC 5321, the preference itself from RFC 1035.
The bounce you get
A rejection always says which side is wrong.
The three-digit code and its detail name the culprit — your zone, the server on the other side, or a misspelled address. Three codes settle it.
- 550 5.1.1no such mailbox · the MX is fine
- 550 5.7.1relay denied · the named server does not handle this domain
- 4.4.1target not answering · machine or port closed
Reading the result
The table lists servers in the order a sender tries them, lowest preference first. The findings below are about what each target turns out to be once the name resolves.
- All clear — the servers answer
- Every target is a name, every name resolves to an address, and none of them is an alias. Mail has somewhere to land.
- All clear — “null MX”
- One record, preference 0, target a bare dot. The domain is saying it takes no mail at all. That is deliberate and clean — senders are turned away on the spot instead of queuing for four days.
- Worth watching — no MX at all
- With no MX, a sender falls back to the domain's own address. A web server answers there, has nothing to accept mail with, and the message bounces.
- Worth watching — a target is an alias
- An MX target has to be a name that carries its own address, not an alias pointing at another name. Some sending servers follow it anyway, others refuse outright, and delivery turns into a coin toss.
- Problem — a target does not resolve
- The name sits in the MX but leads to no address. Renamed server, deleted subdomain, typo — the outcome is identical. Nobody can connect.
- Problem — an IP address as target
- The field expects a domain name. A raw address is invalid there, and plenty of servers would rather refuse than guess what you meant.
- Problem — the name does not exist
- No nameserver knows this domain. The problem is not a missing MX — the domain does not exist, or it is no longer delegated.
- Undetermined — no answer in time
- The resolver returned nothing within the allotted time. This happens on a slow or overloaded nameserver, and says nothing about the domain.
The mistakes we see most often
The new MX was added, the old one was never removed
What causes it: the classic migration-day slip. Two providers stay declared, senders take the first by preference, and a slice of the mail keeps landing in an old mailbox nobody opens.
What fixes it: delete the old provider's MX records the moment you switch, not later. As long as they are published, they receive.
The preferences were copied the wrong way round
What causes it: the LOWEST number is tried first. Put the backup on 10 and the main server on 20 and the two quietly swap jobs — everything now runs through a backup that was never sized for it.
What fixes it: read the list again with smallest-wins in mind, and make sure the server at the top is the one actually holding the mailboxes.
The MX points to an alias
What causes it: someone sets up a short name (mail.example.com) as an alias to the real server, then drops that short name into the MX. The standard forbids an alias as an MX target, and some sending servers stop right there.
What fixes it: point the MX at the name that actually carries the address, or swap the alias for an address record.
The server was renamed, the MX was not updated
What causes it: the host renames its gateway and posts the change in its panel, while the customer's MX still names the old one. That name resolves to nothing now.
What fixes it: check the target, not just the MX line. A syntactically perfect MX aimed at a dead name delivers nothing.
The MX was changed in the belief that sending was handled too
What causes it: an MX decides RECEIVING and nothing else. The right to send on the domain's behalf lives elsewhere, in SPF, DKIM and DMARC. Switch mail providers without revisiting those and your messages go straight to spam.
What fixes it: go back over authentication after the switch — the email authentication check, in this same set of tools, tells you where you stand.
What the number in front of each server means
The preference is not a quality score. It is a running order. The sending server starts at the lowest value and only works down the list when nothing answers.
| What the domain publishes | What a server trying to deliver does | How to read it |
|---|---|---|
| 10 mail.example.net | It connects to that server. If nothing answers, it retries on and off for several hours before handing the message back. | The most common arrangement, and the one several business mail providers recommend. |
| 10 a.example.net · 20 b.example.net | It tries a. If it gets nothing, it tries b. | b is a backup, nothing more. It has to know the same mailboxes, or it accepts mail it cannot deliver. |
| 10 a.example.net · 10 b.example.net | Equal preference: it picks one at random. | Load sharing. Both servers must be equivalent. |
| 0 . | It gives up immediately and returns a permanent error. | The null MX — an explicit statement that no mail is accepted. This is the right way to close a domain to email. |
| no MX at all | It falls back to the domain's own address and tries to deliver there. | A fallback written into the standard. It only works if something at that address listens for mail, which a web server rarely does. |
| 10 203.0.113.25 | Many servers refuse to deliver. | The field expects a name, not an address. Put the server's name there instead. |
The running order and the no-MX fallback come from the SMTP standard (RFC 5321). The preference comes from the definition of the MX record itself (RFC 1035). The null MX is described in RFC 7505.
The bounce message, and what it says about the MX
When mail comes back, the failure report carries a three-digit code and then a detailed one. Codes starting with 4xx are temporary, 5xx permanent — and plenty of them have nothing to do with the MX.
| Code | What it means | What to look at |
|---|---|---|
| 550 5.1.1 | The mailbox does not exist on the server that answered. | The MX is fine. The address is wrong, or the mailbox was deleted. |
| 550 5.1.2 | The recipient's domain could not be found. | The domain does not exist, or no nameserver serves it any more. |
| 554 5.7.1 | The server refuses the message on policy grounds. | Usually sender authentication — SPF, DKIM or DMARC, not the MX. |
| 550 5.7.1 | Relaying denied. | The server named in the MX does not consider itself responsible for this domain. The target points at the wrong server. |
| 4.4.1 | No answer from the receiving server. | The MX target is silent on the mail port. Machine down, firewall in the way, or a name that no longer resolves. |
| 4.4.4 | Unable to route the message. | No usable MX was found — empty list, or every target unreachable. |
| 450 4.2.0 | Mailbox temporarily unavailable. | Usually greylisting, and the sender simply has to retry. Nothing to fix. |
| 452 4.2.2 | Mailbox full. | The MX works. The recipient's quota is what blocks. |
Three-digit codes come from RFC 5321, the detailed codes (5.1.1) from RFC 3463. The wording next to them is free-form, so two servers can phrase the same refusal very differently.
Common questions
What does an MX record do?
It names the servers allowed to receive a domain's mail. When someone writes to an address, the sending server looks up that domain's MX to find out which machine to hand the message to. Without one, it has no door to knock on.
What does the priority number on an MX record mean?
It is a preference, and it runs backwards from intuition. The LOWEST value is tried first, so a server at 10 comes before a server at 20. The values themselves mean nothing on their own. Only the order counts, and 1, 5, 10 or 100 work equally well as long as the ranking is right.
How many MX records do I need?
It depends on the provider, and there is no universal answer. Some business mail providers ask for one record and handle redundancy behind that name. Others publish several. The count is not what matters — what matters is that every one of them is reachable and knows the same mailboxes.
What happens if a domain has no MX record?
The standard provides a fallback, and the sender tries to deliver to the domain's own address. In practice that address hosts a web server, which has nothing to accept mail with, so the message bounces. A domain meant to receive nothing is better off saying so with a null MX than leaving the field empty.
I changed my MX records. When does the change take effect?
Not straight away. Every record carries a lifetime, and resolvers around the world hold on to the previous answer until that lifetime runs out. Until it does, some of your mail keeps arriving at the old server. Which is why you lower the lifetime a few hours BEFORE a migration, not on the day itself.
Do MX records affect outgoing email?
No. It decides receiving, and only receiving. The right to send on the domain's behalf is declared in other records — SPF, DKIM and DMARC. A domain can run a flawless MX and still watch every message it sends land in spam because those are missing.
Received wisdom
The number before the server is not a grade
It is the single most common error on an MX record, and once you see it, the fix takes a minute.
What people believe
What the server does
“10 is the quality of the server.”
It is a preference, and the SMALLEST number goes first. Two servers on the same value get picked at random, in equal shares.
“Putting 20 on the second one is free insurance.”
A backup only helps if it knows the same mailboxes. Otherwise it accepts messages it cannot deliver, and loses them very politely.
“Without an MX, mail does not arrive.”
Without an MX, the sender falls back to the domain's own address. The standard defines that fallback, and it only works if something there listens for mail.
“You can put the IP address, it is more direct.”
The field expects a name, not an address. Many servers simply refuse to deliver to an MX carrying an IP address.
The vocabulary
Six words to read an MX record
They turn up in the tables above, in your server logs, and in the bounces that come back to you.
preference- The number before the name. Smallest goes first, and at equal value the choice is random.
null MX- An
MXset to 0 and a bare dot — the explicit statement that this domain accepts no mail. fallback- With no
MXat all, the sender tries the domain's own address. Defined by the SMTP standard. relay denied- The server named in the
MXdoes not consider itself responsible for this domain. The target is wrong. greylisting- A first temporary refusal, followed by acceptance a few minutes later. Nothing to fix.
detailed code- The 5.1.1 that follows the three-digit code. It names the cause, while the text beside it is free-form.