How to Check MX Records for a Domain

An MX lookup checks which mail exchangers a domain publishes for inbound email. To run one, query the domain's MX record and inspect each returned hostname and preference value. Then confirm that the target hostnames resolve to addresses and match the email provider's current configuration. This is a fast way to catch a missing record or an outdated provider target after a migration. However, seeing an MX answer does not guarantee that a receiving system is online, accepts a particular mailbox, or delivers the message to the inbox. DNS is one important layer of mail routing, not the complete delivery system.

Read the preference values correctly

Each MX record includes a numeric preference and a mail-exchanger hostname. Lower values are preferred over higher ones, so the number is not a priority ranking where the largest wins. Multiple exchangers can provide backup or distribute responsibility. Mail transfer agents have retry behavior and can continue trying an alternate exchanger when a preferred host is unavailable. Do not remove a higher-numbered record merely because it looks less important without confirming the provider's design. Some services publish a single exchanger; others rely on a carefully ordered set of regional or backup systems.

Be precise about which domain you query. A company may use example.com for addresses while a subdomain handles a separate mail stream, or a product may use a delegated sending subdomain. Querying mail.example.com when recipients use @example.com can give an answer unrelated to the mailbox route. If no MX record is published, mail systems may apply fallback behavior involving the domain's address records, but that is not a substitute for verifying the intended provider setup. Follow the email host's documentation and use the exact domain associated with the recipient addresses.

Common MX lookup problems

A missing MX record may indicate that mail routing was never configured, that the wrong hostname was queried, or that a DNS migration omitted the record. A target that does not resolve can prevent delivery even when the MX record itself is syntactically present. An old provider's MX values can continue appearing in recursive lookups while cached responses expire. A typo in a target hostname or incorrect preference can route mail to the wrong service. Review the authoritative zone and the provider dashboard together, then compare public answers through a resolver that is not simply showing a cached panel preview.

• Check MX for the exact recipient domain.
• Compare every preference and target against provider instructions.
• Resolve each exchanger hostname and confirm the values are current.
• Inspect authoritative answers if recursive answers appear stale.
• Check SPF, DKIM, and DMARC separately for outbound authentication.

Verify routing after changes

Before changing MX, record the current configuration and identify which mailboxes and senders depend on it. Publish the replacement values exactly as supplied, including trailing-dot conventions where the DNS host requires them, and confirm the authoritative zone accepts the changes. After publication, run an MX query and resolve all targets. Send controlled test messages from an external provider to addresses that should receive mail, and inspect mail logs or provider diagnostics if delivery fails. Allow for TTLs and retry behavior; a change can take time to be used consistently across remote sending systems.

For the bigger email picture, read email DNS records and what MX records do. A DNS checker can help inspect the public MX answer, but only a real message test can verify the end-to-end route for a particular mailbox. Keep those checks separate and record their results; that makes it easier to tell whether a failure is caused by a DNS record, an exchanger, recipient policy, or a sender's authentication configuration.

Do not diagnose delivery from MX alone

An MX query checks the public routing instruction, but delivery has several later steps: the sending server resolves the exchanger hostname, opens a connection, negotiates transport security where configured, and the receiver applies mailbox, reputation, and policy rules. A valid MX set can point to a service that is temporarily unavailable, while a successful SMTP connection can still reject a recipient or classify the message as unwanted. If DNS looks right, collect the sending provider's delivery status, recipient-side rejection text, and server logs. These details identify whether the next issue is address resolution, network reachability, SMTP policy, mailbox existence, or spam filtering.