DNS MX Record Explained — Mail Exchange Configuration

An MX (Mail Exchange) record tells sending mail servers where to deliver email for your domain. When someone sends an email to user@example.com, the sender's mail server queries the DNS for MX records on example.com to find the responsible mail server. Without MX records, email delivery to your domain fails entirely.

MX records are one of the core DNS record types, and configuring them correctly is the first step toward reliable email.

How MX Records and Mail Routing Work

Email delivery follows a well-defined process driven by MX priority values:

1. A user sends an email to user@example.com
2. The sender's mail transfer agent (MTA) queries DNS for MX records at example.com
3. DNS returns one or more MX records, each with a priority (preference) value
4. The MTA tries the server with the lowest priority number first
5. If that server is unreachable, the MTA moves to the next highest priority
6. The chosen mail server accepts the message and delivers it to the user's mailbox

example.com.    3600    IN    MX    10 mail.example.com.
example.com.    3600    IN    MX    20 backup-mail.example.com.

In this configuration, mail.example.com (priority 10) receives all email under normal conditions. If it is down, senders automatically fall back to backup-mail.example.com (priority 20).

Tip: The priority number is relative, not absolute. Values of 1, 5, 10, or 100 all work -- what matters is which number is lowest. Using gaps like 10, 20, 30 leaves room to insert new servers later.

MX Record Syntax and Format

<name>    <TTL>    IN    MX    <priority>    <mail-server>

The mail server field must be a hostname that resolves to an A record or AAAA record. It must not be an IP address, and it should not be a CNAME.

Setting Up MX Records for Common Providers

Google Workspace

Google requires five MX records with specific priorities:

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

Google also requires TXT records for SPF and DKIM verification. See the SPF, DKIM, and DMARC guide for the complete setup.

Microsoft 365

Microsoft uses a single MX record with a tenant-specific hostname:

example.com.    3600    IN    MX    0   example-com.mail.protection.outlook.com.

Replace example-com with your actual tenant identifier (your domain with dots replaced by hyphens). You also need an SPF TXT record authorizing Microsoft's servers:

example.com.    3600    IN    TXT    "v=spf1 include:spf.protection.outlook.com -all"

Self-Hosted Mail Server

For a self-hosted setup, point MX records at hostnames you control, and make sure those hostnames have corresponding A and AAAA records:

; MX records
example.com.    3600    IN    MX    10  mail.example.com.
example.com.    3600    IN    MX    20  backup.example.com.
 
; A records for the mail servers
mail.example.com.      3600    IN    A     192.0.2.10
backup.example.com.    3600    IN    A     192.0.2.20
 
; PTR records are configured in reverse DNS -- see the PTR guide

Self-hosted mail also requires PTR (reverse DNS) records for deliverability. Without matching forward and reverse DNS, many receiving servers will reject your email.

Multiple MX Records and Failover

Priority-Based Failover

Using different priority values creates an ordered failover chain:

example.com.    3600    IN    MX    10  primary.mail.example.com.
example.com.    3600    IN    MX    20  secondary.mail.example.com.
example.com.    3600    IN    MX    30  tertiary.mail.example.com.

The sending MTA works through the list in priority order. If primary returns a temporary failure (4xx SMTP code), the sender retries with secondary. If all servers are unreachable, the sender queues the message and retries later (typically for up to 5 days).

Load Balancing with Equal Priority

When two or more MX records share the same priority, sending servers distribute traffic randomly among them:

example.com.    3600    IN    MX    10  mail1.example.com.
example.com.    3600    IN    MX    10  mail2.example.com.
example.com.    3600    IN    MX    10  mail3.example.com.

This provides both load balancing and redundancy. If one server goes down, the other two absorb the traffic.

Backup MX Servers

A backup MX (sometimes called a secondary or fallback MX) accepts and queues email when your primary server is unavailable, then forwards it once the primary recovers. This is configured simply by giving the backup a higher priority number:

example.com.    3600    IN    MX    10  mail.example.com.
example.com.    3600    IN    MX    100 backup.example.net.

Tip: If you use a third-party backup MX service, make sure it is configured to relay only to your primary server. An open backup MX can become a spam relay.

Null MX -- Rejecting Email (RFC 7505)

If a domain should never receive email, you can advertise a null MX record as defined in RFC 7505:

example.com.    3600    IN    MX    0   .

The single dot (.) as the mail server tells sending MTAs that this domain does not accept email. This is cleaner than simply having no MX record, because the absence of MX records causes senders to fall back to the A record (per RFC 5321), which may unintentionally accept connections.

Null MX is useful for:

• Domains used only for web hosting with no email
• Parked domains
• Subdomains that should not receive mail

Verifying MX Records with dig

Basic MX Lookup

dig MX example.com

Output:

;; ANSWER SECTION:
example.com.    3600    IN    MX    10 mail.example.com.
example.com.    3600    IN    MX    20 backup.example.com.

Query a Specific Nameserver

During DNS propagation or when troubleshooting, query the authoritative server directly:

dig MX example.com @ns1.dnscale.eu

Verify the Mail Server Has an A Record

An MX record is useless if the target hostname does not resolve:

dig A mail.example.com

