MX records tell mail servers where to deliver email for your domain. Create an MX record pointing to your mail server hostname with a priority value (lower = preferred). For redundancy, add multiple MX records with different priorities—if the primary fails, senders try the backup. Always use hostnames in MX records, never IP addresses.
MX Records Explained: Setup, Priority, and Best Practices
What MX Records Do
MX (Mail Exchanger) records are DNS entries that tell the world where to send email for your domain. When someone sends mail to [email protected], their mail server:
- Queries DNS for
yourdomain.com MX - Gets a list of mail servers and priorities
- Tries to deliver to the highest-priority (lowest number) server
- Falls back to lower-priority servers if needed
Without MX records, email to your domain won't arrive. MX records are part of your broader DNS configuration for email.
MX Record Anatomy
yourdomain.com. IN MX 10 mail.yourdomain.com.
| Part | Meaning |
|---|---|
yourdomain.com. | The domain receiving mail |
IN | Internet class (always IN) |
MX | Record type |
10 | Priority (lower = preferred) |
mail.yourdomain.com. | Mail server hostname |
Important: The target must be a hostname with an A record, not an IP:
mail.yourdomain.com. IN A 192.0.2.10
Basic Setup
Single Server
Minimum viable configuration:
yourdomain.com. MX 10 mail.yourdomain.com.
mail.yourdomain.com. A 192.0.2.10
Works, but no redundancy. If your server goes down, mail bounces after retry period (typically 5 days).
Primary + Backup
Standard redundant setup:
yourdomain.com. MX 10 mail.yourdomain.com.
yourdomain.com. MX 20 backup.yourdomain.com.
mail.yourdomain.com. A 192.0.2.10
backup.yourdomain.com. A 192.0.2.20
Primary handles normal traffic. Backup catches mail if primary is down.
Load Balanced
Same priority = traffic splits between servers:
yourdomain.com. MX 10 mail1.yourdomain.com.
yourdomain.com. MX 10 mail2.yourdomain.com.
mail1.yourdomain.com. A 192.0.2.10
mail2.yourdomain.com. A 192.0.2.20
Each server gets roughly half the traffic. Not precise load balancing—senders pick randomly—but distributes load.
Practitioner note: Don't rely on equal-priority MX records for precise load balancing. Some senders always try the same server first (alphabetical hostname selection is common). For precise load balancing, use a load balancer in front of mail servers and point one MX record at it.
Common Configurations
Google Workspace
yourdomain.com. MX 1 ASPMX.L.GOOGLE.COM.
yourdomain.com. MX 5 ALT1.ASPMX.L.GOOGLE.COM.
yourdomain.com. MX 5 ALT2.ASPMX.L.GOOGLE.COM.
yourdomain.com. MX 10 ALT3.ASPMX.L.GOOGLE.COM.
yourdomain.com. MX 10 ALT4.ASPMX.L.GOOGLE.COM.
Google handles redundancy internally. These five records ensure traffic reaches Google's infrastructure.
Microsoft 365
yourdomain.com. MX 0 yourdomain-com.mail.protection.outlook.com.
Microsoft provides one MX per tenant. Replace yourdomain-com with your actual tenant domain (dashes for dots).
Self-Hosted with External Backup
yourdomain.com. MX 10 mail.yourdomain.com.
yourdomain.com. MX 20 backup.mailbackup.example.
Your server handles normal traffic. Third-party backup service catches mail when you're down.
Email Security Gateway
yourdomain.com. MX 10 inbound.securityservice.com.
Security gateway (Mimecast, Proofpoint, Barracuda) receives mail first, filters spam/malware, then forwards to your actual mail server.
DNS Provider Examples
Cloudflare
Type: MX
Name: @ (or yourdomain.com)
Mail server: mail.yourdomain.com
Priority: 10
TTL: Auto (or 1 hour)
AWS Route 53
Record name: yourdomain.com
Record type: MX
Value: 10 mail.yourdomain.com.
TTL: 300
GoDaddy
Type: MX
Host: @
Points to: mail.yourdomain.com
Priority: 10
TTL: 1 Hour
Verifying MX Records
Using dig
dig MX yourdomain.com +short
# Output:
# 10 mail.yourdomain.com.
# 20 backup.yourdomain.com.
Using nslookup
nslookup -type=mx yourdomain.com
Verify A Record for MX Target
dig A mail.yourdomain.com +short
# Output: 192.0.2.10
If this returns nothing, your MX record is useless.
Online Tools
- MXToolbox: mxtoolbox.com/MXLookup.aspx
- DNSChecker: dnschecker.org
- Google Admin Toolbox: toolbox.googleapps.com/apps/dig
Troubleshooting
No MX Records Found
dig MX yourdomain.com +short
# (empty output)
Causes:
- MX records not created
- Wrong domain in query (typo)
- DNS propagation not complete
- Domain expired
Fix: Add MX records in your DNS provider, wait for propagation.
MX Target Has No A Record
dig A mail.yourdomain.com +short
# (empty output)
Effect: Senders can't resolve the IP, mail bounces.
Fix: Add an A record for the MX hostname pointing to your server's IP.
Wrong Mail Server Receiving Mail
Multiple MX records but wrong one getting traffic.
Check priorities:
dig MX yourdomain.com
# If priority 20 is receiving before priority 10, your priority 10 server might be unreachable
Test primary server:
telnet mail.yourdomain.com 25
If connection refused, your primary MX is unreachable.
Practitioner note: The most common MX issue I see is forgetting the A record for the MX hostname. People add the MX record but forget that
mail.yourdomain.comalso needs to resolve to an IP. DNS tools show a valid MX but mail still fails because the hostname doesn't resolve.
Mail to Subdomain Not Working
MX records for yourdomain.com don't apply to sub.yourdomain.com.
Fix: Add separate MX records for each subdomain that receives mail:
sub.yourdomain.com. MX 10 mail.yourdomain.com.
Or use a wildcard (not recommended—too broad):
*.yourdomain.com. MX 10 mail.yourdomain.com.
Best Practices
Do:
- Use at least 2 MX records for redundancy
- Keep priority numbers spaced (10, 20, 50) to leave room for additions
- Test changes with dig/nslookup before relying on them
- Lower TTL before changes to speed up propagation
- Document your configuration for future reference
Don't:
- Use IP addresses in MX records (violates spec)
- Point MX to a CNAME (works in some cases but technically wrong)
- Forget the A record for MX hostname
- Use priority 0 (some implementations treat it oddly)
- Rely on single MX without redundancy
Migration Checklist
When changing mail servers:
- Lower TTL to 300-600 seconds 24-48 hours before migration
- Add new server as lower-priority MX (e.g., 30)
- Test delivery to new server
- Swap priorities - new server becomes primary (10)
- Monitor delivery for 24-48 hours
- Remove old server MX record
- Restore TTL to normal (3600-86400)
If you need help configuring MX records for a complex email setup or migrating between mail servers, schedule a consultation.
Sources
- RFC 5321: Simple Mail Transfer Protocol (Section 5.1 - MX)
- RFC 7505: A "Null MX" No Service Resource Record
- Google Workspace: Set up MX records
- Microsoft 365: DNS records for email
- Cloudflare: Managing DNS records
v1.0 · March 2026
Frequently Asked Questions
What is MX record priority?
Priority determines which server gets mail first. Lower numbers have higher priority—priority 10 is tried before priority 20. If priority 10 is unavailable, senders try 20. Equal priorities split traffic between servers for load balancing.
Can I point an MX record to an IP address?
No. MX records must point to hostnames (like mail.example.com). The hostname then needs an A record pointing to the IP address. This two-step requirement is part of the DNS specification.
How long do MX record changes take to propagate?
DNS propagation depends on the TTL (time to live). With a 1-hour TTL, most servers see changes within 1-4 hours. Some caching resolvers may take longer. Lower your TTL before making changes if timing is critical.
Do I need multiple MX records?
Not required, but strongly recommended. One MX record works, but if that server goes down, you lose all incoming mail until it recovers. Two or more MX records provide redundancy—backup servers catch mail when the primary fails.
What MX priority values should I use?
Use 10 for primary, 20 for secondary backup, 50 for tertiary. Leave gaps (don't use 1, 2, 3) so you can add servers in between later. Standard convention uses multiples of 10.
Want this handled for you?
Free 30-minute strategy call. Walk away with a plan either way.