What is an MX Record? DNS Mail Exchange Basics

What is an MX Record? The Postal Service of the Internet

Imagine you're sending a physical letter. You write an address on the envelope—let's say "1600 Pennsylvania Avenue, Washington, DC." But the postal service doesn't just look at that address. It first looks up which post office is responsible for delivering to that area. That post office then takes over and handles the final delivery.

An MX (Mail Exchange) record is the DNS equivalent of that "responsible post office." It's a specific type of DNS resource record that tells the world which mail servers are authorized to receive email messages for your domain.

When someone sends an email to user@yourdomain.com, the sending email server queries the DNS system for your domain's MX records. The DNS response contains a list of mail server hostnames (like mail.yourdomain.com or aspmx.l.google.com) along with priority values. The sending server then attempts to deliver the email to the highest-priority server on that list.

📬 Analogy: Think of your domain as a company headquarters. The MX record is like the mailroom address you give to the postal service. It doesn't matter if your actual desks are on different floors or buildings—the mailroom (MX record) handles incoming mail and routes it correctly.

The Anatomy of an MX Record

An MX record contains three essential components:

Host/Name: The domain name the record applies to (usually @ or yourdomain.com).
Priority/Preference: A number (usually 0-100) that determines which mail server to try first. Lower numbers have higher priority.
Exchange/Value: The fully qualified domain name (FQDN) of the mail server that accepts emails for your domain.

Example MX Record Entry:
yourdomain.com.  IN MX  10  mail.yourdomain.com.

In this example, yourdomain.com is the domain, 10 is the priority, and mail.yourdomain.com is the mail server that will receive emails.

⚠️ Critical Requirement: MX records must point to hostnames, NOT raw IP addresses. For example, use mail.yourdomain.com, not 192.168.1.100. Using raw IP addresses violates email RFC standards and causes delivery failures with strict mail servers.

How MX Routing Works: The Journey of an Email

Understanding the complete email delivery flow helps you troubleshoot problems and configure your DNS correctly. Here's what happens from the moment someone clicks "send" to when the email lands in your inbox.

Step-by-Step MX Resolution Process

Email composition: A user sends an email to john@yourcompany.com. Their email client (Gmail, Outlook, Apple Mail) passes the message to their outgoing mail server (SMTP server).
DNS query for MX records: The sending mail server performs a DNS lookup to find MX records for yourcompany.com. It asks the recursive DNS resolver (like your ISP's DNS or Google's 8.8.8.8) to find these records.
DNS resolution chain:
- The resolver checks its cache. If not found, it queries the root nameservers.
- Root servers point to the .com TLD (Top Level Domain) nameservers.
- .com nameservers point to your domain's authoritative nameservers (where your DNS records are hosted).
- Your authoritative nameservers return the MX records for your domain.
Priority sorting: The sending server receives the list of MX records and sorts them by priority (lowest number = highest priority). For example:
- Priority 10: mx1.yourcompany.com
- Priority 20: mx2.yourcompany.com
- Priority 30: mx3.yourcompany.com
A/AAAA record lookup: The sending server now needs to find the IP address of mx1.yourcompany.com. It performs another DNS lookup—this time for an A record (IPv4) or AAAA record (IPv6).
SMTP connection attempt: The sending server opens an SMTP connection to the IP address of mx1.yourcompany.com on port 25 (standard SMTP) or port 587 (submission).
Delivery or failover:
- If the connection succeeds, the sending server transfers the email message.
- If the connection fails (timeout, connection refused, or server error), the sending server moves to the next MX record in priority order (Priority 20, then 30, etc.).
Final delivery: The receiving mail server accepts the message, performs spam and virus checks, and delivers it to your mailbox or forwards it to your email provider.

What Happens When No MX Record Exists?

If your domain has no MX records, the sending mail server falls back to a legacy behavior defined in RFC 5321: it attempts to deliver directly to the A record of your domain (the IP address associated with yourdomain.com).

This fallback rarely works today because most domains don't run mail servers on their root domain's IP address. The result: email delivery fails, and senders receive a bounce message like "Host or domain name not found" or "Mail server not reachable."

Always configure at least one MX record for any domain that should receive email.

🔍 Troubleshooting Tip: Use our MX Lookup Tool to see exactly which MX records external senders see for your domain. The tool shows priorities, hostnames, and resolves them to IP addresses so you can verify every step of the delivery chain.

Understanding MX Priority: The Backup System You Didn't Know You Had

MX priority (also called preference value) is a number assigned to each MX record that determines the order in which mail servers are tried. The server with the lowest number has the highest priority and is attempted first.

