How to Find MX Record for Domain: Step-by-Step Guide

Do not index

Emails that once reached the inbox can suddenly bounce, disappear into spam, or trigger SMTP errors after a mail platform migration. A domain can look healthy in an email dashboard while its DNS still sends inbound mail toward an old or unreachable provider.

To find the MX record for a domain, query the domain's MX records with dig or nslookup, then resolve every returned mail host to an A or AAAA record. The lowest preference number is tried first, and every MX hostname must resolve to a usable destination before the configuration can be trusted for delivery. Microsoft's domain guidance also distinguishes between the terms preference and priority, which DNS providers may use interchangeably.

Table of Contents

Why Emails Bounce or Reach Spam Why the lookup belongs in a deliverability investigation How to Find MX Record Using Command Line Tools Run the two-part verification Query the authoritative server when answers disagree Understanding MX Record Output and Preference Values Using Online MX Lookup Tools and Their Limitations Use the browser result as evidence, not a verdict MX Records and Email Authentication Integration Compare the four pillars Common Mistakes and Troubleshooting Mixed Providers Compare the actual state with the intended state A focused troubleshooting checklist Frequently asked questions What does an MX record do?Is a lower MX preference better?Can a domain have multiple MX records?Why does an online lookup disagree with the DNS control panel?Does a valid MX record guarantee inbox placement?

Why Emails Bounce or Reach Spam

A campaign suddenly loses inbox placement after a mail migration. Transactional messages begin bouncing, customers stop receiving replies, and the team discovers that DNS still points inbound mail to the previous provider. The symptoms look like a copy, subject line, or reputation problem, but the first diagnostic question is more basic: where does DNS tell other mail servers to deliver email for the domain?

An MX record identifies the hostname responsible for accepting inbound mail. Its preference value sets the order in which sending servers should try multiple destinations. Internet standards define MX as a DNS resource record for mail routing, replacing older MD and MF designs because those methods handled caching and delivery routing less efficiently. This MX record reference provides the relevant historical and technical context.

Why the lookup belongs in a deliverability investigation

A missing MX record leaves a domain unreachable for inbound mail. A stale entry can route messages to a decommissioned provider, while mixed records can send different delivery attempts to separate systems. The result may be bounces, delays, failed replies, and uncertainty about which platform controls the mailbox.

Provider migrations create a less obvious trap. Google Workspace expects one active mail provider for the domain, so leaving old MX destinations alongside the new configuration can produce inconsistent routing or prevent the cutover from behaving as intended. Remove obsolete destinations, verify the published records, and confirm that the intended provider is the only receiving system before testing delivery.

An MX lookup does not prove that outbound messages will reach the inbox. SPF, DKIM, DMARC, sender reputation, message behavior, and recipient engagement still influence filtering. A broken receiving path can also disrupt bounce handling and domain operations before spam filters assess the message.

For related guidance, review these email authentication tips for STRs. The broader email deliverability guide explains how inbox placement depends on systems operating alongside DNS.

How to Find MX Record Using Command Line Tools

Command-line queries expose the DNS answer without a web interface interpreting it. That visibility matters during an incident, a provider migration, or a disagreement between an email service and the DNS control panel. The terminal also lets you repeat the same check from different resolvers and compare results.

Run the two-part verification

Step 1, query MX records. If dig is available, run:

dig MX example.com

Use this alternative when nslookup is installed instead:

nslookup -type=mx example.com

The response should show one or more MX entries, each with a preference value and a mail exchanger hostname. That hostname is not an IP address. Resolve it separately before treating the route as usable. DNS resource record documentation explains that domains can publish multiple MX records and that senders process them by priority.

Step 2, resolve every returned hostname. Run an A and AAAA query for each destination:

dig A mail.example.com
dig AAAA mail.example.com

An MX record can be present while its destination has no usable address. That failure leaves the receiving path unavailable, regardless of the preference value.

Query the authoritative server when answers disagree

Cached responses can make a migration appear incomplete. Query the authoritative name server when a record looks stale or different resolvers return conflicting answers:

