MX records tell SMTP clients where a domain receives mail. They do not, by themselves, authorize a service to send as that domain. A reliable receiving setup requires usable exchange hostnames, reachable SMTP endpoints and a plan for temporary failure, not merely a green MX lookup.
Interpret preference correctly
References: RFC 5321 §5.1, RFC 2181 §10.3.
Each MX record contains a numeric preference and an exchange hostname. Lower preference numbers are tried before higher numbers. When there is no clear reason to favor one equal-preference destination, RFC 5321 requires randomizing their order to spread load. Their order in a DNS answer is not a stable primary-server designation. All advertised routes should be intended and operational.
An exchange hostname must have usable A or AAAA records and must not be a CNAME. Do not put an IP literal in the MX exchange field. Resolve each exchange separately, then test the advertised SMTP service. An address answer alone cannot show whether the endpoint accepts mail for the recipient domain.
Distinguish absent, unusable and null MX
References: RFC 5321 §5.1, RFC 7505 §3.
SMTP has an implicit-MX rule when a successful lookup returns no MX records: it treats the domain itself as the target and looks for its address records. This is not permission to ignore broken explicit MX records and use the domain's website address instead. A temporary DNS error also differs from a definitive absence and normally leads to queueing and retry.
A null MX is an explicit statement that the domain accepts no mail: a single MX with preference zero and the root label as exchange, commonly displayed as 0 .. RFC 7505 says not to publish other MX records alongside it. No MX and null MX are therefore different configurations.
Work through routing fixtures
Synthetic fixture A has example.com. MX 10 mx1.example.com. and example.com. MX 20 mx2.example.com.. The first host has A 192.0.2.10; the second has A 192.0.2.20. Expected preference order is mx1 before mx2. A failed connection to mx1 can cause another permitted delivery attempt; it does not prove mx2 accepted the message.
Fixture B removes both MX records but leaves example.com. A 192.0.2.30. Under the implicit-MX rule, that address becomes the potential SMTP destination. Fixture C instead publishes only example.com. MX 0 .; expected interpretation is that the domain accepts no mail. Fixture D retains A's MX records but removes both exchanges' addresses. Expected outcome is unusable explicit routes, not fallback to the apex A record.
Reproduce the DNS part in a lab by querying MX for each isolated fixture and A/AAAA for every returned exchange. Record the selected order and classification. Use a controlled SMTP server to test retry and acceptance if needed. The documentation addresses and described outcomes are illustrative, not production measurements.
Verify the business route
References: RFC 7208 §5.4, RFC 5321 §4.2.5.
Keep inbound routing separate from SPF policy. An SPF mx mechanism can explicitly make MX-associated addresses relevant to an SPF evaluation, but publishing MX alone does not create that authorization. Changing inbound providers may therefore also affect an existing SPF policy that uses mx and deserves a separate review.
During a migration, verify recipient provisioning, SMTP responses and transport security on all active exchanges before removing the old route. A backup exchange can accept spam or reject legitimate recipients if configured differently. Record who owns each endpoint and what evidence closes the change; do not equate SMTP acceptance with inbox placement or a human reading the message.
Captured isolated routing run
The retained historical capture, inspected for this review but not rerun, records that on 7 November 2026 at 20:34:42 UTC an executed loopback fixture returned the MX set 10 mx1.example.com. and 20 mx2.example.com. from 127.0.0.1 port 42125. A Python 3.12.14 client using dnspython 2.9.2 sorted these preferences. The explicit lab endpoint map sent mx1 to 127.0.0.1 port 45271 and mx2 to port 37481; this port map replaces public port-25 routing only within the fixture.
With both listeners running, mx1 returned 220, accepted EHLO with 250, accepted MAIL FROM and RCPT TO with 250, entered DATA with 354 and returned 250 synthetic message accepted; discarded locally. After closing only the primary listener, the next run recorded ConnectionRefusedError for mx1 and the same acceptance sequence at mx2. No external mail, real recipient or mailbox delivery was involved.
To reproduce, start two loopback SMTP fixtures, query the lab MX responder, map its exchange names to the listeners and send a harmless synthetic message with Python smtplib. Repeat after closing the primary. Retain the wire response, endpoint map, client/server transcript, timestamps and tool versions. The captured fixture uses a deliberately small SMTP server and demonstrates preference-driven retry only; it is not a conformance test of a production MTA or evidence of production failover.
Keep the evidence scope explicit
The archived transcript confirms only the loopback fixture behavior described above, including its custom port mapping and local discard. The source capture and harness are retained unchanged; this review did not repeat SMTP traffic or infer production failover from the historical test.