MX Record Checker: Fix Email Receiving and Mail Routing Problems

Quick answer: what should an MX checker look for?

A useful MX checker should check the records that control incoming mail routing, then compare them with the provider that should receive email for the domain.

If you cannot receive domain email, check nameservers, MX records, and mailbox setup before touching SPF, DKIM, or DMARC.

What is an MX record?

MX stands for Mail Exchange.

An MX record is a DNS record that tells sending mail servers where to deliver email for a domain.

For example, when someone sends email to:

hello@example.com

the sender's mail server checks the MX records for:

example.com

Those MX records tell the sender where to deliver the message.

If your domain uses Google Workspace, the MX record should point to Google. If your domain uses Microsoft 365, the MX record should point to Microsoft. If your domain uses Zoho, Proton, Fastmail, cPanel email, or a forwarding service, the MX record should point to that provider.

For a broader view of the surrounding records, start with the email DNS checker guide.

MX records control incoming email

MX records affect receiving email.

They do not usually control:

• Whether your website loads
• Whether SPF passes
• Whether DKIM passes
• Whether DMARC passes
• Whether email lands in inbox or spam
• Whether the mailbox exists
• Whether a user has a paid email license

That distinction matters. If the problem is I cannot receive email at hello@example.com, MX is one of the first things to check.

If the problem is My sent emails go to spam, MX is usually not the main issue. Check authentication records with the SPF record checker, DKIM record checker, and DMARC record checker.

Website DNS and MX records are different

A website can work perfectly while email is broken.

If your website works but email does not, do not immediately change A or CNAME records. Check MX first.

For the full troubleshooting path, use the website works but email does not guide.

What does an MX record look like?

An MX record usually has four main parts:

Example for Google Workspace:

example.com    MX    1    smtp.google.com

Example for Microsoft 365:

example.com    MX    1    example-com.mail.protection.outlook.com

The Microsoft 365 value is only an example format. The exact target is domain-specific and must come from Microsoft 365 admin center.

MX priority explained

MX priority tells sending mail servers which MX target to try first.

Lower priority numbers are more preferred.

example.com    MX    1     mail1.examplemail.com
example.com    MX    10    mail2.examplemail.com

In this example, sending servers should try the priority 1 server first, then the priority 10 server if needed.

Use the priorities your email provider gives you.

Multiple MX records: good or bad?

Multiple MX records are normal when they belong to the same email provider and are part of that provider's recommended setup.

They are risky when they point to different unrelated email providers.

Usually okay

example.com MX 10 mx1.sameprovider.com
example.com MX 20 mx2.sameprovider.com

Usually suspicious

example.com MX 1 example-com.mail.protection.outlook.com
example.com MX 5 ASPMX.L.GOOGLE.COM
example.com MX 10 mail.oldhost.com

This suggests Microsoft 365, Google Workspace, and an old host are mixed together. That is usually not what you want.

Common MX record problems

Step 1: Confirm the active nameservers

Before editing MX records, confirm where your live DNS is managed.

In this setup, Cloudflare controls live DNS because the nameservers point to Cloudflare. Adding MX records inside Namecheap will not fix live email DNS if Cloudflare is the active DNS host.

1. Check the domain's nameservers.
2. Identify the active DNS host.
3. Edit MX records only at the active DNS host.
4. Recheck public DNS after saving.

Step 2: Identify the intended email provider

Before changing MX records, answer this: Which provider should receive email for this domain?

Do not guess. Use the exact MX values from the email provider's setup page.

Step 3: Check current MX records

Look at all MX records currently published for the domain.

• Are there any MX records?
• Which provider do they point to?
• Are there records from old providers?
• Are there records from multiple unrelated providers?
• Do priorities match the provider's instructions?
• Were the records added at the correct DNS host?

Example: clean Google Workspace setup

example.com MX 1 smtp.google.com

Example: clean Microsoft 365 setup

example.com MX 1 example-com.mail.protection.outlook.com

The Microsoft value is only an example. Use the exact value from your Microsoft 365 admin center.

