What this analysis does
Enter a domain to retrieve its current MX routes, priorities and likely inbound provider. Mailybox also recognizes the standards-defined Null MX signal for domains that intentionally reject mail and explains when SMTP may fall back to an A or AAAA address because no explicit MX exists.
An MX lookup answers one precise question: where does this domain accept inbound mail, and in what order. The useful part is not the hostname list but what the configuration implies about routing, fallback behaviour and the provider actually receiving the mail.
Priority is preference, not rank of importance
Each MX record carries a preference value, and a sending system tries lower values first. Equal values are selected among at random, which distributes load. A higher number does not mean a backup server in any protocol sense; it means a less preferred route that is used when preferred hosts do not answer.
That distinction matters operationally. A secondary MX that no longer accepts or forwards mail correctly will still be attempted when the primary is unreachable, which converts a short outage into lost or delayed mail. Every published exchanger should be a host you are willing to have receive production mail.
- Lower preference numbers are tried first.
- Equal preference values are chosen among at random.
- Every published MX should be a host that can actually accept mail.
Null MX and implicit address fallback
RFC 7505 defines a single MX record with preference 0 and a target of a lone dot as an explicit statement that a domain accepts no mail. Publishing it lets senders fail immediately and permanently instead of retrying for days, and it is the correct configuration for a domain used only for a website or only for outbound sending.
When no MX record exists at all, RFC 5321 allows a sender to fall back to the domain’s A or AAAA address and attempt delivery there. That implicit fallback is frequently unintended: a web server suddenly receives SMTP connections because a domain has an address record and no mail policy. Null MX removes that ambiguity.
Read MX together with the rest of the mail policy
MX describes inbound routing only. It says nothing about which systems are authorized to send on the domain’s behalf, which is governed by SPF, DKIM and DMARC. A domain can receive mail through one provider while sending through several unrelated platforms, and that separation is normal.
The combination worth checking is inbound routing against transport security. A domain that publishes MTA-STS must have every published exchanger match a pattern in its policy file, or conforming senders will refuse delivery to the hosts that do not match.
Check MTA-STS and TLS-RPT for the same domainSee MX in the full infrastructure model
Example: a domain that intentionally rejects mail
Evidence supplied
Domain: assets.example.com — a single MX record with preference 0 and a target of a lone dot.
How to read the result
The result reports Null MX rather than a routing failure, and explains that senders should treat delivery as permanently rejected. No A or AAAA fallback applies, because the domain has explicitly declared that it accepts no mail.
Known limits
- Results reflect what the resolver observes at analysis time; DNS propagation and caching can differ elsewhere.
- A published exchanger is not proof that the host is reachable or currently accepting connections.
- Inbound routing says nothing about the domain’s outbound authorization or reputation.
Common questions
Do I need more than one MX record?
Not necessarily. Many providers publish a single exchanger backed by their own redundancy. Additional records only help when the extra hosts genuinely accept and correctly forward mail.
What happens if a domain has no MX record?
A sender may fall back to the domain’s A or AAAA address under RFC 5321. Publish Null MX if that behaviour is not intended.
Does changing MX affect SPF or DMARC?
Not directly. MX governs inbound routing, while SPF, DKIM and DMARC govern outbound authorization. They are changed and evaluated independently.