How Priority Values Work in Practice

Consider this MX record configuration:

yourdomain.com.  IN MX  10  primary.mail.com
yourdomain.com.  IN MX  20  backup1.mail.com
yourdomain.com.  IN MX  30  backup2.mail.com

Here's what happens when someone sends you an email:

The sending server attempts to connect to primary.mail.com (Priority 10).
If primary.mail.com is online and accepts the connection, delivery happens immediately. The sending server never even looks at the backup servers.
If primary.mail.com is offline (connection timeout, server down, or network issue), the sending server waits for a configurable timeout period (typically 30-60 seconds) and then tries backup1.mail.com (Priority 20).
If backup1.mail.com also fails, it moves to backup2.mail.com (Priority 30).

Common Priority Schemes

Equal priorities (load balancing): Some email administrators assign the same priority to multiple servers (e.g., both Priority 10). Sending servers typically choose randomly among equal-priority servers, distributing the email load. However, not all sending servers implement this correctly, so equal priorities don't guarantee true load balancing.
Staggered priorities (failover): Using distinct priority values (10, 20, 30) creates a clear primary → backup → secondary backup chain. This is the most common and reliable configuration.
Single priority (no redundancy): Having only one MX record (e.g., only Priority 10) creates a single point of failure. If that server goes down, all email delivery fails until it recovers.

Recommended Priority Ranges by Use Case

Primary mail server: 0, 1, 5, or 10 (lowest number gets highest priority)
Secondary/backup server: 10, 20, or 25 (higher than primary but still low)
Tertiary/emergency backup: 30, 40, or 50
Email security gateways (Proofpoint, Mimecast): Usually 5-15
Low-priority backup (catch-all): 50-100

Avoid priority values above 100 unless you have a specific reason. Some older mail servers misinterpret high values or treat them as invalid.

The Backup Server Myth

Many administrators mistakenly believe that backup MX servers should be configured to queue emails when the primary is down. However, RFC 5321 discourages queuing on backup servers because:

Backup servers often don't have access to your user mailboxes.
Queued emails may be delayed indefinitely or lost if the backup server crashes.
Modern best practice is to have all MX records point to servers that can accept and deliver mail immediately (or forward to the correct destination).

Better approach: Use a cloud-based email security provider (like Google Workspace, Microsoft 365, Proofpoint, or Mimecast) as your primary MX. These services have global redundancy built in, so you don't need multiple MX records for failover.

🔄 Pro Tip: Use our MX Lookup Tool to test your failover configuration. The tool simulates primary server failure and shows whether your backup servers are properly configured and reachable.

MX Records vs Other DNS Record Types: Know the Difference

DNS includes many record types, each serving a different purpose. Understanding how MX differs from other records prevents configuration mistakes.

A/AAAA Records (Address Records)

What they do: Map a domain or subdomain to an IP address (IPv4 for A, IPv6 for AAAA).

How they relate to MX: MX records point to hostnames (like mail.yourdomain.com), and those hostnames must have A or AAAA records. Without A/AAAA records, MX records are useless because sending servers can't find the mail server's IP address.

Common mistake: Configuring MX to point directly to an IP address (violates RFC standards).

TXT Records (Text Records)

What they do: Hold human-readable or machine-readable text. Used for SPF (email authentication), DKIM, DMARC, and domain verification.

How they relate to MX: TXT records don't affect mail routing but are essential for email deliverability. SPF records authorize which servers can send email from your domain. Without proper SPF, your emails may go to spam even if MX is correct.

CNAME Records (Canonical Name Records)

What they do: Alias one domain name to another.

Important restriction: You cannot use CNAME records for the root domain (yourdomain.com) if you also need MX records. The root domain's CNAME would interfere with MX resolution. Use A records for the root domain instead.

NS Records (Nameserver Records)

What they do: Specify which DNS servers are authoritative for your domain.

How they relate to MX: NS records must be correct before any other DNS record works. If NS records point to the wrong DNS provider, your MX records won't be visible to the outside world.

Quick Reference Table

Record Type | Purpose                                      | Example
------------|----------------------------------------------|-------------------
MX          | Directs incoming email to mail servers       | 10 mail.yourdomain.com
A/AAAA      | Points domain to IP address for web/mail/etc  | 192.168.1.100
TXT         | Holds authentication and verification data    | "v=spf1 include:_spf.google.com ~all"
CNAME       | Aliases one domain to another                 | www.yourdomain.com → yourdomain.com
NS          | Identifies authoritative DNS servers          | ns1.dnsprovider.com