Example: suspicious mixed setup

example.com MX 1 smtp.google.com
example.com MX 5 example-com.mail.protection.outlook.com
example.com MX 10 mail.oldhost.com

This needs investigation because it mixes Google, Microsoft, and an old host.

Step 4: Remove old MX records when ready

Old MX records are one of the most common reasons domain email fails after migration.

For example, you move from cPanel email to Google Workspace.

example.com MX 10 mail.example.com
example.com MX 1 smtp.google.com

If you keep both, mail routing may not behave the way you expect.

Safe process

1. Confirm the new email provider is ready.
2. Confirm users, aliases, or mailboxes exist.
3. Confirm the domain is verified.
4. Add the new provider's MX records.
5. Remove old MX records when ready to switch routing.
6. Send test emails from outside accounts.
7. Watch for bounce messages.

Do not delete old provider access until you are sure migration is complete.

Step 5: Confirm the mailbox or alias exists

MX records do not create mailboxes. They only route mail to the email provider.

For example, your MX can correctly point to Microsoft 365, but if this address does not exist, incoming mail may still bounce:

hello@example.com

Check whether the address exists as one of these:

• User mailbox
• Alias
• Shared mailbox
• Group
• Distribution list
• Forwarding address
• Catch-all address
• Routing rule

Common mistake: MX is correct for Google Workspace, but hello@example.com is not created as a user or alias. MX is correct, but the email still fails.

Step 6: Check provider activation and verification

Many email providers require more than MX records.

• Domain verification
• Admin approval
• User mailbox creation
• License assignment
• Gmail activation
• Microsoft 365 domain setup completion
• Routing rules
• Destination mailbox verification
• Email forwarding confirmation

If the email provider dashboard says setup is incomplete, fix that before assuming DNS is the only problem.

Google Workspace MX records

For new Google Workspace setups, Google's current MX value is:

smtp.google.com

A typical Cloudflare-style entry:

Older Google Workspace setups may use legacy ASPMX records such as:

ASPMX.L.GOOGLE.COM
ALT1.ASPMX.L.GOOGLE.COM
ALT2.ASPMX.L.GOOGLE.COM
ALT3.ASPMX.L.GOOGLE.COM
ALT4.ASPMX.L.GOOGLE.COM

If legacy Google MX records are already working, they may not need to be changed just for cleanup. For new setups, follow Google Admin's current instructions.

For the complete Cloudflare checklist, see the Google Workspace Cloudflare DNS guide.

Microsoft 365 MX records

Microsoft 365 MX records are domain-specific.

The target usually has this format:

<domain-key>.mail.protection.outlook.com

Example only:

example-com.mail.protection.outlook.com

Do not guess this value. Copy it from Microsoft 365 admin center.

If Microsoft 365 should receive email, old MX records from Google, cPanel, Zoho, Proton, or other providers should usually be removed when you are ready to switch.

For the full setup checklist, see the Microsoft 365 Cloudflare DNS guide.

MX records for email forwarding services

Email forwarding services also use MX records.

For example, if you want hi@example.com to forward to yourname@gmail.com, the forwarding service must usually receive mail first. That means your domain's MX records must point to the forwarding service.

If you use forwarding only, make sure the forwarding service is the active MX destination.

MX records for subdomains

MX records can exist for the root domain or a subdomain.

example.com
support.example.com
mail.example.com

If you want to receive email at hello@example.com, check MX for example.com.

If you want to receive email at agent@support.example.com, check MX for support.example.com.

A common mistake is adding MX records to the wrong name. Adding MX under mail.example.com does not necessarily route mail for hello@example.com.

MX record target should be a hostname, not an IP

MX target should be a hostname, not an IP address.

An MX target should be a mail server hostname.

Good:

example.com MX 10 mail.example.com

Bad:

example.com MX 10 192.0.2.10

If the mail server is yours, the MX target should be a hostname, and that hostname should resolve to an A or AAAA record.

example.com MX 10 mail.example.com
mail.example.com A 192.0.2.10

