A customer says they never received your invoice. A prospective client replies that your address bounced. Before assuming the message was filtered as spam, troubleshoot MX record misconfiguration. An MX record controls where other mail systems send email addressed to your domain. If it is wrong, missing, or pointing to a retired service, your business may not receive mail at all.
The straight answer is this: confirm the mail server name, priority, and supporting DNS records against the settings supplied by your email provider. Then allow time for the corrected record to update. The details matter because one extra character or an old server name can send mail to the wrong place.
What an MX record does
MX stands for Mail Exchange. It is a record in your Domain Name System, or DNS, the public directory that connects domain names to internet services. When someone sends a message to you@yourdomain.com, their mail server looks up your domain's MX records. The results tell it which server should accept that message.
An MX record does not usually control where your employees send outgoing mail. It primarily controls inbound email for your domain. That distinction helps narrow the problem. If your team can send messages but cannot receive them, MX records are a likely place to check. If messages fail only when sent to a particular customer, the recipient's MX configuration may be the issue instead.
Each MX record has two key parts: a priority number and a mail server hostname. Lower numbers have higher priority. For example, a server with priority 10 is tried before one with priority 20. The hostname must resolve to an IP address through an A record or AAAA record. An A record maps a name to an IPv4 address, while an AAAA record maps it to an IPv6 address.
Signs you need to troubleshoot MX record misconfiguration
The most obvious sign is a bounce message stating that the destination domain has no mail exchanger, has no valid mail server, or could not be found. Senders may also receive timeouts when the listed server does not respond.
Other symptoms are less direct. New messages may stop arriving immediately after a website change, domain transfer, email provider migration, or DNS update. Some messages may arrive while others are delayed because different sending systems cache DNS results for different periods. Your staff might also receive messages at one address but not another if some mail is routed through an old service.
Do not treat every missing message as an MX problem. A message can be accepted by the correct server and then filtered, quarantined, or routed under a mailbox rule. Start with the sender's bounce notice, if one exists. It often identifies whether the failure occurred during DNS lookup, server connection, or later message processing.
Check the live MX records first
Begin with the DNS records published to the public internet, not just the records displayed in a registrar account. A domain registrar is where you registered the domain name. Your DNS host is the service currently answering DNS requests. They may be the same company, but often they are not.
Use an MX lookup tool to view the live records for your domain. Compare every result to the exact values in your current email provider's setup instructions. Check the hostname character by character. Common mistakes include using a former provider's server name, entering the wrong domain, or placing an address such as mail.yourdomain.com in the MX record without creating a valid A or AAAA record for it.
If you use a major hosted email provider, its required MX hostname is usually specific and must be entered exactly. Do not substitute the provider's website address, your login address, or an outbound SMTP server. SMTP stands for Simple Mail Transfer Protocol, the standard used to transfer email between systems. An SMTP submission setting used by your email application is not automatically a valid MX destination.
Verify priorities and duplicate entries
One correctly configured MX record is often enough. Some providers publish more than one for resilience. Follow their documented values rather than adding extra records from a previous setup "just in case." Old records can cause intermittent delivery, especially when the old server still answers connections but no longer has your mailboxes.
Priorities should also match the provider's instructions. A lower number means the server is preferred. If a retired server has priority 0 and the correct server has priority 10, many senders will try the retired server first.
Avoid using a CNAME record as an MX destination. A CNAME is an alias that points one hostname to another hostname. Mail standards do not permit an MX record to point to a CNAME. Some sending systems may tolerate it, but others may reject or mishandle the destination. Point the MX record to a hostname with a direct A or AAAA record instead.
Confirm the DNS zone you actually control
A correct edit in the wrong DNS zone changes nothing. This happens after a website move, a registrar transfer, or a switch to a security or content delivery service. The name servers assigned to your domain determine where the live DNS zone is hosted.
Check your domain's name server records, then sign in to the service managing those name servers. That is where the MX change must be made. If you update records at your registrar while your domain uses another DNS host, the public result will remain unchanged.
Also check for accidental conflicts. You should not have an MX record at the root of the domain and a competing forwarding or mail-routing feature enabled elsewhere. Some web hosting control panels offer mail routing options that can override local delivery behavior. If your email is hosted externally, make sure the web host is not configured to accept mail locally for the domain.
Test the destination behind the MX record
An MX record can look valid and still point to a server that cannot receive mail. After identifying the destination hostname, confirm that it resolves to an IP address and that the server accepts SMTP connections. Your IT team can use command-line DNS and SMTP tests for this. A diagnostic tool can check the same path without requiring you to interpret raw server responses.
The destination must be publicly reachable. A private network address, an expired server, a firewall blocking inbound SMTP, or a server configured for the wrong domain can all create failures after DNS lookup succeeds. These issues are more common when a business runs its own mail server or has recently changed hosting providers.
If your provider manages the mail infrastructure, do not try to replace its MX targets with IP addresses. Providers can change server infrastructure. Their hostname is the stable value they expect you to use.
Account for DNS update timing
DNS changes are not always visible everywhere at once. Records have a time to live, or TTL, which tells other systems how long they may cache a DNS answer. A low TTL generally means changes appear sooner, but it does not erase a record already stored in every sender's cache.
Check that the new value appears in public lookup results before testing again. If it does, give external senders time to refresh. If it does not, recheck the active DNS host and look for formatting errors. Some DNS dashboards automatically add your domain name to entries. Entering the full hostname in the wrong field can accidentally create a repeated name such as mail.example.com.example.com.
Know when no MX record is intentional
A domain that never receives email can publish a Null MX record, written as priority 0 with a single period as the destination. This explicitly tells senders not to attempt delivery. It is useful for domains reserved for web redirects or other non-email purposes.
It is not appropriate for the domain your business uses for employee or customer email. If you find a Null MX record unexpectedly, remove it and publish the correct provider-provided MX record.
Make the fix without creating a second problem
Before editing DNS, save a copy of the current records and confirm who manages your business email. Then replace only the MX records that conflict with the active provider's settings. Do not delete unrelated records such as website records or email authentication records.
Email authentication records serve different jobs. SPF, or Sender Policy Framework, identifies servers permitted to send for your domain. DKIM, or DomainKeys Identified Mail, adds a signed identifier to messages. DMARC, or Domain-based Message Authentication, Reporting, and Conformance, tells receiving systems how to handle authentication failures. They can affect trust and filtering, but they do not replace MX records.
After the DNS update, test delivery from an independent external address and review any bounce response. Test both a standard mailbox and a shared address such as billing@ or appointments@ if your business uses them. This confirms the corrected route reaches the mail platform and the intended recipient address exists.
If the fix requires access to DNS hosting, server firewalls, or mail-routing settings you do not manage, ask the responsible provider or administrator to make the change. Give them the live MX lookup result, the required value from your email provider, and the exact bounce text. That turns a vague "email is down" report into an actionable request.
For a plain-language view of your domain's MX records and related email health issues, run MailArrive's free email health check and review your Report Card before making further DNS changes.