# MX Record and Mail Routing Inspector > Resolve a domain's live mail-routing records, understand the order in which receiving servers are tried, inspect every exchanger's IPv4 and IPv6 addresses, and identify DNS configurations that can prevent email delivery. - **Canonical page:** [https://emailbump.com/tools/mx-record-lookup](https://emailbump.com/tools/mx-record-lookup) - **Interactive tool:** [Open the MX routing inspector](https://emailbump.com/tools/mx-record-lookup) - **Category:** Email deliverability and DNS diagnostics - **Processing:** Live DNS data is requested from Google Public DNS over HTTPS. The tool sends the domain and subsequent exchanger hostnames needed for the analysis. It does not send email or connect to SMTP servers. ## What the tool checks Enter a domain, URL, or email address. The inspector normalizes the input to a hostname and performs a live MX query. For each exchanger it then resolves A and AAAA records, follows DNS aliases when necessary, and builds a routing view with: - MX preference numbers and delivery tiers - The exchangers that can be tried at each tier - IPv4 and IPv6 destination addresses - MX and address TTL values - DNSSEC authentication evidence returned by the resolver - Explicit MX, implicit MX, Null MX, and unroutable states - Equal-preference groups - Duplicate MX records - MX targets that resolve through a CNAME - Exchangers with no usable A or AAAA address - Private, loopback, link-local, documentation, or otherwise non-public addresses - Shared addresses used by several exchanger names - A copyable zone-style summary and a downloadable JSON report The result describes DNS routing evidence. It does not open port 25, conduct a recipient probe, negotiate SMTP, verify a certificate, or send a test message. ## MX records in plain language An MX record tells an SMTP sender which host accepts mail for a domain. The DNS record contains two important fields: 1. A preference number 2. The hostname of a mail exchanger An example zone might contain: ```dns example.net. 3600 IN MX 10 inbound-a.example.net. example.net. 3600 IN MX 20 inbound-b.example.net. ``` The first number is a preference, not a port, percentage, or arbitrary label. Lower values are preferred. A sender first tries an exchanger in the lowest available preference tier. If delivery cannot be completed there, it can try an exchanger in a higher-numbered tier. The target is a hostname. It is not normally an IP address. The sender resolves that hostname to A and/or AAAA records before opening an SMTP connection. ## Preference is order, not traffic weight MX preference is often called priority in DNS dashboards. The standards field is named preference, and the behavior is ascending order: 0 is preferred over 10, and 10 is preferred over 20. Two hosts with the same preference are alternatives within the same tier: ```dns example.net. 3600 IN MX 10 mx1.provider.test. example.net. 3600 IN MX 10 mx2.provider.test. ``` SMTP senders are expected to randomize equal-preference exchangers. Equal values therefore provide a pool, but they are not a precise 50/50 load-balancing instruction. Resolver caches, retry behavior, address selection, sender implementations, network conditions, and server availability can produce uneven traffic. Do not use preference values as weights. Values of 10 and 20 do not mean a two-to-one traffic split. They create a primary tier and a later fallback tier. ## How failover actually works A secondary MX is useful only if it can correctly accept, queue, reject, or relay mail for the destination domain. Publishing a backup hostname does not make it ready. A sender may move to another exchanger when it cannot reach the preferred host or when a temporary SMTP failure makes another attempt appropriate. The exact attempt sequence and retry schedule belong to the sending implementation. A higher-preference-number server should not be treated as a way to bypass a permanent recipient or policy rejection from the primary. Before adding a backup MX, verify: - It recognizes every valid recipient or has a safe recipient-validation mechanism. - It will not accept unknown recipients and later generate backscatter. - Its relay policy cannot be abused. - Its queue and retry behavior are understood. - It applies compatible filtering and authentication policy. - It can reach the real destination after accepting a message. - Its TLS identity and operational monitoring are maintained. For many managed mailbox providers, redundancy exists behind several provider-controlled MX hosts. An additional customer-operated backup can reduce reliability if it has different recipient data or weaker filtering. ## Explicit MX An explicit MX result means the queried domain published one or more MX records. That is the normal configuration for a domain that receives email. The inspector groups explicit records by preference. It also resolves each target so you can distinguish a published hostname from an actually addressable destination. A syntactically valid MX record is not proof that delivery works. The target may lack an address, port 25 may be unreachable, the SMTP service may reject the domain, or the service may be misconfigured after the DNS lookup succeeds. ## Implicit MX fallback SMTP defines a fallback when a domain has no MX records. In that case, the domain is treated as though it had an implicit MX pointing to itself with preference 0. The sender can resolve the domain's A or AAAA records and attempt delivery there. For `example.net`, the conceptual fallback is: ```dns example.net. IN MX 0 example.net. ``` This behavior is why “no MX record” does not always mean “cannot receive mail.” If the domain itself has a usable address and an SMTP server, delivery can still be attempted. Relying on implicit MX is usually less clear operationally than publishing the intended explicit MX records. Website and mail migrations can become coupled because the same root address participates in both. If the domain should receive email, publish and monitor explicit MX records. If it should never receive email, publish Null MX rather than relying on the absence of records. ## Null MX Null MX is the standards-based way for a domain to say that it accepts no email. The record is exactly: ```dns example.net. 3600 IN MX 0 . ``` The target is the DNS root, written as a single dot, and the preference is 0. A proper Null MX RRset contains only that record. It prevents senders from applying implicit MX fallback to the domain's web-server address. Null MX is appropriate for domains used only as identifiers, redirectors, websites, or outbound-only infrastructure when they intentionally have no inbound mailbox service. These are configuration problems: - A Null MX mixed with ordinary MX records - A root target with a nonzero preference - A domain that publishes Null MX while users expect to receive replies - Treating `0 .` as a temporary disabled state without coordinating senders and users The inspector identifies a valid Null MX separately from an absent or broken route. ## Why an MX target must not be a CNAME An MX target must resolve directly to address records and must not be an alias. RFC 2181 makes this explicit for values used as MX targets. For example, avoid: ```dns example.net. IN MX 10 mail-alias.example.net. mail-alias.example.net. IN CNAME real-mail.provider.test. ``` Publish the canonical exchanger name as the MX target instead: ```dns example.net. IN MX 10 real-mail.provider.test. ``` Some senders will follow an alias, which can make the mistake appear harmless. That tolerance is not guaranteed and adds extra DNS dependencies. The inspector follows aliases to show where a hostname eventually leads, but flags the chain as a standards violation rather than declaring it healthy. Provider onboarding instructions sometimes ask customers to create a CNAME for a branded hostname. That does not automatically make the branded hostname valid as an MX target. Follow the provider's exact MX records, and verify whether the DNS dashboard has flattened or transformed the data. ## Addressability: A and AAAA records After selecting an exchanger, an SMTP sender needs an address. An A record supplies IPv4 and an AAAA record supplies IPv6. An MX target with neither is unusable. Common causes include: - A deleted server record left behind during a migration - A misspelled provider hostname - An MX record copied from the wrong region - An alias chain that ends without an address - A DNS outage or delegation problem - A split-horizon name that resolves only inside a private network The inspector checks both address families. Having only A is normal for an IPv4-only mail service. Publishing AAAA carries an additional obligation: IPv6 routing, firewall policy, reverse DNS, SMTP service, TLS, and operational monitoring should work over IPv6. A broken IPv6 path can introduce delays when senders try it before IPv4 or according to their connection strategy. The tool warns about non-public address ranges because Internet senders cannot route to RFC 1918 private IPv4 addresses, loopback addresses, link-local addresses, or documentation ranges. A private address can be correct in an internal DNS view, but it is not a public inbound mail destination. ## DNSSEC evidence The resolver can return an Authenticated Data indication when it has validated a DNSSEC chain for an answer. The tool surfaces that evidence for the MX query and address lookups. An authenticated answer means the validating resolver confirmed the DNS data against DNSSEC. It does not mean: - The SMTP server is trustworthy - The server supports TLS - The certificate matches - The mailbox provider is secure - The domain has correct SPF, DKIM, or DMARC - The route will accept a particular recipient An answer without authenticated data is not automatically forged or broken. The zone may be unsigned, a chain may be incomplete, or validation evidence may not be available in the response. Treat DNSSEC as one integrity signal, not as a complete email-security verdict. ## TTLs and migration timing The TTL tells recursive resolvers how long an answer can normally remain cached. Changing a record at the authoritative server does not instantly replace every cached copy. A practical MX migration sequence is: 1. Inventory the current MX records, TTLs, exchanger addresses, recipient behavior, and provider dependencies. 2. Prepare and test the new receiving service before publishing it. 3. Lower the relevant TTLs at least one old-TTL period before the cutover. 4. Publish the new MX set exactly as instructed by the provider. 5. Keep the old service able to receive and forward mail while old answers remain cached. 6. Test several recipients and rejection cases from external networks. 7. Monitor queues, bounces, provider logs, and inbound volume. 8. Remove old routes only after the cache window and operational overlap have passed. 9. Raise TTLs again once the route is stable. The TTL visible in a recursive answer is often the remaining cache lifetime, not necessarily the original authoritative TTL. Use the authoritative zone or provider dashboard when planning exact timing. ## Common routing patterns ### One provider, several equal-preference hosts Managed providers often publish multiple exchanger names at the same preference. This creates a first-choice pool. The provider may also distribute each hostname across several addresses. ### Primary and secondary tiers A lower-numbered primary host is tried before a higher-numbered backup tier. Confirm that the backup is a real part of the same receiving architecture and has current recipient knowledge. ### One MX hostname with several addresses A single exchanger name can resolve to several A and AAAA records. This can still provide connection-level diversity, although a separate name may make failure domains and operations easier to reason about. ### Several MX names sharing one address Different hostnames that converge on the same IP may not provide independent infrastructure. The tool calls out shared addresses so operators can investigate whether the apparent redundancy is real. ### No MX, root address exists This invokes implicit MX behavior. It may work, but explicit records are clearer for a domain intended to receive mail. ### No MX and no root address There is no usable SMTP route. If the absence is intentional, Null MX communicates that fact cleanly. If it is not intentional, restore an explicit receiving route. ## A diagnostic workflow for missing inbound mail Use DNS evidence in context: 1. Confirm the exact recipient domain. A subdomain can have a different MX policy from its parent. 2. Inspect the MX response and identify explicit, implicit, or Null MX behavior. 3. Read preference values from lowest to highest. 4. Verify every target ends at public A or AAAA records without an MX-target CNAME. 5. Check TTLs and consider whether a recent change is still cached. 6. Compare the result from another validating recursive resolver and, when needed, query authoritative nameservers. 7. Test TCP connectivity to port 25 from an appropriate external system. 8. Perform a controlled SMTP dialogue without sending unwanted mail. 9. Confirm the receiving service recognizes the domain and intended recipient. 10. Check provider event logs, queues, deferrals, and bounce responses. 11. Review recent DNS, domain-verification, firewall, certificate, and provider-account changes. If a sender returned a bounce, preserve the complete enhanced status code, diagnostic text, reporting host, and timestamp. A DNS route can be healthy while the SMTP service rejects a recipient, policy, message, or sending IP. ## What the inspector cannot prove The tool does not: - Query authoritative nameservers directly - Show every resolver's cached view - Guarantee a DNSSEC result independently of the selected resolver - Connect to an exchanger on port 25 - Test network routing, firewalls, or connection timeouts - Perform an SMTP greeting, EHLO, STARTTLS, or recipient command - Validate an SMTP TLS certificate - Determine whether a recipient exists - Inspect provider queues or account configuration - Verify reverse DNS for exchanger addresses - Assess the sending reputation of an IP - Check SPF, DKIM, or DMARC policy - Guarantee that equal-preference traffic is evenly distributed - Guarantee that a published backup accepts the same recipients as the primary Use the result as a DNS routing map and a starting point for operational diagnosis. ## Frequently asked questions ### Does the lowest MX number win? It is the most preferred tier and is tried before higher-numbered tiers. Equal values form alternatives within the same tier. Successful delivery still depends on reachability and SMTP behavior. ### Is MX priority 0 valid? Yes. Zero is a valid and highly preferred value. It is also required for the special Null MX form when the target is the root dot. A target of `mail.example.net` with preference 0 is an ordinary MX, not Null MX. ### Do I need more than one MX record? Not necessarily. Redundancy can exist behind one hostname through multiple addresses and provider infrastructure. Multiple records help only when the routes are independently useful and correctly operated. ### Why does my website work when inbound email does not? Web and mail routing use different DNS data and ports. A working A or AAAA record for HTTPS does not repair a broken explicit MX target. It matters to email only when implicit MX fallback applies. ### Why does the tool show an implicit route? The domain has no MX record, so SMTP's fallback points at the domain itself. Publish explicit MX records for a receiving service or a proper Null MX if the domain intentionally accepts no mail. ### Can an MX point to an IP address? The MX exchange field is a domain name. Publish a hostname and give that hostname A and/or AAAA records. ### Can an MX target be proxied through a web CDN? Most HTTP reverse proxies do not proxy SMTP. An MX target must resolve to an address where the mail service is actually reachable. Disable web-only proxying for mail hostnames unless the service explicitly supports inbound SMTP. ### Does an MX record affect outbound email? MX primarily directs inbound delivery. Outbound sending uses the sender's configured relay. However, receivers and users may still expect a working reply domain, and some systems consider broader domain configuration during trust decisions. ### Does this check protect against spoofing? No. MX describes where inbound mail goes. SPF, DKIM, and DMARC address sending authorization, signatures, and From-domain policy. ### Is it safe to query a production domain? The operation is read-only. The entered domain and exchanger hostnames are sent to Google Public DNS over HTTPS for resolution. No SMTP connection or email is created. ## Primary sources - [RFC 1035: Domain Names — Implementation and Specification](https://www.rfc-editor.org/rfc/rfc1035.html) - [RFC 5321: Simple Mail Transfer Protocol](https://www.rfc-editor.org/rfc/rfc5321.html) - [RFC 2181: Clarifications to the DNS Specification](https://www.rfc-editor.org/rfc/rfc2181.html) - [RFC 7505: A “Null MX” No Service Resource Record for Domains That Accept No Mail](https://www.rfc-editor.org/rfc/rfc7505.html) ## Related tools and guidance - [Email header analyzer](https://emailbump.com/tools/email-header-analyzer.md) - [SPF lookup budget checker](https://emailbump.com/tools/spf-record-checker.md) - [DKIM record checker](https://emailbump.com/tools/dkim-record-checker.md) - [DMARC record builder](https://emailbump.com/tools/dmarc-record-builder.md) - [SMTP bounce code decoder](https://emailbump.com/tools/bounce-code-decoder.md) - [Sending domains documentation](https://emailbump.com/docs/domains.md) - [MX record definition](https://emailbump.com/glossary/mx-record.md) - [Email authentication definition](https://emailbump.com/glossary/email-authentication.md) - [Domain reputation guide](https://emailbump.com/blog/check-email-domain-reputation.md) - [Bounce handling guide](https://emailbump.com/blog/email-bounce-handling-guide.md)