dig @ns1.provider.com example.com MX

Replace ns1.provider.com with an authoritative server listed for the domain's DNS delegation. MX lookup guidance covers this direct-query pattern alongside common command-line DNS checks.

Provider cutovers need extra care. Google Workspace expects a single active mail provider, so an old destination left beside the new one can make the published configuration ambiguous during testing. Use the authoritative response to confirm that only the intended receiving provider remains, then resolve each returned hostname. A command-line result gives you the records currently published. It does not confirm that every mailbox, routing rule, or migration setting is correct.

Understanding MX Record Output and Preference Values

Read the returned fields in context. A typical answer looks like this:

example.com.    MX    10    mail.example.com.

example.com. is the queried domain, MX identifies the record type, 10 is the preference value, and mail.example.com. is the destination hostname. The preference is a 16-bit value ranging from 0 to 65535, as described in this MX record technical reference. Lower values indicate a preferred destination when the DNS response includes different values. The DNS documentation explains how receiving systems use that ordering.

The number alone does not confirm that delivery will work. Read the hostname as the actual routing target, then check whether it belongs to the provider you intend to use. During a migration, an old destination can remain published beside the new service. Google Workspace, for example, enforces a single active mail provider, so a leftover exchanger can create an invalid or ambiguous cutover rather than a safe fallback.

A misleading response might look like this:

example.com.    MX    10    old-mail.example.net.

If that hostname belongs to the former provider, mail can continue routing away from the current platform. If it has no usable DNS address, the destination cannot accept connections. The preference value is functioning correctly in both cases. The configuration problem is the selected hostname.

The MX hostname then undergoes further DNS resolution before SMTP delivery. This RFC 1035-based MX explanation shows why interpreting the visible line requires checking the destination's operational status, not just its numeric value.

Using Online MX Lookup Tools and Their Limitations

Browser-based lookup tools are convenient for a quick sanity check. They can present MX entries in a readable format, sort preference values, and make obvious errors easier to spot for people who don't work in a terminal every day.

Convenience becomes a liability when the lookup is treated as authoritative. Many online checks rely on recursive resolvers, and those resolvers may still hold cached data after a DNS change. During a migration, a browser result can therefore show the previous provider while an authoritative query shows the newly published records, or the reverse.

Use the browser result as evidence, not a verdict

A useful online workflow is:

Confirm the domain: Check the exact root domain rather than a sending subdomain by assumption.

Review every MX entry: Look for old provider destinations, unexpected hosts, and inconsistent preference values.

Resolve the hosts: Verify that each returned hostname has a usable A or AAAA response.

Compare with the provider record: Treat the provider's required hostname list as the configuration target.

Escalate discrepancies: Query authoritative DNS before changing records during an active incident.

MX correctness also needs to line up with SPF, DKIM, and DMARC. A visual checker may confirm that MX exists while missing an unauthorized sending source, a broken DKIM selector, or a DMARC policy that doesn't align with the actual sender. Those gaps can still influence how Gmail, Outlook, and Yahoo handle messages, so a clean browser result isn't a deliverability clearance.

MX Records and Email Authentication Integration

An MX record determines where a domain receives mail. SPF identifies permitted sending sources, DKIM adds a cryptographic signature, and DMARC checks authentication results against the visible From domain. These records perform separate functions, but they must describe the same mail architecture.

During a provider migration, changing the outbound platform while leaving older DNS records in place creates conflicting signals. The receiving path may point to one service, while SPF still authorizes a previous sender, DKIM still uses an obsolete selector, or DMARC alignment reflects an identity the organization no longer sends from.

Compare the four pillars

Record Type	Role in Deliverability	Dependency on MX Records
MX	Directs inbound mail to an accepting hostname	The hostname must resolve to a usable destination
SPF	Lists authorized sending sources	It may reference DNS mechanisms, but it does not replace MX routing
DKIM	Authenticates a message signature through a selector	It operates independently of inbound routing, but must match the active sender
DMARC	Applies policy and alignment logic to authenticated mail	It evaluates SPF and DKIM results, not MX preference order

