Your domain's MX records are the GPS coordinates for email delivery. When someone sends mail to your domain, their mail server queries DNS to find which server should receive it. Get this wrong and email vanishes into the void—no bounce, no delivery, no trace.
I'll show you how to set up MX records that work in production, starting from absolute zero.
What is an MX record?
MX stands for Mail eXchange. It's a DNS record type that points your domain to one or more mail servers.
Here's what a basic MX record contains:
- Host or Name: usually
@(representing your domain) or a subdomain likemail.example.com - Record Type: MX
- Priority: a number (lower = higher priority)
- Value or Points To: the hostname of your mail server, like
mail.example.comoraspmx.l.google.com - TTL: Time To Live in seconds, how long DNS caches the record
When a sending server looks up [email protected], it finds the MX records for example.com and delivers to the server with the lowest priority number.
Why priority matters
The priority value determines delivery order. If you have two MX records—one with priority 10 and another with priority 20—the sending server tries the priority-10 server first.
This lets you configure a primary mail server and a backup. If your main server is down, mail queues at the backup until the primary comes online.
Here's the catch: equal priority values mean the sender picks randomly between them. That's useful for load balancing across multiple servers of equal importance, but most small setups want a clear primary-backup hierarchy.
Your first working MX record
Let's walk through the simplest production setup: one mail server, no backup yet.
You'll need:
- Access to your domain's DNS management panel (cPanel, Cloudflare, your registrar's dashboard, etc.)
- The hostname of your mail server
If you're using cPanel or a shared host, your mail server hostname is usually mail.yourdomain.com. If you're using Google Workspace or Microsoft 365, your provider gives you specific hostnames.
Step 1: Find your DNS zone editor
In cPanel, look for "Zone Editor" under the Domains section. In Cloudflare, go to the DNS tab for your domain. Other panels have similar names—DNS Management, DNS Records, Name Server Management.
Step 2: Add the MX record
Click "Add Record" or the equivalent button. Fill in:
- Name/Host:
@(this represents your root domain) - Type: MX
- Priority:
10 - Mail Server/Value:
mail.yourdomain.com(replace with your actual hostname) - TTL:
3600(one hour)
Save the record.
Step 3: Verify the A record exists
Your MX record points to a hostname, not an IP address. That hostname needs its own A record.
Check that mail.yourdomain.com has an A record pointing to your server's IP. If it doesn't, add one:
- Name/Host:
mail - Type: A
- Value: your server's IPv4 address
- TTL:
3600
Without this A record, the MX record is useless. The sending server looks up the MX, gets mail.yourdomain.com, then tries to resolve that and finds nothing.
Step 4: Test the setup
Wait a few minutes for DNS propagation (or up to an hour depending on your previous TTL). Then test from a terminal:
dig yourdomain.com MX +short
You should see:
10 mail.yourdomain.com.
If you see your old MX records or nothing, flush your local DNS cache and try again. On Linux:
sudo systemd-resolve --flush-caches
On macOS:
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
Production best practice 1: Always configure a backup MX
A single MX record is a single point of failure. Your primary mail server goes down, and incoming mail bounces immediately instead of queueing somewhere safe.
Add a second MX record with higher priority (remember, higher number = lower priority in delivery order):
- Name/Host:
@ - Type: MX
- Priority:
20 - Mail Server:
backup-mail.yourdomain.com - TTL:
3600
Your backup server should queue messages and retry delivery to the primary. Many hosting providers offer a backup MX service, or you can spin up a simple Postfix relay on a VPS.
In support tickets I handled, the usual reason people skipped backups was cost. But a $5/month VPS running Postfix as a relay is cheaper than explaining to your boss why customer inquiries disappeared during a four-hour outage.
Production best practice 2: Use meaningful priority spacing
Don't set priorities like 10 and 11. Use 10 and 20, or 10 and 30.
Why? It gives you room to insert an intermediate server later without renumbering everything. If you start with 10 and 11, and later need to add a server between them, you're stuck editing all your records.
Common schemes:
- Primary: 10, Backup: 20
- Primary cluster: 10, 10, 10 (load balancing), Backup: 50
- Tiered: 10 (primary), 20 (secondary in same datacenter), 50 (remote backup)
Production best practice 3: Set appropriate TTL values
TTL (Time To Live) controls how long other DNS servers cache your record. A TTL of 3600 seconds (one hour) is standard.
Lower TTL (300 seconds / 5 minutes) if you're planning a migration or expecting to change mail servers soon. Higher TTL (86400 seconds / 24 hours) once your setup is stable reduces DNS query load.
Never set TTL below 300 seconds in production. Some mail servers ignore very short TTLs, and you're just hammering DNS resolvers for no reason.
Before a planned change, lower your TTL a day in advance. Change the records. Then raise TTL back up after the change settles.
Production best practice 4: Match your SPF record
SPF (Sender Policy Framework) is a TXT record that lists which servers are allowed to send email for your domain. If your MX records point to mail.yourdomain.com, your SPF record should include it.
A basic SPF record looks like:
v=spf1 mx ~all
The mx mechanism means "servers listed in my MX records are authorized." This keeps your SPF and MX aligned automatically.
If you use external senders (like a transactional email service), add them:
v=spf1 mx include:_spf.google.com ~all
Mismatched SPF and MX records are a red flag for spam filters. Your MX points to Server A, but your SPF only authorizes Server B? That's suspicious.
Production best practice 5: Don't point MX to a CNAME
This is against the DNS RFC and breaks at many mail servers.
Wrong:
- MX record:
mail.yourdomain.com(priority 10) mail.yourdomain.comis a CNAME toserver1.hosting.com
Right:
- MX record:
mail.yourdomain.com(priority 10) mail.yourdomain.comis an A record to192.0.2.10
If you need to point to a server you don't control, use the hostname directly in the MX record. For example, Google Workspace MX records point straight to aspmx.l.google.com, alt1.aspmx.l.google.com, etc.—no intermediate CNAME.
Production best practice 6: Avoid IP addresses in MX records
Some DNS panels let you put an IP address directly in an MX record. Don't.
MX records must point to hostnames, not IPs. If you absolutely must work around something broken, create an A record for a hostname first, then point the MX there.
Why does this matter? Mail servers expect to verify the hostname via reverse DNS (PTR records). Skipping the hostname breaks SPF checks, TLS certificate validation, and reverse DNS lookups.
Production best practice 7: Monitor your MX records
DNS records occasionally get overwritten by automation, panel glitches, or team members who didn't realize what they were changing.
Set up monitoring that queries your MX records daily and alerts you if they change unexpectedly. A simple cron job works:
#!/bin/bash
EXPECTED="10 mail.yourdomain.com."
CURRENT=$(dig +short yourdomain.com MX | head -n1)
if [ "$CURRENT" != "$EXPECTED" ]; then
echo "MX record changed! Expected: $EXPECTED, Got: $CURRENT" | mail -s "MX Alert" [email protected]
fi
Run it daily from cron. It's basic but catches the obvious disasters.
What about third-party email providers?
If you use Google Workspace, Microsoft 365, or another hosted email service, they give you specific MX records to configure. The process is the same—add each MX record they specify with the correct priority.
Google Workspace typically uses five MX records:
1 aspmx.l.google.com.
5 alt1.aspmx.l.google.com.
5 alt2.aspmx.l.google.com.
10 alt3.aspmx.l.google.com.
10 alt4.aspmx.l.google.com.
Notice the priority spread: one primary at 1, two secondaries at 5, two backups at 10. Copy the values exactly as provided. Don't try to "fix" them or use your own hostnames.
After adding third-party MX records, delete any old MX records pointing to your previous mail server. Leaving both active splits incoming mail between two systems.
Common mistakes that break email delivery
Forgetting the trailing dot: Some DNS systems require hostnames to end with a period (mail.yourdomain.com.). If you omit it, the system appends your domain again, creating mail.yourdomain.com.yourdomain.com. Check your DNS provider's docs.
Multiple MX records with the same priority pointing to different servers that don't sync: If priorities are equal, senders distribute mail randomly. That's fine for load balancing if all servers share the same mailbox storage. If they don't, users see mail sometimes on Server A, sometimes on Server B, and nothing syncs.
Pointing MX to a CDN or proxy: Cloudflare's orange-cloud proxy doesn't work for MX records. Always click the cloud to grey (DNS only) for your mail server's A record.
Setting TTL too high before a migration: If your TTL is 86400 (24 hours) and you suddenly change MX records, some mail servers will use the old cached records for a full day. Lower TTL at least 48 hours before the change.
How long does DNS propagation take?
Theory: TTL seconds. A 3600-second TTL means changes appear everywhere within an hour.
Reality: most resolvers respect TTL, but a few cache longer, and your local machine might have its own DNS cache.
Expect MX changes to take effect for most senders within an hour. Plan maintenance windows with a two-hour buffer to account for stragglers.
What to check when email stops arriving
Verify your MX records are correct with dig yourdomain.com MX. If they look fine, check that the A record for your mail server hostname resolves. Then check your mail server logs for rejected connections.
If everything looks right in DNS but mail isn't arriving, the issue is usually firewall rules, mail server configuration, or greylisting. MX records are just the first hop—they tell senders where to deliver, but the server has to actually accept the connection.
Get your MX records right once, monitor them, and you'll forget they exist until the next migration. That's the goal.