MX Records Not Verifying – Quick Fix Guide

You've added your MX records, waited hours, and they still won't verify. That's annoying. Let's fix it.

Step 1: Check your MX record syntax

Most verification failures come from a simple typo or wrong format. First, look at what you actually entered in your DNS zone. You need a specific format: a priority number followed by the mail server hostname.

For Google Workspace, it should look like this:

1 ASPMX.L.GOOGLE.COM.

For Office 365:

0 yourdomain-com.mail.protection.outlook.com.

Notice the trailing dot after the hostname. Many DNS providers add this automatically, but some don't. That dot tells the DNS system the hostname is fully qualified — no dot means it's relative, and the record won't resolve correctly.

Expected outcome: After correcting the dot, wait 5 minutes (or adjust TTL — see below) and re-run your verification. You should see the record show up.

Step 2: Lower the TTL temporarily

Your MX record has a TTL (Time To Live) value in seconds. If it's set to 86400 (24 hours), changes take a full day to propagate. That's useless for testing.

Change the TTL to 300 (5 minutes) for your MX records. Do this before you make any changes. Here's how:

Log into your DNS provider (like GoDaddy, Cloudflare, Namecheap, or your host's panel).
Find your MX record in the DNS zone editor.
Edit the TTL field. If you can't see a TTL option, look for advanced settings.
Set it to 300 (seconds).
Save the record.

Expected outcome: After saving, any verification tool you use should pick up the change within 5 minutes. If your tool still shows old records, flush your local DNS cache — on Windows open Command Prompt and type ipconfig /flushdns. On Mac, type sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder.

Step 3: Verify you're looking at the right zone

This one trips up people. Your MX records live in the DNS zone for the exact domain. If your email is for user@subdomain.yourdomain.com, the MX records go in the zone for subdomain.yourdomain.com, not yourdomain.com.

Also, double-check you're not editing a different zone (like a staging domain or a parked domain). I've seen technicians fix records for the wrong domain for hours.

Expected outcome: Once you're in the correct zone, the record you entered should match what verification tools see. Run a quick MX lookup with nslookup -type=mx yourdomain.com (replace with your domain) to confirm.

Why the fix works

MX records work like mail routing instructions. The server making the request (like Google's email checker) asks the DNS system: "Where do I send email for this domain?" If the MX record has a typo — missing dot, wrong hostname, wrong priority — that server can't find the target. So it says "not verified."

Lowering TTL forces the DNS system to refresh quickly. Without that, even correct records stay hidden for up to 24 hours while old cached copies are used.

Less common variations

Variant 1: You're using CNAME records that point to the same host

Some providers (like Google Workspace) require a specific CNAME for verification, plus MX records. If you have a CNAME that conflicts (like mail.yourdomain.com pointing somewhere else), the MX lookup may fail. Remove that CNAME or point it to the same host as your MX target.

Variant 2: Your DNS provider has a bug

Rare, but happens. I've seen cases where a provider's web interface saves the record but doesn't actually write it to their DNS servers. Fix: export your zone file (some providers let you download a text file), then check the file for your MX record. If it's missing, contact support.

Variant 3: You need to add an SPF record too

Some verification tools also check SPF records. Without one, they might mark MX as "not verified" because email won't be delivered anyway. Add an SPF record like: v=spf1 include:_spf.google.com ~all for Google Workspace, or v=spf1 include:spf.protection.outlook.com -all for Office 365.

Prevention for next time

Before you add any MX record, do this checklist:

Write down the exact hostname (including the trailing dot) from your email provider's docs.
Set TTL to 300 before making changes.
Verify you're editing the right domain zone.
Test with nslookup -type=mx immediately after saving to catch typos.

That's it. Most MX issues are just a dot or a wrong zone. You won't waste hours again.