To inspect a domain’s published mail-routing records on Windows, query its MX record type with nslookup. Use the domain after the recipient’s @ sign, not the whole email address and not automatically the company’s www website. An MX answer identifies mail-exchanger names returned by the queried DNS server; it does not prove that a mailbox exists or that a message was accepted or delivered.
This is a narrow evidence-gathering check for a domain you administer or are authorised to troubleshoot. It does not change Windows DNS settings, send a test email, or log into a mail server. Keep the original bounce message or delivery report because it may explain a problem that a DNS lookup cannot.
Choose the right domain and query type
For the illustrative address reader@example.com, the recipient domain is example.com. Do not query reader@example.com as though it were a hostname. Likewise, the MX records for www.example.com are not automatically the same question as the MX records for example.com.
Microsoft documents A as the default resource-record type for nslookup, while MX selects mail-exchanger records. A plain hostname lookup is therefore not a substitute for explicitly asking the mail-routing question. Use a trailing period to make the example domain name fully qualified rather than letting a local search suffix alter the intended name.
Open Command Prompt on Windows and replace the example domain below with the domain you are authorised to investigate:
nslookup -type=MX example.com.The example is a command pattern, not a promise that example.com offers email service. Read the actual result on your machine. Record the queried domain, the DNS server shown at the beginning of the output, the time of the check, and the returned records or exact error.
Read the answer separately from the resolver heading
The initial Server and Address details identify the DNS resolver answering your request. They are not, just by appearing first, the destination domain’s mail server. Look for the answer associated with the domain you queried and the mail-exchanger names returned for it.
MX results can include more than one exchanger and a preference value. RFC 5321 explains that lower preference numbers are more preferred than higher numbers. A preference is a routing-order input, not a measurement of server health, delivery speed, or trustworthiness. Do not remove a higher-numbered entry just because it looks secondary.
If you need an interactive comparison of record types using the same nslookup session, enter these lines one at a time:
nslookup
set type=MX
example.com.
set type=A
example.com.
exitThe second lookup asks a different DNS question. Different answers are not automatically a contradiction. The exit line returns you to the ordinary command prompt; set type here affects the query tool’s session, not your Windows adapter configuration.
Do not turn an MX response into a delivery verdict
A returned exchanger name does not establish whether the SMTP service is reachable, whether it accepts a particular recipient, whether an account is suspended, or whether a message entered a spam folder. RFC 5321 distinguishes routing and the later SMTP conversation, including acceptance and rejection. Preserve the actual delivery-status information rather than declaring email healthy after a successful lookup.
Similarly, no MX answer is not by itself a universal verdict that a domain cannot receive mail. SMTP has rules concerning implicit MX handling when the relevant conditions are met, and administrators also need to interpret deliberately configured no-mail policies correctly. Escalate with the exact DNS result instead of making a blanket claim from an empty-looking screen.
Handle failures without resetting useful evidence
- Timeout: the selected resolver did not answer within the lookup’s retry and timeout behaviour. That is not proof that the recipient mailbox is absent.
- Nonexistent domain: check the exact spelling and domain from the recipient address before escalating the result.
- No records: Microsoft distinguishes a valid name without records of the requested type from a nonexistent domain.
- Server failure or refusal: preserve the message and resolver identity; these are not successful negative answers about a recipient account.
Do not start by flushing caches, replacing DNS servers, or editing the domain’s records. If local resolution history matters, first follow the separate guide to inspecting the Windows DNS cache before clearing evidence. That cache inspection is complementary evidence, not a replacement for querying MX records.
Final support checklist
Keep the original recipient domain, requested record type, resolver, timestamp, complete answer, and original mail error together. Redact personal addresses and internal infrastructure details before sharing outside the support team. If DNS records require a correction, have the authorised domain or email administrator confirm the intended values and change plan; this read-only walkthrough makes no record changes and needs no configuration rollback.
Sources: Microsoft’s nslookup syntax and error meanings; record-type selection; RFC 5321, especially mail routing in section 5.
Educational-use notice: Test procedures carefully before production use. The site owner is not responsible for misuse, damage, data loss, or production issues. Documentation-backed syntax is not evidence that your mail service has been tested successfully.
