DNS & Domain Guides

MX Records 101: Directing Email to the Right Server

Learn what MX records do, how they route incoming email, how MX priority works, and how to check and fix common mail routing problems.

By CheckDomainHealth Editorial Team Reviewed by Dionis Ceban Updated Jun 28, 2026 8 min read Beginner

Introduction

MX records tell the internet which mail servers should receive email for your domain. When someone sends a message to user@example.com, the sending mail server looks up the MX records for example.com and delivers the message to the listed mail provider.

If MX records are missing, outdated or pointing to the wrong provider, incoming email may fail, bounce or arrive at the wrong mail system. This is why MX records should always be checked after changing email providers, moving DNS, migrating hosting or setting up business email.

Quick answer

Quick answer

MX records, or Mail Exchange records, tell sending mail servers where to deliver incoming email for a domain. Each MX record points to a mail server hostname and has a priority value. Lower priority numbers are tried first.

What is an MX record?

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

Example 
example.com MX 10 mail.example.com

In this example, email sent to addresses at example.com should be delivered to mail.example.com. The number 10 is the priority. Lower numbers have higher priority.

  1. Someone sends an email to user@example.com.
  2. The sending mail server checks MX records for example.com.
  3. DNS returns one or more mail server hostnames.
  4. The sending server chooses the mail server with the highest priority.
  5. The email is delivered to that mail server if it accepts the message.

An MX record should point to a hostname, not directly to an IP address. The mail server hostname should then have an A or AAAA record.

MX priority

MX records use priority numbers to decide which mail server should be tried first. Lower numbers have higher priority.

Priority example 
example.com.  3600  IN  MX  10  mx1.mailprovider.com.
example.com.  3600  IN  MX  20  mx2.mailprovider.com.

mx1.mailprovider.com has priority 10, so it is preferred. mx2.mailprovider.com has priority 20, so it is usually used as backup.

Do not assume higher numbers mean higher priority. For MX records, lower numbers are preferred.

One provider at a time

In most setups, all MX records should point to one active email provider. Mixing MX records from Google Workspace, Microsoft 365, old hosting mail and a third-party platform at the same time usually causes routing problems.

Risky: mixed providers 
example.com MX 10 aspmx.l.google.com
example.com MX 10 mail.protection.outlook.com

Unless you intentionally designed split delivery, remove old provider MX records when switching mail platforms. Use only the MX hostnames and priorities from your current provider documentation.

Google Workspace

Use the MX hostnames and priorities from your Google admin or setup guide.

Microsoft 365

Copy the exact MX records from the Microsoft 365 DNS setup instructions.

Zoho Mail

Add the MX records listed in your Zoho Mail control panel.

cPanel / hosting mail

Often uses mail.yourdomain.com or provider-specific MX hostnames.

Backup MX carefully

Many providers publish multiple MX records for redundancy. A backup MX with a higher priority number is only useful if that server is meant to receive mail for your domain.

  • Use backup MX records only when your provider recommends them.
  • Do not leave old provider MX records as accidental backups.
  • Confirm backup servers accept mail for your domain.
  • Use the exact priority values from provider documentation.

A backup MX pointing to an old mail system can keep delivering email to the wrong place even after you think migration is complete.

No IPs in MX values

MX records should point to a mail server hostname, not directly to an IP address. The hostname must resolve using A or AAAA records.

Correct pattern 
example.com.      MX  10  mail.example.com.
mail.example.com. A       192.0.2.25

If the MX hostname does not resolve, mail delivery can fail even if the MX record itself exists.

The IP address 192.0.2.25 is only a documentation example. Use the real value from your mail provider.

Why this matters

Why this matters

MX records are critical for incoming email. If they point to the wrong provider, messages can bounce, disappear into an old mailbox system or be rejected by the receiving server. MX records do not control your website, but they directly affect whether your domain can receive email.

How to check MX records

Use the MX Lookup tool to see which mail servers are currently configured for your domain.

What to compare

When checking MX records, compare these five values.

Domain

The domain that receives email, such as example.com.

Current MX hostnames

The mail server hostnames returned by public DNS.

Priority values

The order in which mail servers should be tried.

Expected provider values

The MX records given by your email provider.

Active nameserver

The DNS provider currently controlling the live DNS zone.

If the current MX records do not match the expected provider values, confirm that you are editing DNS at the active nameserver provider.

Check MX records now

Use MX Lookup to confirm which mail servers currently receive email for your domain.

Run MX Lookup →

Common problems

MX records point to the wrong provider

High

Email may still route to an old email provider, old hosting server or wrong mail service.

Next step: Compare the current MX records with your active email provider’s required values.

Missing MX records

High

The domain has no MX records, so sending servers may not know where to deliver incoming email.

Next step: Add the MX records provided by your email service.

MX hostname does not resolve

High

The MX record points to a mail hostname that has no A or AAAA record.

Next step: Fix the mail hostname DNS record or use the correct MX hostname from your provider.

Wrong MX priority

Medium

Backup or secondary mail servers may be preferred incorrectly if priorities are wrong.

Next step: Use the priority values recommended by your email provider.

Mixed MX providers

Medium

MX records from different email providers are active at the same time.

Next step: Remove old provider MX records unless the setup is intentionally designed.

MX changed but email still goes to old mailbox

Low

