Email stops arriving and panic sets in. You added MX records yesterday but messages bounce or vanish. The DNS propagated hours ago, yet nothing works.
I've seen the same seven mistakes wreck email delivery for hundreds of domains. Most are silent—your DNS query succeeds, your mail server runs fine, but the sending MTA picks the wrong target or gives up entirely. The fixes are small but specific.
Mistake 1: Missing the trailing dot
You enter mail.example.com as your MX target. Your DNS panel appends the zone name automatically, so the published record becomes mail.example.com.example.com. — a hostname that doesn't exist.
Why it breaks: DNS is hierarchical. A name without a trailing dot is relative to the current zone. If you're editing example.com and type mail.example.com, most panels interpret that as mail.example.com + .example.com. = mail.example.com.example.com.
The fix: Always add the trailing dot when you specify a fully qualified domain name.
example.com. IN MX 10 mail.example.com.
Or use the short form if your DNS panel understands context:
@ IN MX 10 mail
Check the published record with dig:
dig +short MX example.com
If you see doubled domain names, you forgot the dot.
Mistake 2: Pointing an MX record at a CNAME
Your mail server lives behind a load balancer. You create a CNAME mail.example.com → lb.cloudprovider.net, then point your MX at mail.example.com. Lookups fail intermittently.
Why it breaks: RFC 2181 and RFC 5321 forbid CNAME targets for MX records. Some resolvers tolerate it, others refuse. Sending MTAs may cache the broken lookup and reject all mail for hours.
The fix: MX records must point to A or AAAA records directly. If you need a CNAME for your mail server's web interface or IMAP hostname, use a different name:
example.com. IN MX 10 mx1.example.com.
mx1.example.com. IN A 198.51.100.50
mail.example.com. IN CNAME mx1.example.com.
The MX target is an A record. The CNAME is separate.
Mistake 3: Identical priority values
You run two mail servers for redundancy and assign both the same priority:
example.com. IN MX 10 mx1.example.com.
example.com. IN MX 10 mx2.example.com.
Mail arrives only at mx1. The second server sits idle.
Why it breaks: Equal priority means the sender should distribute load randomly or round-robin. Many MTAs pick the first record returned and never try the second unless it fails. If mx1 accepts the connection but silently drops mail, mx2 never sees traffic.
The fix: Use different priorities unless you truly want random distribution:
example.com. IN MX 10 mx1.example.com.
example.com. IN MX 20 mx2.example.com.
Now mx1 is primary, mx2 is backup. The sending MTA tries mx1 first, falls back to mx2 only if mx1 is unreachable.
Want actual load balancing? Put both servers behind a single A record with multiple IPs, then point one MX entry at it.
Mistake 4: Forgetting to remove old records
You migrate from an old mail provider to a new one. You add the new MX records but leave the old ones in place "just in case." Half your mail arrives at the old server, which rejects it because the mailboxes no longer exist there.
Why it breaks: Senders see multiple MX records and will try all of them. If the old record has lower priority, some MTAs deliver there first. If the old server responds with a 5xx error, the message bounces immediately instead of retrying the new server.
The fix: Delete the old MX records completely before changing the mail provider. Check every record:
dig MX example.com
If you see hostnames you don't recognize, remove them. A common pattern I see in tickets: someone adds Google Workspace MX records but forgets to delete the default cPanel MX entry pointing to the hosting server. Mail splits randomly.
Mistake 5: Setting priority to zero
You want your primary mail server to have the highest priority, so you set it to 0:
example.com. IN MX 0 mail.example.com.
Mail arrives, but some senders mark your domain as misconfigured.
Why it breaks: Priority 0 is technically valid, but older RFCs discouraged it and some MTAs treat it as a special case or configuration error. The risk is small but real—certain spam filters or strict corporate mail servers may defer or reject delivery.
The fix: Start priorities at 10 and increment by 10:
example.com. IN MX 10 mx1.example.com.
example.com. IN MX 20 mx2.example.com.
This spacing lets you insert an intermediate server later without renumbering everything.
Mistake 6: Publishing MX records that don't resolve
You copy MX records from documentation or a setup guide:
example.com. IN MX 10 mail.example.com.
But you never create the A record for mail.example.com. DNS queries for the MX succeed, but the subsequent A lookup fails. Senders see "Host not found" and bounce the message.
The fix: Every MX target must have a corresponding A or AAAA record. Check both:
dig +short MX example.com
dig +short A mail.example.com
If the second query returns nothing, add the A record. In cPanel's DNS Zone Editor, create:
- Type: A
- Name: mail.example.com.
- Address: your mail server's IP
For IPv6, add an AAAA record too.
Mistake 7: Not waiting for TTL expiration
You fix a broken MX record and test immediately. It still fails. You assume the fix didn't work and revert it.
Why it breaks: DNS records are cached for their TTL duration. If your old MX record had an 86400-second TTL (24 hours), resolvers and MTAs will keep using the cached value until it expires. Your fix is live at the authoritative nameservers, but the rest of the internet hasn't seen it yet.
The fix: Check the TTL on the old record before you change it:
dig MX example.com
Look at the TTL column (the number before IN). That's how many seconds remain in the cache. If you're planning a mail migration, lower the TTL to 300 (five minutes) a day in advance. Make the change. Wait five minutes. Then test.
To see what the authoritative server publishes right now, query it directly:
dig @ns1.yourdnshost.com MX example.com
If the authoritative answer is correct but dig (without @) still returns the old record, you're seeing a cached value. Wait it out or flush your local resolver cache.
What about reverse DNS and SPF?
They're not MX mistakes, but they do affect delivery. Make sure your mail server's IP has a PTR record pointing back to the hostname in your MX record. Add an SPF TXT record listing the same IPs:
example.com. IN TXT "v=spf1 mx -all"
That line says "accept mail from servers listed in our MX records, reject everything else." It won't fix MX lookup failures, but it stops spoofing and improves your reputation.
Testing the full chain
After you fix the records, test from an external mail server. Send a message to [email protected] from Gmail or Outlook and check the headers. Look for Received: lines that show which MX hostname the sender connected to.
Or use an MX lookup tool and SMTP test tool:
dig MX example.com
telnet mail.example.com 25
If the telnet connection succeeds and you see a 220 banner, the MX chain works.
Common questions
Can I use an IP address directly in an MX record?
No. MX records must point to hostnames, not IPs. Create an A record first, then point the MX at it.
How many MX records do I need?
One is enough if you accept downtime risk. Two provides redundancy. More than three is overkill for most domains.
Do MX records affect outbound mail?
No. MX records control where others send mail to your domain. Outbound delivery depends on your SMTP server's configuration and your SPF/DKIM records.
Why does nslookup show different results than dig?
nslookup queries your system's configured resolver, which may return cached data. dig can query authoritative nameservers directly with the @ flag.
What if I have no mail server?
Delete all MX records or publish a null MX (priority 0, target .) to signal that the domain doesn't accept mail. Senders will bounce messages immediately instead of retrying for days.
Verify every target hostname
Most MX failures come down to typos, relative versus absolute names, and stale cache assumptions. Check the trailing dot. Confirm the target hostname resolves to an IP. Use different priorities for primary and backup servers. Remove old records completely when you migrate.
Run dig MX yourdomain.com and dig A <each-mx-target> after every change. If both return results, the DNS side is correct. If mail still bounces, the problem is on the server itself—firewall rules, mailbox existence, or SMTP configuration. But you'll know the MX records aren't the culprit.