Most small businesses using Google Workspace, Microsoft 365, Zoho, Proton, or Fastmail do not need to create their own mail server hostname. They should use the provider's MX values.

MX target should not point to a CNAME

An MX target should resolve to address records, not to a CNAME target.

Better:

example.com MX 10 mail.provider.com
mail.provider.com A 192.0.2.10

Risky:

example.com MX 10 mail.example.com
mail.example.com CNAME other.example.net

Some systems may tolerate this, but it is not a clean setup. For normal business email, use the MX target exactly as your email provider gives it.

MX and Cloudflare

If your DNS is managed in Cloudflare, add MX records in Cloudflare.

MX records are DNS-only. They do not use Cloudflare's orange-cloud proxy.

If your website is proxied through Cloudflare, that does not automatically affect email. Email routing still depends on MX records.

MX and website hosting

A website host and email host can be different.

In this setup, Vercel records keep the website working, Google MX records receive email, and Cloudflare is where DNS records are managed.

In this setup, the website may still need the cPanel A record, email should use Microsoft 365 MX, and you may remove old cPanel MX records when Microsoft is ready.

Website hosting and email hosting are separate jobs.

What happens if there are no MX records?

If a domain has no MX records, some sending systems may try fallback behavior using the domain's A or AAAA records.

Do not rely on that for business email.

For a real business mailbox, publish the correct MX records from your email provider.

If the domain intentionally does not accept email, a special Null MX record may be used by advanced administrators. For most businesses trying to receive email, missing MX is a problem to fix, not a strategy.

What is a Null MX record?

A Null MX record tells senders that a domain does not accept email.

example.com MX 0 .

This is not for normal email setup. Use Null MX only when you intentionally want the domain to receive no mail.

Do not add Null MX if you expect addresses such as hello@example.com, support@example.com, or billing@example.com to work.

For Domain Email Doctor's typical users, a Null MX result usually means this domain is not configured to receive email.

MX records and bounce messages

Bounce messages often reveal the real problem.

If you have a bounce message, read it before making random DNS changes.

Scenario 1: Website works, but no email arrives

Most likely causes include missing MX records, MX records added at the wrong DNS host, MX pointing to an old or wrong provider, missing mailbox or alias, incomplete provider setup, or incomplete domain verification.

1. Check active nameservers.
2. Check MX records.
3. Confirm the intended email provider.
4. Remove old MX records if needed.
5. Confirm the mailbox or alias exists.
6. Check provider activation.
7. Send a test email from an external account.

Do not change website A or CNAME records unless the website itself is broken.

Scenario 2: Email goes to old provider

This is usually an MX problem.

For example, you moved to Microsoft 365, but mail still appears in your old Google Workspace or cPanel inbox.

• Old MX records are still active.
• MX priorities still favor the old provider.
• DNS was changed in the wrong host.
• Migration was not completed.
• Sender is using cached DNS results.

1. Check public MX records.
2. Confirm the active DNS host.
3. Remove or update old MX records when ready.
4. Wait for DNS propagation.
5. Test again from external mailboxes.

Scenario 3: Some users receive mail, others do not

This is less likely to be pure MX if the same domain is involved.

• Missing mailbox
• Missing alias
• User not licensed
• Shared mailbox not configured
• Group or distribution list issue
• Mail routing rule problem
• Spam or junk filtering
• Old forwarding rule

If MX were completely wrong, the whole domain would usually be affected. Confirm MX records for the whole domain, then check the failing recipient inside the email provider.

Scenario 4: Email worked before moving to Cloudflare

When moving DNS to Cloudflare, people often copy website records but forget email records.

Result: website works, email fails, MX records may be missing, and SPF, DKIM, and DMARC may also be missing.

1. Did nameservers change to Cloudflare?
2. Were old MX records copied into Cloudflare?
3. Were SPF, DKIM, and DMARC copied?
4. Were verification records copied?
5. Is the email provider still activated?

If email stopped after moving to Cloudflare, check Cloudflare DNS first.

Scenario 5: Email broke after website migration