DNS cache may still return old MX records until TTL expires.

Next step: Wait for TTL/cache expiry and check from multiple DNS resolvers.

Mail server rejects messages

High

MX records may be correct, but the receiving mail server may reject mail due to mailbox, routing, authentication or server configuration.

Next step: Check mailbox existence, mail routing, spam filtering and server logs.

Root domain works but subdomain mail does not

Medium

A subdomain can have separate MX records from the root domain.

Next step: Check MX records for the exact domain or subdomain receiving email.

How to configure MX records

  1. Step 1: Confirm your active email provider

    Identify which provider should receive email for the domain, such as Google Workspace, Microsoft 365, Zoho, cPanel email, or a custom mail server.

  2. Step 2: Get the official MX records

    Copy the exact MX hostnames and priorities from your email provider. Do not guess MX values.

  3. Step 3: Confirm where DNS is hosted

    Check the active nameservers for the domain. Make MX changes only at the DNS provider controlling the live zone.

  4. Step 4: Remove old MX records if needed

    If you are switching email providers, remove old MX records unless your provider specifically instructs you to keep them.

  5. Step 5: Add the new MX records

    Create the MX records with the correct hostnames and priority values.

    Type: MX | Host: @ | Priority: 10 | Value: mx1.mailprovider.com | TTL: 3600
  6. Step 6: Check that MX hostnames resolve

    Make sure each MX hostname resolves to an IP address. An MX record pointing to a broken hostname can still cause delivery failures.

  7. Step 7: Verify mail delivery

    After saving records and allowing for DNS cache, send test messages from external mail services and check whether they arrive at the expected mailbox.

Check commands 
dig example.com MX
dig mx1.mailprovider.com A

These are examples only. Use the exact MX records provided by your email provider. Do not copy example hostnames into production DNS.

MX vs SPF/DKIM/DMARC

MX records control where incoming email is delivered. SPF, DKIM and DMARC help receiving mail servers evaluate whether outgoing email from your domain is authenticated.

MX

Routes incoming email to the correct mail server.

SPF

Lists which servers are allowed to send email for the domain.

DKIM

Adds a cryptographic signature to outgoing email.

DMARC

Tells receivers how to handle email that fails SPF or DKIM alignment.

Changing MX records does not automatically configure SPF, DKIM or DMARC. After setting MX records, check email authentication separately.

Mail routing after migration

Hosting migrations can accidentally break email if website DNS and mail DNS are moved together without checking MX records.

  • Current MX records
  • Active mail provider
  • Required MX records in the new DNS zone
  • SPF, DKIM and DMARC TXT records
  • Mailboxes and routing rules
  • Whether email is hosted separately from the website

Do not assume moving a website also moves email. Website hosting and email hosting may be handled by different providers.

TTL and testing

After changing MX records, DNS cache and TTL can delay when the new routing takes effect. Email may still arrive at the old provider until cached MX answers expire.

  • Check MX from multiple DNS resolvers or use MX Lookup.
  • Note the TTL on existing MX records before changing them.
  • Lower TTL before a planned migration if your DNS provider allows it.
  • Send test messages from external mail services after the change.
  • Watch for bounces, delays or mail arriving at the old mailbox.
  • Confirm SPF, DKIM and DMARC still resolve after DNS moves.

A valid MX record does not guarantee inbox delivery, but it is required for normal incoming mail routing.

Frequently asked questions

Are MX records required to receive email?

Usually yes. MX records tell sending mail servers where to deliver email for your domain. Without MX records, incoming email may fail or behave unpredictably.

Can MX records point to an IP address?

MX records should point to a hostname, not directly to an IP address. The mail server hostname should then resolve using A or AAAA records.

What does MX priority mean?

MX priority controls which mail server is tried first. Lower numbers have higher priority.

Can I have multiple MX records?

Yes. Many providers use multiple MX records for redundancy. Use the exact priorities recommended by your email provider.

Can I use MX records from two email providers?

Usually no, unless you intentionally designed split delivery. Mixing providers by accident can route mail to the wrong system.

Does changing MX records affect outgoing email?

MX records mainly affect incoming email. Outgoing email authentication depends more on SPF, DKIM and DMARC.

Why does email still go to the old provider after changing MX?

DNS cache may still return the old MX records, or the change may have been made at the wrong DNS provider. Check active nameservers and wait for TTL expiry.

Do subdomains need separate MX records?

Only if the subdomain receives email directly, such as user@mail.example.com. Subdomains can have separate MX records from the root domain.

Use these free tools to verify your configuration after applying changes.

MX Lookup DNS Lookup SPF Checker DKIM Checker DMARC Checker Domain Health Checker
SPF Basics: Defining Authorized Senders 7 min read DKIM Signatures: How They Work and Why They Matter 8 min read DMARC for Beginners: Policies, Alignment and Enforcement 8 min read Understanding DNS: How Domain Names Connect to Websites and Email 8 min read How to Run a Complete Domain Health Check 9 min read Slow Email Delivery: Common Causes and Fixes 8 min read
Browse all DNS & Domain guides →

Need help applying this fix?

Send us your domain, report link or issue details. CheckDomainHealth will review the request and route it to the right technical team if hands-on support is needed.

Get Help Run Domain Health Check

Was this guide helpful?

Your feedback helps us improve our guides for everyone.