Equal preference · randomized
All tools
DELIVERABILITY TOOL / 12MX routing
MX routing
inspector
Resolve the route a sending server sees. Read preference tiers, expand every exchanger to its addresses, and distinguish missing, implicit, and deliberately null mail service.
- Explicit, implicit, and Null MX
- IPv4 and IPv6 expansion
- Alias and resilience review
Inbound mail domain
QUERY PLAN
emailbump.com MXThen A and AAAA for every selected exchanger. No SMTP connection is made.
Queries use Google Public DNS over encrypted HTTPS with EDNS client subnet disabled. Domain names go to Google’s resolver; the tool does not probe port 25 or submit an address.
Preference is order, not speed.
Sending systems try the lowest preference value first. Equal values form one priority tier. Higher values are alternatives when lower-priority-number routes cannot accept delivery.
10 mx-primary.example20 mx-backup.exampleLOWEST VALUE FIRST
MX preference creates tiers, not weights.
A sender sorts MX records by increasing preference. Hosts at the lowest number form the first tier. Equal-preference hosts must be randomized. A larger number is tried only after lower-numbered destinations are unavailable or unusable.
Alternative route
NO MX DOES NOT ALWAYS MEAN NO MAIL
Address records can become an implicit exchanger.
Under SMTP routing, a domain with no MX records can fall back to an implicit MX: the domain itself, with preference zero, provided it has an address record. This legacy behavior is why simply deleting MX records does not clearly declare that a domain accepts no mail.
An implicit route is standards-defined, but an explicit MX is clearer for a mail-receiving domain and a Null MX is clearer for a domain that accepts no mail.
EXPLICITLY NO SMTP SERVICE
Null MX is one preference-zero record pointing to “.”
RFC 7505 defines a Null MX record for domains that do not accept email:0 .. It prevents senders from falling back to A or AAAA. A Null MX must be the only MX record. Mixing it with ordinary exchangers is invalid and does not provide a backup route.
0 .Single Null MXNo email accepted
No MX + AImplicit MXSMTP may try domain
No MX + no A/AAAANo routeUndeliverable
EXCHANGERS SHOULD BE CANONICAL
An MX target must not be a CNAME alias.
RFC 2181 requires the domain name used as an MX value to resolve directly to address records rather than being an alias. The inspector still follows returned aliases to show the operational destination, but reports the configuration as an error.
This rule applies to the MX target. Delegating the mail domain itself or using provider-controlled canonical exchanger names is a different DNS design question.
COMMON QUESTIONS
MX routing inspector FAQ.
Does preference 10 receive more mail than preference 20?+
Normally, preference 10 is attempted first. Preference is an ordering mechanism, not a traffic weight. Equal values form one randomized tier.
Is one MX record automatically unsafe?+
No. One hostname can sit behind resilient anycast or distributed infrastructure. Multiple independently operated routes can improve resilience, but hostname count alone does not prove architecture.
Why does the tool show an implicit MX?+
RFC 5321 defines fallback to the domain’s address when no MX exists. Publish an explicit MX for intended inbound mail, or a Null MX when the domain should accept none.
Does an IP address prove the mail server works?+
No. DNS only provides the destination. SMTP reachability, greeting, recipient acceptance, TLS, reputation, and local policy require separate evidence.
Should every MX hostname have both IPv4 and IPv6?+
Not necessarily. IPv4-only and IPv6-only routes are possible. Operators should ensure the published address families are reachable and intentionally supported.
KEEP INSPECTING
ROUTING IS ONE SIDE
Build a complete sending domain.
Authenticate sending streams, monitor delivery activity, and keep infrastructure evidence connected.
Start for free