Skip to content
HomeAboutProjectsBlogContactHire Me
Back to Blog
DNS & Networking11 min read

MX Record Setup Troubleshooting: 7 Errors Fixed (2026)

Email bouncing or delayed? Walk through the seven most common MX record mistakes support tickets reveal, with symptoms, root causes, and exact fixes for each.

Written by Abdul AbrorTechnical Hosting Support Engineer
MX Record Setup Troubleshooting: 7 Errors Fixed (2026)
On this page

Email stopped flowing after you changed MX records? You're not alone. In support tickets I handled, most inbound mail problems trace back to a handful of repeatable DNS mistakes—wrong priority values, trailing dot errors, or stale cache sitting between your fix and the world.

This guide walks through seven real-world MX record setup errors. For each you'll see the symptom, the root cause, and the exact fix.

Error 1: Missing trailing dot causes mail loops

Symptom: Mail clients time out or you see bounce messages mentioning "too many hops" or "loop detected." Sending works fine; receiving fails.

Root cause: You entered your mail server hostname without a trailing dot in the DNS zone file. Many zone editors treat entries without a dot as relative to the zone origin, so mail.example.com becomes mail.example.com.example.com—which doesn't exist. The MX lookup fails and some senders retry against the domain itself, creating a loop.

The fix:

If you're editing the zone file directly (Bind-style), always append a dot:

example.com.  IN  MX  10  mail.example.com.

If you're in cPanel's Zone Editor or another GUI, check whether the interface adds the dot automatically. Most do. Test by querying the live DNS:

dig +short MX example.com

You should see 10 mail.example.com. with the trailing dot in the output. If you see mail.example.com.example.com, delete the record and recreate it correctly.

Error 2: Identical priority values break round-robin assumptions

Symptom: Only one mail server receives traffic even though you published multiple MX records with the same priority. Or worse, mail bounces intermittently because senders pick the wrong host.

Root cause: MX priority is not a load-balancer hint; it's a preference order. When two records share the same priority, RFC 5321 says the sender may randomize, but many MTAs simply pick the first one returned by DNS—and DNS response order is not guaranteed.

If one of those hosts is a backup that can't relay, half your mail will fail.

The fix:

Assign distinct priorities. Lower numbers mean higher preference:

example.com.  IN  MX  10  mail1.example.com.
example.com.  IN  MX  20  mail2.example.com.

mail1 will handle all inbound traffic unless it's down; then mail2 takes over. If you truly want round-robin load distribution, put that logic inside a single hostname (mail.example.com) backed by multiple A records, and point one MX entry at it.

Error 3: MX points to a CNAME instead of an A record

Symptom: Some senders deliver mail; others bounce with "MX lookup error" or "CNAME not allowed." Deliverability is inconsistent.

Root cause: RFC 2181 and RFC 5321 explicitly forbid CNAME records as MX targets. While a few lenient MTAs will follow the CNAME chain anyway, standards-compliant servers reject the message outright.

The fix:

Change your MX record to point directly at an A (or AAAA) record:

; Wrong:
example.com.       IN  MX  10  mailserver.example.com.
mailserver.example.com.  IN  CNAME  server45.hosting.example.

; Right:
example.com.       IN  MX  10  server45.hosting.example.
server45.hosting.example.  IN  A  203.0.113.50

If your mail provider gave you a CNAME target, ask them for the underlying A record hostname or IP. Most reputable hosts publish a dedicated MX hostname precisely to avoid this problem.

Error 4: TTL set too high delays propagation after a move

Symptom: You updated the MX record hours ago, but some senders still deliver to the old server. Logs on the new server are silent.

Root cause: DNS resolvers cache records for the duration of the TTL (time-to-live). If your MX had a TTL of 86400 seconds (24 hours) before the change, every resolver that queried it in the last day will keep using the stale answer until the TTL expires.

The fix:

Before you migrate mail servers, lower the TTL to something short—300 seconds (5 minutes) is common:

example.com.  300  IN  MX  10  old-mail.example.com.

Wait at least one full cycle of the old TTL. Then update the MX record to point at the new server:

example.com.  300  IN  MX  10  new-mail.example.com.

After the migration settles (a day or two), raise the TTL back to 3600 or 7200 to reduce query load. I've seen migrations go sideways because someone skipped the pre-lowering step and mail trickled into the old server for 48 hours.

Error 5: No A record exists for the MX hostname

Symptom: dig MX returns your record, but mail bounces with "Host not found" or "Name resolution failed."

Root cause: The MX record itself is valid, but the hostname it points to has no A or AAAA record. Senders can't find an IP address to connect to.

The fix:

Verify the A record exists:

dig +short A mail.example.com

