Introduction
Email remains one of the most critical communication channels for individuals, businesses and services. Yet one small DNS misconfiguration can render an address unreachable. If a sender reports that they get a “No MX record found” error or your test message vanishes into thin air, the DNS Mail Exchanger (MX) record is usually to blame.
What does “No MX record found” mean? In plain terms it means your domain lacks a special DNS record that tells the world which servers accept incoming mail for you. Without MX records (or with incorrect ones), other mail servers may revert to legacy fallbacks or give up completely. The result? Bounced messages, lost leads, failed password resets, delayed onboarding e‑mails and a tarnished professional image.
This article explores everything you need to know about MX records: how they work, why missing them hurts deliverability, how to diagnose problems using hands‑on commands, and how to fix them across popular DNS providers. We back our explanations with relevant excerpts from the Domain Name System (DNS) and Simple Mail Transfer Protocol (SMTP) standards. Whether you’re configuring your first domain or debugging edge cases in a complex infrastructure, this deep dive gives you actionable guidance.
MX Records 101
Before we troubleshoot, we need to understand what MX records are and how they fit into the DNS and SMTP ecosystem.
What is an MX record?
An MX record is a type of DNS resource record that specifies the mail exchange host(s) responsible for accepting e‑mail on behalf of a domain. According to RFC 1034, an MX record’s RDATA consists of a 16‑bit preference value followed by the host name of a mail exchange. The preference (often called priority) is a numeric weight; lower numbers are chosen before higher numbers. If multiple MX records share the same priority, sending servers should choose one at random to distribute load.Each record also has a Time to Live (TTL) – a value in seconds that tells resolvers how long to cache the response.
Why MX instead of A/AAAA or CNAME?
When a remote mail transfer agent (MTA) wants to deliver a message to [email protected], it must discover which server accepts mail for example.com. The process is defined in RFC 5321 §5.1: the MTA first queries the DNS for MX records. If one or more MX records exist, it chooses the target with the lowest preference and resolves its A (IPv4) or AAAA (IPv6) record(s). It connects to that host to deliver the message. Only if no MX records are present should the sender treat the domain as having an implicit MX pointing to itself and attempt delivery to the domain’s A/AAAA record(s). This fallback exists for backward compatibility but is considered risky and may be ignored by modern senders.
The standards strongly discourage pointing an MX record to a CNAME. RFC 2181 clarifies that “the domain name used as the value of an MX resource record must not be an alias (CNAME)”. Using a CNAME here can cause additional queries or failures, and some resolvers will treat it as an error. Always point MX records to an FQDN that resolves directly to an A or AAAA record.
Anatomy of an MX record
An MX record has several key fields:
| Field | Description |
|---|---|
| Name | The domain or subdomain for which the record applies (often @ for the apex domain). |
| Type | The DNS type, MX. |
| Preference | A 16-bit integer; lower means higher priority. |
| Target | The hostname of the mail server. Must not be an IP address or CNAME. |
| TTL | Time to Live in seconds; controls cache duration. |
An example set of MX records for example.com:
; Name TTL Class Type Pref Target example.com. 3600 IN MX 10 mail1.example.com. example.com. 3600 IN MX 20 mail2.example.com.
In this configuration, messages are delivered to mail1.example.com first. If that server is unreachable, senders will try mail2.example.com.
MX vs A/AAAA vs CNAME
| Record type | Purpose | Allowed as MX target? |
|---|---|---|
| A/AAAA | Maps a host name to an IPv4 (A) or IPv6 (AAAA) address. Used for web servers, API endpoints, etc. | Only the target of an MX record should resolve to A/AAAA; the MX itself must not be an A/AAAA record. |
| MX | Points to the host(s) that accept mail for a domain. Carries a priority value. | Yes – this is the record we’re defining. |
| CNAME | An alias that points one domain to another. | No – RFC 2181 prohibits using a CNAME as the data in an MX record. |
How SMTP discovers MX records – a lookup flow
When an MTA wants to deliver a message, it follows a deterministic process:
┌────────────┐ 1. Query MX records via DNS ┌────────────────────┐
│ Sender │ ───────────────────────────────────▶ │ DNS resolver │
└────────────┘ └────────────────────┘
│ 2. Receive MX list and preferences
▼
┌────────────────────┐
│ Choose lowest-pref │ 3. For each MX target in order, resolve its A/AAAA records.
│ (randomly among │
│ equals) │ 4. Attempt SMTP connection; if fails, try next.
└────────────────────┘
If there are no MX records, the MTA treats the domain as having an implicit MX record with preference 0 pointing to itself. It resolves the domain’s A/AAAA records and connects to that IP. Modern MTAs may skip this fallback entirely because it’s unreliable and not required by law; the next section examines this behaviour.
How Mail Delivery Behaves With and Without MX
Normal behaviour when MX records are present
- MX lookup: The sending MTA queries the DNS for MX records and receives a list of targets with preferences.
-
Sorting: It sorts the list by increasing preference value.
- If multiple MX records share the same preference, the selection is random to distribute load.
-
Target resolution: For each target in order, it queries the DNS for A/AAAA records.
- If none exist for a target, the MTA marks that target as unusable and moves to the next one.
-
Delivery attempt: It attempts an SMTP connection on TCP port 25 to the resolved IP.
- If the connection fails (timeout, refuse, TLS problems), it tries the next MX.
- If all fail, the message is deferred or bounced depending on the error.
Fallback behaviour when MX records are missing
RFC 5321 allows a fallback: if the domain has zero MX records, the sending MTA may treat it as if it has an implicit MX of priority 0 pointing to the domain itself. It then attempts to deliver mail to the A/AAAA records of the domain. This behaviour ensured backwards compatibility with hosts that existed before MX records were introduced. However, relying on this fallback is dangerous for several reasons:
Not all MTAs implement the fallback. Many modern sending services require an MX record and will bounce messages immediately. The RFC’s language is “SHOULD” rather than “MUST,” so the fallback is optional.
A/AAAA record may point to a web server. Without an MX, senders might connect to your web server’s IP on port 25. If there’s no mail server there, the connection fails or the web server inadvertently accepts mail, creating security risks.
No priority or redundancy. Without MX records you cannot specify multiple mail servers or control failover order.
Comparison: With MX vs Without MX fallback
| Scenario | RFC behaviour | Real-world implications |
|---|---|---|
| Proper MX records present | Sender MUST use the MX list, sorted by preference. Only fallback to A/AAAA if all MX targets are unusable. | Predictable delivery, ability to set redundancy and failover. |
| No MX records | Sender SHOULD treat domain as implicit MX pointing to itself (A/AAAA). | Some senders will attempt fallback; others will bounce. Domain cannot specify multiple mail servers or priorities. |
| Null MX (see Section 7) | Explicitly refuse mail by publishing an MX with a zero-length target “.”. | Senders MUST not attempt delivery; mail is rejected cleanly. |
Common “No MX record found” Error Messages & What They Mean
When MX records are missing or misconfigured, different tools and mail servers emit different error messages. Understanding them helps narrow down the cause. Below are common variants and where they come from:
| Error message | Emitted by / context | Likely cause & fix |
|---|---|---|
| “No MX records found for domain” | Command-line tools like dig or nslookup when querying a domain. | The domain lacks MX records. Add at least one MX pointing to a valid mail server. |
| “Host or domain name not found. Name service error for name=… type=MX” | Postfix logs (server trying to send mail). | DNS resolution failed; either the domain has no MX, or the resolver returned a transient error. Check domain’s DNS and retry. |
| “DNS query returned NXDOMAIN for MX” | DNS tools when the entire domain doesn’t exist. | The queried domain is not registered or has no zone file. Register the domain or fix the authoritative DNS. |
| “Could not connect after trying all MX records. type=mx” | SocketLabs or similar sending services when none of the MX targets accepted connections. | MX records exist but the servers are unreachable. Verify your mail server is running and accessible on port 25. |
| “Mail for <domain> loops back to myself” | Postfix misconfiguration when the mail server thinks it is authoritative for the domain but has no MX; it tries to deliver locally and fails. | Remove incorrect local_transport settings and ensure your domain’s MX points elsewhere. |
| “Relaying denied due to missing MX” | Recipient MTA rejects the message because it doesn’t handle mail for the domain. | The domain’s MX points to a server that isn’t configured to accept mail; fix your mail server or point MX to the correct provider. |