Common MX Record Use Cases and Configurations

Different organizations need different MX configurations. Here are the most common scenarios.

Use Case 1: Google Workspace (formerly G Suite)

Google Workspace is the most popular email hosting service. The MX records point to Google's global mail infrastructure:

yourdomain.com.  IN MX  1   aspmx.l.google.com
yourdomain.com.  IN MX  5   alt1.aspmx.l.google.com
yourdomain.com.  IN MX  5   alt2.aspmx.l.google.com
yourdomain.com.  IN MX  10  alt3.aspmx.l.google.com
yourdomain.com.  IN MX  10  alt4.aspmx.l.google.com

The priority 1 server is tried first. If unavailable, the two priority 5 servers are tried (randomly). If those also fail, priority 10 servers provide additional backup.

Use Case 2: Microsoft 365 (formerly Office 365)

yourdomain.com.  IN MX  0   yourdomain-com.mail.protection.outlook.com

Microsoft uses a single MX record pointing to their regional endpoint. Their infrastructure handles redundancy internally, so multiple MX records aren't necessary.

Use Case 3: Self-Hosted Email (Postfix, Exchange, etc.)

yourdomain.com.  IN MX  10  mail.yourdomain.com
yourdomain.com.  IN MX  20  backupmail.yourdomain.com
mail.yourdomain.com.     IN A    192.168.1.100
backupmail.yourdomain.com. IN A  192.168.1.200

You need both MX records (for routing) and A records (for IP resolution).

Use Case 4: Email Security Gateway (Proofpoint, Mimecast, etc.)

yourdomain.com.  IN MX  10  mx1.securityprovider.com
yourdomain.com.  IN MX  20  mx2.securityprovider.com
yourdomain.com.  IN MX  30  mail.yourdomain.com

Email first goes through the security gateway (spam filtering, malware scanning, DLP), then is forwarded to your internal mail server.

Use Case 5: Development/Testing Domain (No Email)

yourdomain.com.  IN MX  10  .  (Null MX)

A null MX record (represented by a period) explicitly tells senders that this domain does not accept email. This prevents accidental email sending to test domains and reduces bounce traffic.

MX Record Best Practices: Do's and Don'ts

Follow these best practices to ensure reliable email delivery and avoid common pitfalls.

Do: Always Have at Least Two MX Records

Even if you use a highly reliable provider like Google Workspace, follow their recommended multiple MX record configuration. Redundancy protects against network failures, DDoS attacks, and provider-specific outages.

Do: Set TTL (Time To Live) to 3600 Seconds (1 Hour) or Less

When you need to change MX records (e.g., switching email providers), a lower TTL ensures changes propagate quickly. Many DNS providers default to 3600 seconds for MX records, which is appropriate. Avoid 86400 (24 hours) unless you never plan to change providers.

Do: Keep Backup MX Servers at Lower Priorities (Higher Numbers)

Use a significant gap between primary and backup priorities (e.g., primary at 10, backup at 50). This ensures senders wait long enough for the primary to respond before falling back. A gap of 5-20 is common and effective.

Do: Regularly Test Your MX Configuration

Use our MX Lookup Tool weekly or monthly to verify your records are still correct and resolvable. DNS changes can happen accidentally (someone else with access modifies records) or through provider errors.

Don't: Use CNAME Records for the Root Domain with MX

DNS standards prohibit CNAME records at the root domain (yourdomain.com) if you also have MX records. The CNAME would override all other records, breaking email delivery. Use A records for the root domain instead.

Don't: Point MX to an IP Address

Always use hostnames. IP addresses change; hostnames are stable references. Additionally, RFC 5321 explicitly requires MX targets to be hostnames, not IP literals.

Don't: Forget to Update MX When Changing Email Providers

If you switch from Google Workspace to Microsoft 365, your old MX records will still point to Google. Update MX records BEFORE canceling your old service to avoid email loss during the transition.

Don't: Use MX Records That Point to Themselves (Loops)

Example of a loop: mail.yourdomain.com has an MX record pointing to mail.yourdomain.com. The sending server looks up mail.yourdomain.com, finds the same MX record, and loops indefinitely. Ensure your mail server's hostname resolves to an A record, not another MX record.

📌 Key Takeaway: MX records are the foundation of email delivery for your domain. They tell the world where to send your email. Configure them correctly with proper priorities, redundancy, and hostnames. Use our MX Lookup Tool to verify your configuration and troubleshoot any issues before they cause email delivery failures.