Website migrations can accidentally damage email DNS. A developer may move the website to Vercel, Netlify, Wix, Shopify, or Squarespace and only copy website records.

If MX records are not copied into the new active DNS host, email may fail even though the website is fine.

1. Check whether nameservers changed.
2. Check whether MX records still exist.
3. Check whether old MX records were removed accidentally.
4. Check whether the email provider still verifies the domain.
5. Restore the correct MX records.

Website migration should not require breaking email.

Scenario 6: Microsoft 365 says MX is missing

Check these items:

1. Are you editing DNS at the active DNS host?
2. Did you copy the Microsoft-provided MX target?
3. Does the target end with mail.protection.outlook.com?
4. Did you add it at @ for the root domain?
5. Is the priority correct?
6. Are old MX records still present?
7. Has DNS had time to propagate?
8. Are you checking the correct domain in Microsoft 365?

The Microsoft MX target is domain-specific. Do not guess it.

Scenario 7: Google Workspace says MX is missing

Check these items:

1. Are you editing DNS at the active DNS host?
2. Did you add Google's MX record at @?
3. Is the mail server smtp.google.com for a new setup?
4. Are old non-Google MX records removed?
5. Is Gmail activated in Google Admin?
6. Is the domain verified?
7. Has DNS had time to propagate?
8. Are you checking the root domain and not www?

If you are using older Google ASPMX records and email works, you may not need to change them.

Scenario 8: Email forwarding is not working

Email forwarding is still email receiving. The forwarding provider must receive the message before it can forward it.

1. MX records point to the forwarding provider.
2. Destination mailbox is verified.
3. The forwarding alias exists.
4. Old MX records are removed.
5. The destination mailbox is not filtering the mail.
6. The forwarding service is active.
7. The sender is not receiving a bounce.

MX records vs SPF, DKIM, and DMARC

These records are related, but they solve different problems.

If you cannot receive email, check MX first. If you can receive but sent emails go to spam, check SPF, DKIM, and DMARC.

If the domain is used for business email, you eventually want all of them configured correctly.

Safe MX troubleshooting workflow

1. Identify whether the problem is receiving, sending, or spam placement.
2. If receiving is broken, check active nameservers.
3. Confirm the active DNS host.
4. Check current MX records.
5. Identify the intended email provider.
6. Compare current MX records with provider instructions.
7. Remove old MX records when ready.
8. Confirm the mailbox, alias, group, or forwarding rule exists.
9. Confirm provider verification and activation.
10. Send test email from an external mailbox.
11. Read any bounce message.
12. Wait for DNS propagation before changing more records.

This avoids changing website records or authentication records when the real problem is mail routing.

What not to do

• Do not edit MX records at the registrar if DNS is managed elsewhere.
• Do not delete website A/CNAME records while fixing email.
• Do not mix MX records from several email providers casually.
• Do not point MX directly to an IP address.
• Do not assume MX creates mailboxes.
• Do not add MX under www for normal root-domain email.
• Do not keep old MX records after a completed migration.
• Do not assume Cloudflare orange cloud affects MX.
• Do not change SPF/DKIM/DMARC first if receiving is completely broken.
• Do not ignore bounce messages.
• Do not keep making DNS changes every few minutes during propagation.

Final MX checklist

• Active nameservers are confirmed.
• DNS is edited at the active DNS host.
• Intended email provider is known.
• MX records exist.
• MX records point to the intended provider.
• MX priorities match provider instructions.
• Old MX records are removed when ready.
• MX target is a hostname, not an IP.
• MX target resolves properly.
• Mailbox or alias exists.
• Email provider has verified the domain.
• Email provider has activated mail service.
• Test email from an external sender arrives.
• Bounce messages are reviewed.
• Website records remain untouched unless the website is also broken.

Run an MX record check

Use Domain Email Doctor to scan your domain's public DNS records before changing anything.

A scan can help show whether your domain has MX records, which mail provider they point to, whether old providers are still present, and whether other email DNS records such as SPF, DKIM, and DMARC also need attention.

Start with MX when the problem is receiving email. Fix routing first, then improve authentication.