If it returns nothing, create the A record:

mail.example.com.  IN  A  203.0.113.50

Then confirm the full chain:

dig +short MX example.com
dig +short A mail.example.com

Both should return answers. This mistake happens when you set up the MX in one DNS panel (maybe your domain registrar) but forget to add the A record in the same place.

Error 6: Old MX records still published alongside new ones

Symptom: Mail arrives at both the new server and an old server you decommissioned. Or worse, the old server rejects mail and senders treat that as a permanent failure.

Root cause: You added the new MX record but never deleted the old one. DNS returns all published MX records, and senders will try them in priority order. If the old record has a better (lower) priority, it gets tried first.

The fix:

List all current MX records:

dig MX example.com

Delete every record except the one (or two) you intend to keep. In cPanel's Zone Editor, click the trash icon next to obsolete entries. In a Bind zone file, remove the lines entirely and increment the serial number:

example.com.  IN  MX  10  new-mail.example.com.
; Deleted: example.com.  IN  MX  10  old-mail.example.com.

Reload the zone (rndc reload example.com) and verify:

dig +short MX example.com @your-nameserver-ip

You should see only the active record.

Error 7: Firewall blocks port 25 on the target server

Symptom: MX lookup succeeds, DNS is perfect, but senders time out or return "Connection refused" when attempting delivery. Your own outbound mail works fine.

Root cause: The server's firewall (iptables, firewalld, cloud security group) doesn't allow inbound TCP port 25. Many hosting providers block it by default to prevent spam relay abuse.

The fix:

First, confirm the MX record points to the right IP:

dig +short MX example.com
dig +short A mail.example.com

Then test port 25 from an external machine:

telnet mail.example.com 25

or

nc -zv mail.example.com 25

If it hangs or refuses, check your firewall rules. On a server running firewalld:

sudo firewall-cmd --list-all
sudo firewall-cmd --permanent --add-service=smtp
sudo firewall-cmd --reload

For iptables:

sudo iptables -A INPUT -p tcp --dport 25 -j ACCEPT
sudo service iptables save

If you're on AWS, Azure, or another cloud, open port 25 in the instance's security group or network ACL. Some providers (AWS EC2, for example) throttle or block port 25 on new accounts; you may need to request removal of that limitation through a support case.

After opening the port, test again:

telnet mail.example.com 25

You should see an SMTP banner like 220 mail.example.com ESMTP Postfix.

What about SPF, DKIM, and DMARC?

MX records control where inbound mail is delivered. They don't authenticate that you sent the outbound message. That's the job of SPF, DKIM, and DMARC records.

If senders report your mail is landing in spam even though MX delivery works, check those records next. But fix the MX setup first—without it, you won't receive replies at all.

Testing MX changes before you commit

Before you update a live MX record, test the new server in isolation:

  1. Add a temporary subdomain MX (like test.example.com) pointing to the new server.
  2. Send a test message to [email protected] from an external account.
  3. Check the new server's mail log (/var/log/maillog or /var/log/mail.log) to confirm receipt.
  4. Only after success, update the primary domain's MX.

This isolates DNS mistakes from mail server configuration mistakes.

What to check first

When inbound mail stops working, verify these in order:

  1. Run dig MX yourdomain.com and confirm the record exists and points to the correct hostname.
  2. Run dig A on that hostname and confirm it resolves to your mail server's IP.
  3. Test port 25 with telnet or netcat from outside your network.
  4. Check the mail server's logs for rejected connections or configuration errors.
  5. Confirm SPF/DKIM/DMARC if delivery succeeds but messages land in spam.

Most MX problems live in the first three steps. Fix DNS, open the port, and you're back online.

FAQ

How long does an MX record change take to propagate?

Up to the TTL value at the time of the previous query. If your TTL was 3600 seconds, expect up to one hour. Resolvers that haven't cached it yet will see the change immediately.

Can I have more than two MX records?

Yes. You can publish as many as you need, each with a unique priority. Common patterns: one primary, one backup. Enterprises sometimes use three or four for redundancy across data centers.

Do I need an MX record if I only send email?

No, but you should publish one anyway—even if it points to a blackhole server that rejects everything. Without an MX, senders fall back to the A record, and you'll receive backscatter and bounce loops.

Why does dig show the MX but mail still fails?

DNS propagation isn't the only step. Check the A record for the MX target, verify port 25 is open, confirm the mail server daemon (Postfix, Exim) is running, and review the mail server's own logs for rejection reasons.

Can I point an MX at an IP address directly?

No. MX records must point to a hostname (A or AAAA record). If you try to enter an IP, most DNS editors will reject it. If you bypass validation, RFC-compliant servers will refuse it.

Related articles