What an MX record does

An MX, or mail exchanger, record tells sending systems which host accepts mail for a domain. When a sender needs to deliver a message to user@example.com, the relevant mail system looks up the MX records for example.com and uses the resulting hostnames as delivery targets. MX records point to hostnames rather than IP addresses. Those hostnames are then resolved through A or AAAA records. This separation is useful because the mail destination can change its address without changing the domain's MX record.

MX priority

MX records include a preference value. Lower values are preferred over higher values, allowing a domain to publish multiple mail exchangers. If the preferred server is temporarily unavailable, a sending MTA can try another eligible destination according to SMTP delivery rules. Multiple MX records should represent intentional redundancy. Publishing several hosts that do not actually accept mail can create confusing delivery behavior. Every advertised MX target should therefore be tested independently.

Common MX mistakes

A common mistake is publishing an MX record that points directly to an IP address. Another is creating an MX hostname without a corresponding address record. Configuration errors can also arise when an old provider's MX record remains after migration, causing different senders to route mail to the wrong service. DNS caches can make changes appear inconsistent for a period of time. Before assuming that a resolver is broken, compare authoritative DNS data with the result returned by the resolver you are using.

How to troubleshoot MX

Start with the domain's authoritative nameservers and inspect the complete MX set. Confirm each target hostname resolves and that the destination accepts SMTP connections. Then inspect the receiving server's logs to determine whether the message reaches the expected host. If one provider reports that a domain has no mail exchanger while another sees an MX record, investigate DNS delegation, resolver caching and DNSSEC or nameserver configuration. The important point is to establish where the disagreement occurs.

MX and web hosting are different

An MX record does not determine where a website is hosted. A domain can point its website to one provider while its email is handled by a completely different service. Changing web hosting therefore does not automatically require changing MX records. This separation is useful during migrations. Keep a written inventory of DNS records and identify which records belong to the website, which belong to email, and which are used for authentication.

Pre-change checklist

Before changing MX records, record the current values and confirm the new provider's required targets. Lower the risk of downtime by preparing the new mail service before switching routing. After the change, test both inbound delivery and administrative access. Monitor the old and new systems during the transition where possible. A successful DNS lookup alone does not prove that the receiving service is correctly configured to accept and process mail.

Practical checklist

• Record the exact hostname, domain, IP address or SMTP response involved in the issue.
• Change one variable at a time and keep a short change log.
• Verify the result with a real test message and inspect the relevant DNS or SMTP evidence.
• Document the final configuration so the next migration or incident starts with known-good information.

Frequently asked questions

Is there one setting that guarantees successful delivery?

No. Email delivery depends on the complete sending path, including infrastructure, authentication, recipient policy, message handling and operational practices.

Should I change several settings at once when troubleshooting?

Usually no. Controlled changes make it easier to identify the cause and confirm whether the fix actually worked.