MX Records and Email Delivery Failures: How to Diagnose and Fix Them

When email stops working, MX records are almost always involved

An email bounces. A newly acquired domain stops receiving mail. A migration from one email provider to another goes smoothly except that some messages to a specific domain are still bouncing. A customer reports they can't reach your company by email.

In every case, the first diagnostic step is the same: look at the MX records. They tell you which mail servers are supposed to receive email for the domain, in what priority order — and whether the configuration matches what should be there.

---

How email delivery uses MX records

When a sending mail server wants to deliver email to recipient@example.com, it performs an MX lookup:

1. Query DNS for MX records on example.com
2. Get back a list of mail server hostnames with priority values
3. Attempt delivery to the lowest priority value (highest preference) server first
4. If the first server is unavailable, try the next priority
5. If all servers fail, queue the message and retry for up to 5 days
6. After 5 days, return a bounce (NDR — non-delivery report) to the sender

The key point: if MX records are wrong, missing, or pointing to unavailable servers, email delivery fails silently from the recipient's perspective — bounces go to the sender, not to you.

---

MX record structure

example.com.  IN  MX  10  mail1.example.com.
example.com.  IN  MX  20  mail2.example.com.
example.com.  IN  MX  30  backup.mail.example.com.

Priority numbers: lower = higher preference. The sending server tries priority 10 first. Priority 20 and 30 are fallbacks if the primary is unavailable.

The trailing dot: mail1.example.com. — the trailing dot means this is a fully qualified domain name (FQDN). DNS tools typically add this automatically; manually edited zone files need it.

MX targets must be A/AAAA records — never CNAME records. The RFC prohibits CNAME targets for MX records. Some DNS providers accept it and resolve the chain, but it's technically non-compliant and causes delivery failures with strict implementations.

---

Common MX configurations

Google Workspace

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

Google's mail infrastructure uses a specific set of servers. Verify against Google's admin documentation — the exact servers required for your account may vary.

Microsoft 365

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

Microsoft 365 uses a single MX record with a tenant-specific hostname and priority 0. Note: priority 0 is valid and means "highest preference" — lower than 1.

Migrating between providers

During an email migration, you might temporarily see two sets of MX records — the old and new providers. The priority determines which receives mail. Setting the new provider to a lower priority number (higher preference) while keeping the old server at a higher number provides a gradual cutover.

After confirming the new provider is working:

1. Remove the old MX records
2. Allow the previous TTL to expire before deleting (so any mail servers with the old records cached can use the new records)

---

Diagnosing delivery failures with MX records

Symptom: email to a domain bounces with "host not found" or "no MX records"

Check: MX lookup for the recipient's domain shows no records, or records pointing to a non-existent hostname.

Causes:

• The domain has expired and DNS has been removed
• MX records were accidentally deleted
• The domain was recently migrated and MX records weren't updated
• A typo in the MX target hostname

Fix: the domain owner needs to add or correct their MX records.

Symptom: mail is being delivered to the old email provider despite switching to a new one

Check: MX lookup still shows old provider's servers.

Causes:

• MX records weren't updated at the DNS level (common when multiple DNS providers are involved)
• MX changes haven't propagated (TTL still in effect)

Fix: check the DNS provider's admin panel directly — not just cached results. Use a DNS lookup tool that queries authoritative nameservers directly rather than relying on cached responses.

Symptom: some senders can deliver email, others can't

Check: what MX records different DNS resolvers are returning — is there inconsistency?

Causes:

• Incomplete DNS propagation after a recent change
• Different TTL cached values at different resolvers
• Split-horizon DNS serving different answers internally vs. externally

Fix: check from multiple DNS resolvers (8.8.8.8, 1.1.1.1, your ISP's). If results differ, wait for TTL to expire.

Symptom: email is delayed significantly but eventually arrives

Causes:

• Primary MX server is temporarily unavailable; sending servers are retrying on lower-priority backup MX
• The primary MX server is responding but slowly (connection timeouts)
• The primary MX is rejecting connections and forcing fallback to the backup

Fix: check that the primary MX server's A record is resolving correctly and the server is accepting connections on port 25.

---

MX lookup for custom domain email providers

When you set up a custom email domain with Google Workspace, Microsoft 365, Zoho, Fastmail, or similar services, you're always provided with MX records to add to your DNS. The MX lookup tool lets you verify these are in place before testing email delivery.

Verification checklist after adding MX records:

1. MX lookup returns the provider's servers ✓
2. Priority values match the provider's instructions ✓
3. No old MX records remaining from a previous provider ✓
4. MX targets resolve to valid A records ✓
5. Test email from an external account delivers successfully ✓

---

The "null MX" for non-email domains

RFC 7505 defines a "null MX" record for domains that intentionally don't accept email:

example.com.  IN  MX  0  .

The period (.) as the exchange value with priority 0 signals that the domain accepts no mail. This causes sending servers to immediately reject with a clean bounce rather than spending time trying to connect to non-existent servers.

Useful for domains that exist only for websites or other purposes — prevents spam attempts and makes bounces immediate rather than requiring timeout failures.

---

How to use the MX Lookup on sadiqbd.com

1. Enter the domain
2. Look up — the tool queries DNS and returns all MX records with their priority values
3. Verify the target hostnames — the tool also shows whether each MX target resolves to an A record
4. Check the priority order — confirm the expected primary and backup servers

---

Frequently Asked Questions

Do I need multiple MX records? A single MX record works but has no redundancy — if that server is unavailable, delivery is delayed until the sending server gives up (typically after repeated retries over several hours). Multiple MX records at different priorities provide failover. Most commercial email providers supply 2–5 MX records for redundancy.

Can I use the same server at multiple priorities? Yes — some configurations use the same server at multiple priorities for load balancing. Most real-world setups use different servers for different priority levels to provide true redundancy.

Why does my new email provider say my MX records are wrong when I added them yesterday? DNS propagation. Your previous MX records had a TTL (e.g. 3600 seconds = 1 hour). Until that TTL expires on all resolvers worldwide, some will return the old records. Most propagation completes within 24–48 hours but can take longer depending on TTL.

Is the MX Lookup free? Yes — completely free, no sign-up required.

---

MX records are the first place to check when email delivery fails. The lookup tool makes the diagnosis immediate — you see exactly which servers are supposed to receive mail, and whether they're correctly configured.

Try the MX Lookup free at sadiqbd.com — query any domain's mail server records and verify their A record targets instantly.