MX Record Check
Reads the live MX order, resolves exchanger addresses, and flags Null MX, CNAME, and dead-host routing risks.
Email SecurityPlanning MX Architecture: Preference, Capacity, and Safe Migration
MX is not a decorative DNS list. It is the failure plan that every remote sender executes without consulting you, so each preference, hostname, and supposedly redundant target must describe a route that can really accept the same mail.
Preference is failover, not a percentage
An MX preference is an ordering value: lower numbers are tried before higher ones. A pair such as 10 mx1.example.net. and 20 mx2.example.net. does not ask senders to deliver two thirds of the traffic to the first host. It tells them to prefer mx1 and use mx2 when the preferred route cannot be reached or temporarily refuses delivery. Exact retry schedules remain the sender's decision, so MX cannot promise an immediate or uniform failover.
Equal preferences are the DNS-level tool for coarse distribution. With two reachable exchangers at preference 10, senders may choose either; many randomize, but the standard does not give you a stable 50/50 load balancer. Capacity-plan every equal-priority host for skew and bursts, and make their filtering, recipient knowledge, queueing, and downstream relay behavior equivalent. The MX Record Check sorts the published set and resolves the first exchangers, which is the right first check for what remote MTAs are actually being told.
The backup MX that makes an outage worse
A higher-numbered backup is useful only if it is operated as a real receiver. It needs current recipient validation, comparable anti-abuse controls, sufficient queue storage, working onward delivery, and monitoring that proves mail can traverse the entire path. A hostname that accepts a TCP connection but cannot relay accepted messages is not redundancy; it is a delayed-loss machine. A dead backup is quieter still: nobody notices it during normal operation, then primary trouble sends traffic directly into the neglected branch.
The traditional weakly filtered backup is also a spam magnet. Attackers deliberately target the least-preferred MX because old deployments often trust it more, filter less, or accept every local part before forwarding to the primary. That creates backscatter, queue pressure, and a bypass around controls you paid to run on the main edge. If a provider cannot enforce the same recipient and abuse policy, remove the record. One healthy route with honest retry behavior is safer than ornamental redundancy.
Null MX: a deliberate refusal
A domain that never receives mail should say so explicitly with one record: example.com. MX 0 .. This Null MX declaration tells conforming senders that no SMTP service exists for the domain. It avoids pointless address fallback and repeated connection attempts, and it makes the administrative intent reviewable. It is appropriate for parked domains, non-mail infrastructure names, and dedicated sending domains whose design excludes replies.
Null MX cannot coexist meaningfully with ordinary exchangers. Publishing MX 0 . beside a real MX 10 mail.example.com. is contradictory, not a clever emergency switch. Nor should it be used merely because a mailbox platform is temporarily unavailable: senders may treat the statement as a permanent inability to accept mail and fail immediately. Before publishing it, inventory reply addresses, automated bounces, certificate contacts, and forgotten aliases. “We do not run inboxes” is not proof that nobody sends to the domain.
MX targets must be hosts, not aliases
An MX target must name a host with address records; pointing it at a CNAME is a standards violation. Some resolvers and MTAs follow the alias anyway, which is why the mistake survives testing. Others reject it, cache an awkward intermediate answer, or behave differently when the alias chain changes. That produces peer-specific failures: the worst kind, because successful delivery from one large provider appears to acquit the design.
Give each exchanger a stable canonical hostname with direct A and, if genuinely served, AAAA records. The names also become certificate identities, MTA-STS policy entries, TLSA owner names, logs, and monitoring keys; casual renaming therefore has a much larger blast radius than the MX RRset suggests. After DNS is sound, the SMTP TLS Handshake / Mail Domain Delivery Readiness can probe the first exchangers and compare STARTTLS certificates against those actual MX hostnames.
Migrate by adding paths, then removing them
The safest provider migration is an overlap, not a DNS flip. First provision every domain, recipient, alias, routing rule, size limit, and abuse policy on the new edge. Establish downstream delivery and test real messages in both directions. Then publish the new exchangers alongside the old ones, initially at a less-preferred value if the platform supports a clean pilot. This exercises fallback without making it the normal route. If policy layers name MX hosts, update and stage those before senders can encounter the new path.
Next make the new set preferred while retaining the old route long enough for DNS caches and queued remote mail to drain. Watch acceptance logs, queues, bounces, and TLS reports rather than assuming the TTL is the whole waiting period: a sender may have already queued mail against an older answer. Only then remove the old MX records, and keep the former service able to forward late arrivals for a bounded retirement window. Lowering TTL ahead of the change helps discovery; it does not flush caches already populated.
Design the dependencies as one object
Write down the intended MX set with owner, preference, address families, certificate names, capacity role, and policy coverage. Every production change should be checked against that model. An exchanger is not ready because DNS resolves: port 25 must answer, recipient policy must be correct, STARTTLS must present a usable identity, and any MTA-STS or DANE assertion must agree. Authentication records are a different layer; the SPF/DMARC/DKIM Checker helps inspect how accepted and outbound mail will be judged, but it cannot rescue broken inbound routing.
Finally, test failure rather than admiring redundancy on paper. Withdraw a preferred path during a controlled exercise, confirm that multiple external senders reach the remaining route, and trace accepted messages through final delivery. Alert on unreachable MX hosts, address drift, certificate renewal, queue depth, and policy mismatch. The practical invariant is simple: every hostname you publish is a promise to strangers. If you cannot continuously prove that promise, stop publishing it.