What can an MX and DNS lookup actually establish about an email destination, and what evidence do I need next?
An MX record is a routing signpost
An MX lookup answers a narrow question: which host names does DNS publish as mail exchangers for this recipient domain? An MX record names the domain’s mail-exchange host and a preference value; it is not a list of individual users. Lower preference numbers rank ahead of higher ones, and sending MTAs use that preference when selecting among available exchangers. [1][2] Think of the answer as a routing signpost, not a test of the destination’s users or policy.
To inspect example domains, try dig MX example.com +noall +answer or nslookup -type=MX example.net; these reserved documentation domains are command examples, not a promise of particular output. For a domain you are diagnosing, query its MX records, then resolve each returned exchange with dig A <exchange-host> +noall +answer and dig AAAA <exchange-host> +noall +answer (replace the placeholder with the returned host). Addresses identify possible network destinations; they do not prove that SMTP is reachable there or that a server will accept a message.
How the sender selects a route
A sending MTA normally queries the recipient domain’s MX records, orders exchangers by preference, and resolves an exchanger’s host name to IP addresses before attempting SMTP. Lower numeric preference is tried first; when multiple exchangers share a preference, the SMTP specification calls for randomizing their order absent a reason to favor one. The sender’s actual route can therefore depend on its resolver answer, connection outcomes, and retry behavior—not just the first line you see in a lookup. [2]
An empty MX answer is not automatically “this domain cannot receive mail.” Under SMTP’s implicit-MX rule, when no MX records exist, the sender can use the domain name itself as the mail exchanger and look up its addresses. A Null MX is different: a specific single MX record with preference zero and . as its target declares that the domain does not accept email. [2][3] Check the DNS response status as well as its answer section; a timeout or resolver error is not the same finding as a valid response with no MX data.
What DNS cannot identify
An MX record is published for a domain and points to an exchange host. It does not encode the recipient’s local-part, prove that a particular mailbox is provisioned, identify the person or organization controlling an account, or map delivery to Inbox, spam, archive, forwarding, or another folder. Even a successful lookup of the exchange host’s A or AAAA record says only that DNS returned address data for that host. [1]
This is why an MX answer is useful for tracing the intended domain-level route, but weak evidence for questions about a specific address. A company can use shared inbound infrastructure for many addresses or domains, and a recipient system can apply policy and mailbox handling after DNS routing. If the question is “does this address exist?” or “where did it land?”, ask for the SMTP transaction and recipient-side evidence appropriate to that question; an MX query alone cannot answer either one.
DNS resolution is not SMTP acceptance
DNS lookup and SMTP are separate steps. A DNS answer does not open a connection, exchange SMTP commands, or receive a server reply. A successful TCP connection or SMTP greeting is also narrower than message acceptance. In an SMTP transaction, a 250 after RCPT TO can acknowledge that recipient at that stage; some servers defer recipient checks until after message data. The final response after the data is the relevant evidence of whether that SMTP server accepted the message for processing. [2]
Keep the hops distinct: your sending service accepting a message into its own queue is local submission acceptance; it does not prove that the recipient’s MX has accepted it. A final success reply from a recipient-side SMTP server documents acceptance at that handoff, not the eventual folder or user-visible placement. Filtering, internal routing, quarantine, forwarding, storage, and client display happen beyond what the DNS answer can show. [2] Do not use “accepted,” “delivered,” and “in the inbox” as interchangeable status labels.
Set a confidence limit—and gather the next evidence
A lookup is a time- and vantage-specific observation. DNS records carry TTLs, and recursive resolvers can serve cached answers until those records expire; another resolver or the sending MTA may see a different answer during a change or because it uses a different DNS view. [4] Record when and where you queried, including the resolver and response status. Confidence is high that this resolver returned these records at that time; confidence is only provisional about which host a particular sender will reach, and zero about mailbox ownership or folder placement from DNS alone.
Treat DNS as one checkpoint in the trace, then compare it with the sending MTA’s delivery log and, when available, the recipient system’s message trace. Preserve the actual SMTP stage and complete reply text: a rejected RCPT TO, a temporary connection failure, and a final post-DATA success are different evidence. If an accepted message is not visible, investigate recipient-side routing and filtering rather than treating an MX record—or an earlier sender-side queue acknowledgment—as proof of inbox delivery.
Fictional example only — synthetic DNS snapshot, not a live lookup
Example only. No customer message, real mailbox or live account data is shown.
northstar.example. 300 IN MX 10 mx-a.northstar.example.northstar.example. 300 IN MX 20 mx-b.northstar.example.mx-a.northstar.example. 300 IN A 192.0.2.25The illustrative routing order places preference 10 ahead of 20, subject to the sender’s implementation and reachability. The documentation-only address and all records are fabricated. This snapshot says nothing about whether a particular Northstar mailbox exists, who owns it, whether SMTP would accept a message, or where an accepted message would appear.
What to check next
- 01Record the lookup time, queried domain and record type, resolver used, response code/status, complete answer, and TTL.
- 02List every MX host and preference; distinguish no MX records from an explicit Null MX and from timeout, SERVFAIL, or other lookup errors.
- 03Resolve each MX target to A and AAAA, and note which resolver supplied those answers; do not equate an address with SMTP reachability.
- 04Correlate the actual sending MTA’s logs with the recipient domain, time, chosen destination, connection result, SMTP stage, and full reply text.
- 05Separate sender-side queue acceptance, recipient-side final post-DATA acceptance, and recipient-side message trace or folder evidence; redact sensitive addresses and content when sharing records.
Check the source
Standards and provider documentation are linked beside the claims they support. Provider policies can change; check the current document before changing a live sending program.
- [1]RFC 1035 — Domain Names: Implementation and Specification, §3.3.9 MX record fields: preference value and exchange host name.
- [2]RFC 5321 — Simple Mail Transfer Protocol, especially §§4.1.1 and 5.1 SMTP mail routing, MX preference ordering, address resolution, implicit-MX behavior when MX records are absent, and replies during SMTP transactions including completion after DATA.
- [3]RFC 7505 — A “Null MX” No Service Resource Record for Domains That Accept No Mail The specific Null MX representation and its meaning: the domain declares that it does not accept email.
- [4]RFC 1034 — Domain Names: Concepts and Facilities DNS resolver/cache model and the role of TTL in how long resource records may be cached.