The Definition and Structural Syntax of MX Records
An MX record is a DNS record that maps a domain name to the hostname of one or more mail servers responsible for accepting inbound email for that domain. Unlike A records (which resolve to an IP address) or CNAME records (which alias to another hostname), an MX record resolves to a mail server hostname — and that hostname must itself have an A or AAAA record pointing to an IP. This two-step process allows for high flexibility, such as moving your email hosting to a new server by simply updating the underlying A record while leaving the MX record untouched.
MX records exist strictly at the domain level for which they are configured. To receive email at user@example.com, the MX record must be configured at example.com. To receive email at user@subdomain.example.com, a separate MX record must exist at subdomain.example.com — the parent domain's MX records do not cascade down to subdomains. This is a common pitfall for organizations launching new marketing or community subdomains that require their own unique email routing identity.
; MX record format
; domain TTL class type priority mail-server-hostname
example.com. 3600 IN MX 10 mail1.example.com.
example.com. 3600 IN MX 20 mail2.example.com.
The mail server hostname at the end of an MX record must be a fully qualified domain name (FQDN) with a trailing dot in zone file notation. It must resolve to an A or AAAA record. It must not be a CNAME — RFC 2181 and RFC 5321 both prohibit MX records from pointing to CNAME targets to prevent infinite loops and excessive DNS lookups that can degrade SMTP performance.
Every domain that needs to receive email must have at least one MX record. A domain with no MX record will cause sending mail servers to fall back to trying the A record. This behavior is unpredictable and considered a misconfiguration in any production environment. As shown in the syntax above, multiple records are typically used to provide redundancy, ensuring that even if one server goes offline, your email queue will find an alternate path for delivery.
How SMTP and Priority Values Control Email Delivery
When a sending mail server (MTAs) needs to deliver a message to recipient@example.com, it enters a highly organized sequence of lookups. The protocol used, SMTP, relies on the priority values assigned to your MX records to decide which server to attempt first. This mechanism allows you to designate primary servers and backup servers in a clear, deterministic hierarchy.
-
MX Lookup: The sending server queries for
MX example.com. It receives a list of records, each containing a priority number and a hostname. -
Priority Sorting: The sender sorts these records by the priority value. Here, a lower number equals a higher priority. A record with priority 1 is tried before a record with priority 10.
-
Hostname Resolution: The sender resolves the hostname of the top-priority record into an IP address using a standard A or AAAA lookup.
-
SMTP Connection: The sender attempts a TCP connection to that IP on port 25. If the connection fails or the server returns a temporary error, the sender moves to the next highest priority record in the list.
The priority value (also called "preference") is a non-negative integer. If multiple MX records have the same priority number, the sending server will distribute delivery attempts randomly among them. This effectively acts as a load-balancing mechanism. Many enterprise providers, like Google Workspace, use this to distribute incoming traffic across their massive edge networks.
| Priority | Hostname | Function |
|---|---|---|
1 | aspmx.l.google.com | Primary destination for all traffic |
5 | alt1.aspmx.l.google.com | Redundant backup; load-balanced with alt2 |
10 | alt3.aspmx.l.google.com | Emergency tertiary backup; used only if others fail |
Relative priority values are arbitrary. Using 10 and 20 vs 1 and 2 has no impact on delivery behavior; only the numerical relationship between them matters. Most administrators use intervals of 10 to allow room for inserting new servers in the future without renumbering the entire set. If a sending server exhausts all your listed MX hosts without success, it will typically queue the message locally and retry for several days before bouncing the message back to the sender as undeliverable.
Industry Standard Configurations and Security Integration
Different email providers have standardized their MX record requirements to ensure maximum uptime. Google Workspace requires five distinct MX records, utilizing a tiered priority structure to ensure that no single outage can disrupt your inbound mail. In contrast, Microsoft 365 typically uses a single MX record with a unique tenant hostname. Under the hood, Microsoft's single hostname uses Anycast routing to handle redundancy, so you only need to manage one DNS entry.
| Provider | Typical Record Count | Primary Priority |
|---|---|---|
| Google Workspace | 5 Records | 1 |
| Microsoft 365 | 1 Record | 0 |
| Self-Hosted | 2-3 Records | 10 |
MX records and email authentication (SPF, DKIM, DMARC) are separate but closely integrated components of your "Email Posture." A common misconception is that your MX servers are automatically authorized to send email just because they are in the MX list. This is not true. Your SPF record must explicitly authorize any server that sends mail from your domain, which may or may not be the same server listed in your MX record.
; Example SPF record that includes MX servers manually
v=spf1 mx include:_spf.google.com ~all
When you use an Email Security Gateway (like Mimecast or Proofpoint), your MX records should point to the gateway's hostnames, not your actual mail server. The gateway acts as a "buffer," scrubbing mail for spam and malware before forwarding the clean messages to your internal infrastructure. If you leave your original mail server open to the internet, spammers can bypass your gateway entirely by connecting directly to your IP—a vulnerability known as "MX bypass."
💡 Tip: Always restrict port 25 on your internal mail server so that it only accepts incoming connections from your security gateway's specific IP addresses. This closes the "back door" that spammers use to bypass your filters.
Verification Methods and Operational Validation Checklist
Validating MX records is a multi-step process that involves checking the records themselves, their underlying IP addresses, and the actual responsiveness of the servers. Using the dig command-line tool is the industry standard for this task because it provides raw, un-cached data directly from the nameservers.
# Query MX records and their priorities
dig MX example.com +short
# Verify the A record for the primary MX hostname
dig A aspmx.l.google.com +short
# Query your authoritative nameserver directly to bypass any cache
dig MX example.com @ns1.yourprovider.com
Once the records are verified at the DNS level, you must ensure they point to a live, listening SMTP service. You can use the telnet or nc command to connect to the MX host on port 25. A successful connection will return a "220" greeting banner from the mail server. If the connection times out, your MX record is effectively pointing to a "dead" destination, and no email can be received.
Use the checklist below to audit your configuration after any hosting change or migration.
- MX records exist exactly at the domain level (check
dig MX yourdomain.com). - No MX record targets are CNAMEs (this violates RFC 2181).
- Every MX hostname resolves to a valid A or AAAA record (check the IP).
- Priority values match your provider's documentation exactly.
- Old MX records from previous providers have been removed entirely.
- If using an inbound gateway, traffic is restricted to only the gateway's IPs.
- SPF record is updated to match your current sending requirements.
💡 Tip: For a global view across dozens of regions simultaneously, our MX Record Lookup tool can identify "regional lag" where some parts of the world are still seeing old, cached MX data while others have updated.
Diagnostic Guide: Common Errors and Their Impact
Even a minor typo in an MX record can cause a catastrophic email outage. The most frequent error is pointing an MX record to an IP address instead of a hostname. MX records must point to a domain name (FQDN). If you put an IP address (e.g., 203.0.113.10) directly in the data field, many mail servers will consider the record invalid and refuse to even attempt delivery.
Split delivery is another critical issue that occurs during migrations. This happens when an administrator adds new MX records but forgets to delete the old ones. If the old and new records have the same priority, sending servers will alternate between them. Half your email will end up at your new provider, and the other half will rot or bounce at your old provider.
| Error Type | Visual Symptom | Technical Root Cause |
|---|---|---|
| NXDOMAIN | 550 Host Not Found | MX hostname has no underlying A record |
| CNAME Target | Intermittent Bounces | MX points to a CNAME (RFC violation) |
| Split Delivery | "Missing" Emails | Old and new MX records coexist with same priority |
| MX Bypass | Sudden Surge in Spam | Spammers connecting directly to IP instead of MX host |
Typos in hostnames are simple but deadly. If your MX points to msmx.l.google.com instead of aspmx.l.google.com, the lookup will return a "NXDOMAIN" error, and no mail server in the world can reach you. Always copy and paste your hostnames directly from your provider's dashboard to avoid manual entry errors.
Finally, be aware of stale cache issues during a migration. If your MX records had a TTL of 24 hours before you changed them, you must wait the full 24 hours before you can be certain that every sender is reaching the new server. This is why we recommend lowering your MX TTL to 300 seconds several days before a planned migration. This gives you high agility if something goes wrong and needs to be rolled back quickly.
Frequently Asked Questions
Q: What is the difference between MX records and A records for email?
The MX record is the "routing label"—it tells the internet which mail server hostnames are responsible for your domain. The A record is the "address locator"—it turns those hostnames into the actual IP addresses used for the connection. You need both to receive email correctly; one identifies the server, the other locates it.
Q: Do I need MX records to send email from my domain?
No, you only need MX records to receive email. However, without MX records, your outbound email will likely fail spam filters, as many receiving servers check for valid MX records as a basic legitimacy test. Furthermore, without an MX record, no one can reply to the emails you send.
Q: Can I have only one MX record for my domain?
Yes, it is perfectly valid to have just one MX record. Microsoft 365, for example, uses a single MX record for almost all customers. However, for self-hosted setups, having a single MX record creates a single point of failure; if your server goes down, all incoming mail will immediately begin to queue at the sender's end.
Q: My MX records are correct, but I'm not getting any mail. What else could it be?
Check your server's firewall and listener settings. Even if DNS is perfect, if your server's port 25 is blocked or the mail service is crashed, the mail cannot be delivered. Also check for "MX record mismatches" where the NS records in your zone file point to different nameservers than the ones registered at your registrar.
Q: Why does my MX record use priority 10 instead of priority 1?
The specific number doesn't matter—only the relative order. Using 10, 20, and 30 is common because it allows you to insert a new server at priority 15 later if you need to, without reordering your entire list. It is purely a matter of administrative convenience and future-proofing.
Q: Can I use a CNAME for my mail server if I don't want to manage an IP?
No. RFC 2181 and RFC 5321 explicitly state that the target of an MX record must be a hostname with an address record (A or AAAA). Using a CNAME as an MX target is a violation of the protocol standards and will cause intermittent delivery failures from strict mail servers.
Next Steps
Use our MX Record Lookup tool to check your current MX configuration and verify each hostname resolves correctly. For a more detailed audit, run the Email Health Report to check MX alongside SPF, DKIM, and DMARC.
If you are planning a migration to a new email provider, see our DNS Migration Without Downtime guide for the complete cut-over sequence.
Browse all DNS guides on DNSnexus for related topics.