If this returns NXDOMAIN or has no answer, email delivery will fail.

Check Reverse DNS for the Mail Server

Many receiving servers verify that the mail server's IP has a matching PTR record:

dig -x 192.0.2.10

The PTR should match the hostname in your MX record (e.g., mail.example.com).

Trace the Full Resolution Path

dig MX example.com +trace

This shows every step from root servers through to the final answer, which is helpful for diagnosing delegation or zone configuration issues.

Verify SPF Alongside MX

dig TXT example.com | grep spf

This confirms your SPF record exists and authorizes the correct mail servers.

MX Records and Email Authentication

MX records handle inbound email routing, but email authentication records protect your domain from outbound spoofing. A complete email DNS setup includes:

A minimal but complete email configuration:

; Inbound routing
example.com.    3600    IN    MX     10 mail.example.com.
 
; SPF -- only the MX host and the domain's A record may send
example.com.    3600    IN    TXT    "v=spf1 mx a -all"
 
; DMARC -- reject emails that fail authentication
_dmarc.example.com.    3600    IN    TXT    "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"
 
; DKIM -- configured per sending service (key published as TXT record)
selector1._domainkey.example.com.    3600    IN    TXT    "v=DKIM1; k=rsa; p=MIGf..."

Without these complementary records, your domain is vulnerable to spoofing, and your outbound email is more likely to land in spam folders. See the full SPF, DKIM, and DMARC guide for step-by-step instructions.

Common Mistakes

1. Pointing MX to a CNAME

RFC 2181 and RFC 5321 state that an MX record's target must not be a CNAME. While some resolvers tolerate this, many mail servers reject the lookup, causing delivery failures:

# WRONG -- MX target is a CNAME
example.com.    MX    10 mail.example.com.
mail.example.com.    CNAME    mailhost.provider.com.
 
# CORRECT -- MX target has an A record
example.com.    MX    10 mail.example.com.
mail.example.com.    A    192.0.2.10

2. Pointing MX to an IP Address

The MX record value must be a hostname, never an IP address:

# WRONG
example.com.    MX    10 192.0.2.10
 
# CORRECT
example.com.    MX    10 mail.example.com.

3. Missing A/AAAA Records for the Mail Server

If the hostname in your MX record does not have a corresponding A or AAAA record, email delivery fails. Always verify with dig A mail.example.com.

4. No Backup MX

Relying on a single MX record means a server outage stops all inbound email. Add at least one backup MX with a higher priority number.

5. Forgetting Reverse DNS

Most mail servers check that the sending IP resolves back to the mail server's hostname via a PTR record. Missing or mismatched reverse DNS is one of the top causes of email being flagged as spam.

6. Overly High TTL During Migration

When migrating email providers, lower the MX TTL to 300 seconds (5 minutes) at least 24 hours before the switch. This ensures that old MX records expire quickly from resolver caches once you update them. See TTL best practices for more guidance.

MX and Email Deliverability

Beyond correct MX configuration, deliverability depends on several DNS-related factors:

• SPF alignment -- your SPF TXT record must authorize every server that sends email on your behalf
• DKIM signing -- publish DKIM keys as TXT records under selector._domainkey.example.com
• DMARC policy -- a p=reject or p=quarantine DMARC policy tells receivers to enforce authentication
• PTR records -- forward-confirmed reverse DNS (FCrDNS) is essential for self-hosted mail
• IP reputation -- ensure your mail server IPs are not on blocklists

All of these work together with MX records to form a complete email DNS infrastructure.

Managing MX Records with DNScale

Using the Dashboard

1. Navigate to your zone in the DNScale dashboard
2. Click Add Record
3. Set Type to MX
4. Leave Name as @ for the apex domain
5. Enter the Priority (e.g., 10)
6. Enter the mail server hostname in Content
7. Set TTL (3600 is typical for stable configurations)
8. Click Create Record

Repeat for each MX record you need (primary, secondary, tertiary).

Using the API

# Primary MX
curl -X POST "https://api.dnscale.eu/v1/zones/{zone_id}/records" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "@",
    "type": "MX",
    "content": "mail.example.com",
    "ttl": 3600,
    "priority": 10
  }'
 
# Backup MX
curl -X POST "https://api.dnscale.eu/v1/zones/{zone_id}/records" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "@",
    "type": "MX",
    "content": "backup.example.com",
    "ttl": 3600,
    "priority": 20
  }'

Related Record Types

• A Record -- resolves the mail server hostname to an IPv4 address
• AAAA Record -- resolves the mail server hostname to an IPv6 address
• CNAME Record -- must not be used as an MX target
• TXT Record -- carries SPF, DKIM, and DMARC data
• PTR Record -- reverse DNS lookup for mail server IPs
• SRV Record -- service discovery for protocols like IMAP and SMTP submission

Conclusion

MX records are the foundation of email delivery for any domain. Correct configuration requires not just the MX records themselves, but supporting A/AAAA records for the mail server hostnames, reverse DNS, and email authentication records (SPF, DKIM, DMARC). Use priority-based failover with multiple MX records for redundancy, avoid pointing MX targets to CNAMEs, and always verify your configuration with dig before considering your email DNS complete.