MX records tell the internet where to deliver mail

MX records tell the internet where to deliver mail begins with a practical question: how can a reader inspect receiving path and MX priority without confusing a provider promise with a field observation?

Method for this question

Trace inbound mail from the domain’s MX records to the receiving hostnames. Record each MX preference, resolve the target to A and AAAA, check whether the target is reachable and identify which provider owns the endpoint. Then inspect outbound authentication separately: MX does not tell a sender which server may send mail. During a migration, write the old and new MX set, the overlap plan, mailbox creation status and the intended final TTL. Test a real message in both directions only after confirming that test accounts and content are safe.

What to record

• MX hostname and preference
• A or AAAA resolution for the target
• provider migration overlap
• SPF and DKIM sending identity

An MX failure can be delegation, target resolution, transport or mailbox policy. Query the authoritative and recursive views, verify that the MX target is not a CNAME where the provider forbids it, and check preference ordering. Use SMTP response codes to distinguish a connection problem from an unknown mailbox, quota or policy rejection. If only some senders fail, compare their resolver cache and IPv6 path. Check SPF, DKIM and DMARC for outbound symptoms, but do not add them to the inbound diagnosis unless headers show an authentication failure.

A realistic failure pattern

During a move from one mail provider to another, the new MX record is published first but only half of the mailboxes exist. Some senders follow the new preference and receive an unknown-user rejection while cached senders still reach the old system. A safer cutover provisions accounts, confirms forwarding or migration, keeps the old service available for the documented overlap and monitors both queues. After the cache window, remove the old MX and test inbound, outbound, aliases and password recovery addresses.

Errors and boundaries

MX priority is not a load-balancing score and a higher preference number is not the primary route. Multiple MX targets can create fallback behavior, but they do not synchronize mailboxes. Do not point MX at a web hostname merely because it resolves, and do not assume changing MX configures SMTP authentication. TTL affects cache timing but cannot repair a missing mailbox. IANA records the DNS parameter vocabulary; the mail provider’s current migration and transport policy controls the practical details.

What this does not prove

MX records do not configure outbound authentication and do not explain every mailbox rejection.

The Domain Host USA desk uses the documented fact, field observation, provider statement and editorial recommendation labels so readers can see what kind of sentence they are reading.

This note connects to the Infrastructure Field Desk, where the sample method and dated observations remain visible. Continue through Email & Deliverability for related decisions rather than treating one check as a complete review.