MX records control receiving mail, not the validity of outbound authentication. A domain can have correct MX entries and still send messages without valid SPF, DKIM, or DMARC alignment. The reverse also occurs: authentication can look well configured while replies fail because the receiving destination is stale or no longer monitored.

Provider-specific rules make migrations harder. Some hosted mail systems expect one active provider configuration and reject the practice of retaining legacy MX destinations alongside the new setup. Before changing DNS, identify the provider's intended inbound records, authorized sending sources, DKIM selectors, and DMARC policy. Treat those requirements as one configuration rather than independent checkboxes.

Teams should authenticate their sending domain as a coordinated change. Test that inbound mail reaches the intended destination, outbound sources match SPF, DKIM signatures validate, and DMARC alignment reflects the actual sending identity.

A clean MX lookup alone does not confirm deliverability. Unrelated or outdated authentication records can still contribute to rejected messages, spam placement, and interrupted product notifications, support replies, or purchase communications.

Common Mistakes and Troubleshooting Mixed Providers

The most damaging MX error often appears after a migration. A domain publishes the new provider's records but retains destinations from the former provider. Sending systems can then route messages toward infrastructure the team no longer monitors, producing delays, rejects, or silent delivery failures.

Migrations to providers that enforce a strict single-provider MX set require particular care. Their current setup documentation requires five MX records, instructs administrators to remove unrelated MX records, and requires old entries to be replaced rather than combined with the new configuration. The provider setup documentation describes this requirement.

Compare the actual state with the intended state

Mixed-provider state: The lookup returns hosts belonging to both the current and former mail systems. Messages may be deferred, rejected, or delivered to an unattended environment.

Clean provider state: The published records match the active provider's documented set, and each destination resolves correctly.

Single-record state: One MX record is not automatically an error. A single record can be valid, and its preference value is not wrong because it is not the lowest possible number. Domain configuration guidance notes that any preference value is acceptable when only one MX record exists.

A focused troubleshooting checklist

Check authoritative DNS: Cached answers can hide what the domain currently publishes. Query the authoritative nameservers directly, compare their responses with the resolver result, and confirm that the records match the intended provider. This separates a propagation or caching issue from an incorrect DNS zone.

Remove legacy destinations: Delete old MX entries that point to infrastructure no longer accepting or monitoring the domain. Do not retain a former provider as a precaution when the active provider requires a single-provider set.

Resolve every hostname: An MX target without a usable A or AAAA result cannot support reliable delivery. Check each listed hostname, not only the first destination returned.

Validate authentication afterward: Use MailAdept's free SPF checker to confirm that authorized sending sources still match the active setup. MX changes do not repair SPF, DKIM, or DMARC problems.

Monitor after cutover: Review DNS and sender infrastructure together. A correct MX record can become misleading after a later platform change, new sending source, or incomplete account migration.

Frequently asked questions

What does an MX record do?

It tells sending mail servers which hostname accepts email for a domain. That hostname must then resolve through DNS before delivery can proceed.

Is a lower MX preference better?

A lower preference number is tried first when multiple MX records exist. It indicates delivery priority, not a faster or more reputable server.

Can a domain have multiple MX records?

Yes. Multiple records let senders try destinations in priority order, provided every hostname is valid and intentionally configured.

Why does an online lookup disagree with the DNS control panel?

The result may come from a cached recursive resolver. Use the authoritative DNS check in the troubleshooting list to determine which records the domain currently publishes.

Does a valid MX record guarantee inbox placement?

No. MX governs mail routing. Inbox placement also depends on SPF, DKIM, DMARC, sender reputation, message behavior, and recipient engagement.

Finding an MX record is a precise routing diagnostic, not a complete deliverability program. Confirming the route and resolving every target exposes stale or unusable destinations. Mixed-provider records and disconnected authentication can still cause bounces, spam placement, lost conversions, and damaged brand trust.

MailAdept provides subscription-based email deliverability consulting with AI agents and human experts reviewing MX routing, SPF, DKIM, DMARC, reputation, and ongoing changes. Visit Mailadept to request a free deliverability audit.