What an MX record is, and what it is not
A mail exchanger record names the hosts that accept mail for a domain and gives each one a preference. That is the entire content of the record type. It is a routing instruction and nothing more: it does not say whether the hosts are running, whether they will accept mail for your domain, or whether the messages they accept will reach anybody’s inbox.
The gap between routing and delivery is where most confusion originates. A domain can have perfectly configured MX records and still lose mail, because the record was only ever one step of the process. The report above deliberately separates the routing facts from the observations that follow from them, so the boundary is visible.
Reading the list
The preference number is a priority, and the smallest number wins. Senders try the lowest first and only fall through to higher numbers when a lower host is unreachable, which means a high preference number is a standby rather than a share of the load. Two hosts sharing the same preference are different: senders may then choose between them, and the order shown is not meaningful for those entries.
That difference matters when you are reasoning about capacity. A pair of hosts with preferences 10 and 20 is not a load-balanced pair; it is a primary with a backup. If the primary is overwhelmed rather than unreachable, the backup does nothing, because senders keep handing mail to the primary.
Frequency of failure is the other thing the list reveals. A single MX record is a single point of failure: while it is down, senders queue mail and retry, and after their retry window expires the mail bounces. Whether that matters depends on how long an outage is tolerable, which is a business decision rather than a DNS one.
The two rules that catch people out
The first is that an MX target must be a host name that resolves to an address directly. It must not be an alias. Mail routing is the one place where this rule is enforced strictly, and the reason is practical: a resolver following an alias during mail routing can produce a different address than the one the sender evaluated, which makes the routing decision meaningless.
The second is that a domain publishing no MX record is not the same as a domain publishing a null MX. With no record at all, senders fall back on the domain’s address record, which usually means mail is either rejected or, worse, quietly dropped. A single record with a preference of zero and a target of a single dot is the explicit way to declare that a domain accepts no mail, and it is the correct configuration for a domain that only serves a website.
Why the first host gets a second look
The report resolves the address of the host with the lowest preference and checks two things: whether that name is an alias, and what reverse record the address publishes. Both are cheap to confirm and both are common causes of a delivery problem that appears to have no explanation.
The alias check exists because a provider that hands you a host name for web traffic may expect it to be used differently for mail. The reverse check exists because many receiving servers compare the address of a connecting host against the name it announces, and treat a mismatch or an absence as a negative signal. A missing reverse record is worth fixing before exploring anything more complicated.
That check is limited to the first host by design. Reading reverse records for every entry in a long list would produce a large report mostly full of results that do not matter, and the first host is the one that carries the traffic in ordinary operation.
What this page does not tell you
It does not test whether any host accepts mail. Sending a probe would require opening a connection to a third party’s server, which this site does not do to addresses it was merely asked to look up. Whether the hosts respond is a separate question that only a connection attempt answers.
It does not confirm that the addresses listed are authorised to send. Receiving is MX and sending authorisation is SPF, and the two are configured independently — a provider can appear in one and not the other, which is a common source of authentication failures. The SPF checker reads the sending side.
It says nothing about whether messages will be delivered rather than rejected or filed away. That depends on authentication, the reputation of the sending addresses, complaint rates and content. The email deliverability test gathers the pieces that live in DNS and orders them; the rest is not in DNS at all, which is the subject of why legitimate email goes to spam.
Where a domain is not receiving mail because it should not, the relevant configuration is the null MX described above. Where the question is who administers the mail infrastructure rather than where mail goes, the nameserver and zone records on the WHOIS alternative page are the ones to read.