The Complete Guide to MX Records: Everything You Need to Know

MX records are the foundation of email delivery. Every email sent to your domain depends on these DNS entries to reach the right mail server. Get them wrong and email bounces, disappears, or lands in the wrong place.

This guide covers everything you need to know about MX records, from the basics of how they work to provider-specific setup, troubleshooting, and ongoing monitoring. Whether you're setting up email for the first time or diagnosing a delivery problem, start here.

What Are MX Records?

MX stands for Mail Exchanger. An MX record is a type of DNS record defined in RFC 1035 that specifies which mail servers are responsible for accepting email on behalf of your domain.

When someone sends an email to you@yourdomain.com, the sending server queries DNS for your domain's MX records. DNS returns a list of mail servers and their priority values. The sender tries the highest-priority server first, then falls back to alternates if needed.

Without MX records, there's no way for the internet to know where to deliver your email. Messages bounce immediately with a "no mail exchanger" error. This is different from a misconfigured server. With no MX records, the sending server doesn't even attempt delivery. It gives up instantly.

Every domain that receives email needs at least one MX record. Most have two or more for redundancy. The records themselves are small (just a priority number and a hostname) but they're the single most critical piece of your email infrastructure.

For a gentler introduction, see What is an MX Record?. For the technical deep dive into structure and internals, see MX Records Explained.

How MX Records Work

Understanding the email delivery chain helps you diagnose problems when things go wrong. Here's what happens every time someone sends you an email:

The Delivery Sequence

1. Someone sends an email to you@yourdomain.com
2. Their mail server extracts the domain (yourdomain.com) from the recipient address
3. It queries a DNS server: "What are the MX records for yourdomain.com?"
4. DNS returns one or more MX records, each with a priority value and a mail server hostname
5. The sending server sorts the results by priority (lowest number first)
6. It attempts to connect to the highest-priority server on port 25 (SMTP)
7. If that server accepts the connection and the message, delivery is complete
8. If the server is unreachable, refuses the connection, or returns a temporary error, the sender tries the next server in priority order
9. This continues until delivery succeeds or all servers have been tried
10. If every server fails, the sending server queues the message and retries periodically (usually for up to 5 days) before generating a bounce

This process, defined in RFC 5321 (SMTP), happens in milliseconds for the initial attempt. But notice how many things need to be right: the MX records must exist, the hostnames must resolve to IP addresses, the servers must be reachable on port 25, and they must be configured to accept mail for your domain.

What Happens Without MX Records

If a domain has no MX records at all, the behaviour depends on whether an A record exists for the domain:

• No MX records, no A record: Immediate bounce. The sending server has nowhere to try.
• No MX records, but A record exists: Some mail servers will fall back to attempting delivery directly to the IP address in the A record. This is a legacy behaviour defined in RFC 5321. You should never rely on it, as it's inconsistent across mail servers, and many modern providers don't honour it.

The takeaway: always configure explicit MX records. Don't rely on fallback behaviour.

MX Record Structure

Every MX record has two components:

Priority: a number from 0 to 65535 that determines the order servers are tried. Lower numbers mean higher priority. The number itself has no intrinsic meaning; what matters is the relative order among your records.

Hostname: the fully qualified domain name (FQDN) of a mail server. This must be a hostname, never an IP address. Using an IP directly violates RFC 5321 and will cause delivery failures with many email systems.

Here's what MX records look like in a DNS zone file:

example.com.    IN    MX    10    mail.example.com.
example.com.    IN    MX    20    backup.example.com.

The first record says: for email to example.com, try mail.example.com first (priority 10). The second provides a fallback at backup.example.com (priority 20).

The mail server hostname needs its own A record (or AAAA record for IPv6) to resolve to an IP address. This two-step design exists for flexibility: you can change the IP address of your mail server by updating its A record without touching any MX records. Every domain that references your mail server automatically uses the new IP.

Priority and Failover

Priority values create a hierarchy for delivery. The sending server always tries the lowest number first. If that server is unavailable (down for maintenance, unreachable, or returning errors), the sender moves to the next lowest priority.

Equal priorities create load balancing. When two or more MX records share the same priority value, sending servers pick randomly between them. This distributes incoming mail roughly evenly. Large email providers like Google Workspace use this. Their five MX records include two pairs at the same priority:

The server at priority 1 handles most traffic. If it's busy or down, traffic splits between the two priority-5 servers. If those fail too, it falls to the priority-10 pair.

Priority spacing matters for flexibility. Using 10, 20, 30 instead of 1, 2, 3 leaves room to insert new servers later without renumbering everything. Need to add a server between your primary and first backup? Give it priority 15. With 1, 2, 3 you'd have to renumber the entire chain.

For a deeper look at priority mechanics, including edge cases with equal priorities and how different mail servers handle them, see MX Record Priority Explained.

Multiple MX Records and Redundancy

A single MX record means a single point of failure. One server outage, planned or unplanned, and every email to your domain bounces. This is why virtually every production email setup uses multiple MX records.

With two or more MX records, you get:

Automatic failover. If your primary mail server goes down, email routes to your backup automatically. Senders don't notice. No one needs to do anything.

Painless maintenance. You can take a server offline for updates, patches, or hardware replacement knowing email will route to alternates. No maintenance window coordination needed.

Geographic distribution. Some organizations place MX servers in different data centers or regions. Email routes to the nearest available server, improving latency and providing disaster recovery.

Load balancing. Equal-priority records distribute traffic across multiple servers, preventing any single server from becoming a bottleneck.

A typical redundant configuration:

The two priority-10 servers share the load during normal operation. If the entire primary datacenter goes offline, the priority-20 backup takes over until it's restored.

Read more in Can You Have Multiple MX Records?.

Setting Up MX Records by Email Provider

Each email provider requires specific MX records, and the exact hostnames and priority values differ between providers. Using the wrong values means email goes to the wrong place or bounces entirely.

How Provider MX Records Differ

The number of MX records varies significantly by provider:

• Google Workspace uses five MX records with a multi-tier priority structure. Google's infrastructure load-balances across all five servers automatically. All five are required, and using fewer reduces redundancy.
• Microsoft 365 uses a single MX record with a tenant-specific hostname (e.g. yourdomain-com.mail.protection.outlook.com). Microsoft handles redundancy internally within their infrastructure.
• Zoho Mail uses three MX records with regional variants depending on where your account is hosted (US, EU, India, Australia, or Japan).
• ProtonMail and Fastmail each use two MX records in a simple primary/backup configuration.

The important thing is to use your provider's values exactly. Don't guess, don't mix records from different providers, and don't leave old records in place when switching.

Major Email Platforms

• Google Workspace MX Records: five MX records with priorities 1, 5, 5, 10, 10
• Microsoft 365 MX Records: single tenant-specific record at priority 0
• Zoho Mail MX Records: three records with regional variants
• ProtonMail MX Records: two records for encrypted mail delivery
• Fastmail MX Records: two records at messagingengine.com

For the full list of 16 providers with exact MX record values and a quick-reference comparison table, see MX Records by Email Provider.

DNS Provider Setup Guides

Once you know which MX records to add, you need to add them in the right place. The process varies by DNS host:

• Add MX Records in Cloudflare
• Add MX Records in GoDaddy
• Add MX Records in Namecheap

More guides coming for Bluehost, Squarespace, Hostinger, Porkbun, Route 53, and others. See How to Add MX Records for the universal process that works across all hosts.

MX Records and Other DNS Records

MX records don't exist in isolation. They interact with several other DNS record types, and misunderstanding these relationships is one of the most common sources of email problems.

MX Records and A Records

MX records point to hostnames. A records map those hostnames to IP addresses. You need both layers for email delivery to work.

When a sending server looks up your MX records and gets mail.example.com, it then needs to resolve mail.example.com to an IP address via an A record. If the A record is missing, the MX record is useless. The hostname can't be resolved, and email bounces even though your MX record looks perfectly correct.

This is a common cause of "everything looks right but email doesn't work" problems. The MX record is fine. The mail server is running. But the hostname in the MX record doesn't have an A record, so the sending server can never find it.

The fix is always the same: verify that every hostname referenced in your MX records has a valid A record that resolves to the correct IP address.

For IPv6, you'll also want AAAA records. Most email is still delivered over IPv4, but IPv6-only senders are becoming more common.

MX Records and CNAME Records

There's an important DNS rule that catches people off guard: you cannot have both a CNAME and MX records on the same domain name. This is a fundamental DNS specification limitation defined in RFC 1034, not a provider-specific restriction.

A CNAME (Canonical Name) record creates an alias, meaning "this name is really that other name." When a CNAME exists for a domain, it takes over all record types for that name. You can't have a CNAME and an MX, a CNAME and an A record, or a CNAME and a TXT record on the same name.

This is why your root domain (example.com) should use A records rather than a CNAME. If you CNAME your root domain to something.else.com, you can't add MX records for email. Some DNS providers like Cloudflare work around this with CNAME flattening at the apex, but MX records still need their own space.

Subdomains can use CNAMEs more freely since email is usually handled at the root domain level. But if you need email at a subdomain, it needs its own MX records, which means it can't also have a CNAME.

For a deeper comparison, see MX Records vs A Records.

MX Records and Email Authentication

MX records handle where incoming email is delivered (the receiving side). A completely separate set of DNS records handles whether outgoing email should be trusted (the sending side). Together, these records form the core of your domain's email infrastructure.

SPF (Sender Policy Framework) is a TXT record that lists which servers are authorized to send email from your domain. When a receiving server gets an email claiming to be from your domain, it checks your SPF record to verify the sending server is legitimate. Without SPF, anyone can send email pretending to be you. Check yours at spfrecordcheck.com.

DKIM (DomainKeys Identified Mail) uses cryptographic signatures. Your mail server signs every outgoing message with a private key. The public key is published in a DNS TXT record. Receiving servers use the public key to verify the signature, proving the message wasn't tampered with in transit and really came from your domain. Test your DKIM setup at dkimtest.com.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together. It tells receiving servers what to do when an email fails authentication: reject it, quarantine it, or let it through. It also sends you reports about who's sending email using your domain. Verify your policy at dmarcrecordchecker.com.

A properly configured domain needs all four: MX records for receiving, SPF for send authorization, DKIM for message integrity, and DMARC for enforcement and reporting. Missing any one of these creates a gap, either in delivery or in security.

See MX Records and Email Security for a detailed look at how these records work together.

TTL and Propagation

When you change MX records, the change doesn't take effect instantly. This is one of the most misunderstood aspects of DNS, and it causes real problems during email provider migrations.

How DNS Caching Works

DNS servers around the world cache your records to reduce lookup times. When a DNS server resolves your MX records, it stores the result for the duration specified by the TTL (Time to Live) value. During that window, any subsequent lookups get the cached result, even if you've changed the records at your DNS provider.

This means there's a gap between when you make a change and when every DNS server worldwide has the new values. The length of this gap is determined by your TTL.

TTL Values and Their Trade-offs

High TTL (e.g. 86400 seconds / 24 hours) means DNS servers cache your records for a full day. This reduces the number of DNS queries hitting your nameservers, but it also means changes can take up to 24 hours to propagate globally. If you make a mistake, you're stuck with it for up to a day.

Low TTL (e.g. 300 seconds / 5 minutes) means changes take effect quickly, within minutes rather than hours. But it increases DNS query volume and can slightly increase email delivery latency as DNS lookups happen more frequently.

Moderate TTL (e.g. 3600 seconds / 1 hour) is a good default for normal operation. Fast enough that accidental changes don't linger too long, but infrequent enough to keep DNS traffic reasonable.

The Migration Playbook

When you need to change MX records (whether switching email providers, adding a backup server, or correcting a mistake), follow this sequence:

1. Lower the TTL to 300 seconds at least 24-48 hours before the planned change. You need to wait for the old, high TTL to expire before the low TTL takes effect.
2. Wait for the old TTL period to pass. If your TTL was 86400 seconds (24 hours), wait at least 24 hours after lowering it.
3. Make the MX record change. Remove old records, add new ones.
4. Verify using an MX lookup that the new records are visible. Check from multiple locations if possible.
5. Send test emails from external accounts to confirm delivery.
6. Monitor for 24-48 hours to ensure no issues.
7. Raise the TTL back to your normal value (3600 seconds is a good default).

Skipping step 1 is the most common mistake. If you change your MX records while the TTL is still 86400 seconds, some DNS servers will serve the old records for up to 24 hours. During that time, some email goes to your old provider and some to your new one.

For the full details on propagation timing and how to monitor it, see How Long Do MX Records Take to Propagate?. For TTL-specific best practices, see MX Record TTL Best Practices.

Troubleshooting MX Record Problems

When email stops working, MX records are one of the first things to check. Here's a systematic approach to the most common problems, what causes them, and how to fix them.

Missing MX Records

Symptoms: All email to your domain bounces immediately. Senders get an error like "Host or domain name not found" or "No MX record found."

Common causes:

• New domain where email was never configured
• Accidental deletion during DNS cleanup
• Domain transfer where records weren't migrated
• DNS provider change where records weren't recreated

Fix: Add MX records for your email provider. If you're not sure which values to use, check MX Records by Email Provider. Run an MX lookup to confirm the records are visible after adding them.

MX Hostname Doesn't Resolve

Symptoms: MX records exist and look correct, but email still bounces. Error messages mention the hostname being unresolvable.

Common causes:

• The hostname in the MX record doesn't have an A record
• Typo in the hostname (e.g. aspmx.i.google.com instead of aspmx.l.google.com, a lowercase L)
• The A record for the mail server was deleted or changed

Fix: Look up the hostname in your MX record separately. Does mail.example.com resolve to an IP address? If not, add or fix its A record. If the hostname is your email provider's server (like aspmx.l.google.com), double-check the spelling character by character. Copy-paste from the provider's documentation rather than typing it manually.

Stale Records After Provider Change

Symptoms: Some emails arrive at your new provider, but some go to the old one. Delivery is inconsistent, and the same sender might reach you sometimes and not others.

Common causes:

• Old MX records weren't removed when switching providers
• Old MX records have a lower priority number (higher priority) than the new ones
• DNS caching is serving a mix of old and new records during propagation

Fix: Remove all MX records from your previous provider. There should be only one set of MX records: your current provider's. Run an MX lookup to confirm no stale records remain. If you just made the change, wait for DNS propagation (based on your TTL) and check again.

Wrong Priority Order

Symptoms: Email works, but all traffic goes to your backup server instead of your primary. Or email routes to an unintended server.

Common causes:

• The backup server has a lower priority number (meaning higher priority) than the primary
• Priorities were entered in the wrong order during setup
• A well-meaning change to priorities accidentally inverted the hierarchy

Fix: Remember that lower numbers = higher priority = tried first. Your primary server should have the lowest priority number. Run an MX lookup and verify the priority values are in the correct order.

Port 25 Blocked

Symptoms: MX records are correct, hostnames resolve to valid IPs, and the mail server is running, but email delivery fails with timeout errors.

Common causes:

• Your hosting provider blocks inbound connections on port 25
• A firewall rule is blocking SMTP traffic
• Your ISP blocks port 25 (common on residential connections)
• The mail server process isn't listening on port 25

Fix: Test port 25 connectivity with telnet mail.example.com 25 or an online port checker. If the port is blocked, check your hosting provider's firewall settings, security groups, or contact their support. Some providers require you to explicitly open port 25 for mail servers.

MX Record Timeout

Symptoms: Intermittent delivery failures. Some emails arrive, others time out. The problem may come and go.

Common causes:

• The mail server is overloaded and responding slowly
• Network issues between the sender and your mail server
• DNS resolution is slow due to nameserver problems
• The server is geographically distant from most senders

Fix: Check your mail server's load and response times. Verify DNS resolution speed for your MX hostnames. Consider adding geographically distributed backup MX servers if your primary is in a single location. See MX Record Timeout for detailed diagnostics.

For a comprehensive troubleshooting walkthrough that goes beyond MX records to cover the full email delivery chain, see Not Receiving Emails?.

Checking and Monitoring MX Records

How to Check MX Records

The quickest way to check your MX records is to use our free MX Record Checker. Enter any domain to see all configured mail servers and their priorities. The tool queries DNS in real time, so you see exactly what the rest of the internet sees.

You can also check MX records from the command line:

Using dig (Linux/macOS):

dig mx example.com +short

This returns just the priority and hostname pairs:

10 mail.example.com.
20 backup.example.com.

Using nslookup (Windows/Linux/macOS):

nslookup -type=mx example.com

Using PowerShell (Windows):

Resolve-DnsName -Name example.com -Type MX

Each tool shows the same information: the domain's MX records with priority values and mail server hostnames. The web-based checker is easiest for quick lookups, but command-line tools are useful for scripting and automation.

For the full walkthrough including how to interpret the results, see How to Check MX Records.

Identifying Your Email Provider from MX Records

Your MX records tell you exactly who handles your email. The mail server hostnames reveal the provider:

• Hostnames containing google.com or googlemail.com → Google Workspace
• Hostnames containing outlook.com or protection.outlook.com → Microsoft 365
• Hostnames containing zoho.com → Zoho Mail
• Hostnames containing protonmail.ch → ProtonMail
• Hostnames containing messagingengine.com → Fastmail

This is useful when you've inherited a domain and don't know how email is configured, or when you're auditing a client's infrastructure. Run an MX lookup and the hostnames will tell you immediately.

See Who is My Email Provider? for the complete list of provider hostname patterns.

Why Continuous Monitoring Matters

Checking MX records once is good. Monitoring them continuously is essential. Here's why:

MX records can change without your knowledge. A DNS admin makes an unrelated change and accidentally deletes an MX record. A domain auto-renewal fails and records are lost. A malicious actor gains access to your DNS provider and redirects your email. These scenarios happen more often than you'd think, and the result is always the same: email stops arriving, and no one notices until someone asks "did you get my message?"

Problems are time-sensitive. Every hour your MX records are wrong is an hour of lost email. Unlike a website outage where visitors can try again later, a bounced email is often gone for good. The sender gets a bounce notification, assumes you don't have a working email address, and moves on.

Manual checks don't scale. If you manage one domain, you might remember to check it occasionally. If you manage 10, 50, or 100 domains (common for agencies and IT teams), manual checking is impossible. Automated monitoring checks every domain, every day, and alerts you the moment something changes.

The Email Deliverability Suite monitors your MX records alongside SPF, DKIM, DMARC, and blacklist status. It checks daily and sends alerts when anything changes, so you can fix problems before they affect email delivery.

Advanced Topics

Null MX Records

A null MX record explicitly declares that a domain does not accept email. Defined in RFC 7505, a null MX uses priority 0 with a single dot (.) as the hostname:

example.com.    IN    MX    0    .

This is useful for domains that should never receive mail, such as parked domains, redirect-only domains, or subdomains used exclusively for websites. Without a null MX, sending servers might try the A record fallback or keep retrying for days before giving up. A null MX causes an immediate, clean bounce with a clear error message.

Null MX is different from simply having no MX records. No records triggers unpredictable fallback behaviour. A null MX is an explicit "this domain does not accept email" signal.

See Null MX Records for implementation details.

Subdomain Email

By default, subdomains do not inherit MX records from the parent domain. This catches many people off guard. If you have MX records for example.com, email to user@support.example.com will bounce unless you also create MX records specifically for support.example.com.

This is by design in the DNS specification (RFC 1034). Each domain name is independent. example.com and support.example.com are separate names with separate record sets.

If you need email at a subdomain, you have two options: create MX records pointing to the same mail servers as your root domain (if your provider supports it), or use a different email setup for the subdomain entirely.

See MX Records for Subdomain Email for detailed setup instructions.

Backup Mail Servers

A backup MX server (sometimes called a secondary MX) stores email temporarily when your primary server is down, then forwards it when the primary recovers. This is more sophisticated than simple failover; the backup server holds messages in a queue rather than delivering them to a separate mailbox.

Backup MX is less common than it used to be. Major email providers like Google Workspace and Microsoft 365 handle redundancy internally, as their multiple MX records point to their own globally distributed infrastructure, not to separate backup servers. For self-hosted email, however, a backup MX server can prevent message loss during outages.

See MX Backup Email Server for when backup MX makes sense and how to configure it.

MX Record TTL Best Practices

TTL (Time to Live) values control how long DNS servers cache your MX records. Getting TTL right matters most during migrations. Too high and you're stuck with old records for hours or days; too low and you're generating unnecessary DNS traffic.

The recommended approach:

• Normal operation: TTL of 3600 seconds (1 hour). A good balance between caching efficiency and change responsiveness.
• Before a planned change: Lower to 300 seconds (5 minutes) at least 24-48 hours in advance.
• After the change: Keep low for 24-48 hours while monitoring, then raise back to 3600.
• Emergency fix: You can change records immediately, but some servers will serve cached values until the old TTL expires. There's no way to force a cache flush on remote DNS servers.

See MX Record TTL Best Practices for the full playbook.

Email Delivery After Domain Transfer

Transferring a domain between registrars is one of the highest-risk moments for email continuity. If MX records aren't preserved during the transfer, email bounces until you reconfigure them, and you might not even notice for hours or days.

The key is preparation: document your current MX records before the transfer, lower your TTL, verify records immediately after the transfer completes, and have your email provider's MX values ready to re-enter if needed.

See MX Records After Domain Transfer for a step-by-step migration checklist.

References

• RFC 1035: Domain Names - Implementation and Specification - Defines the DNS record format, including MX records
• RFC 1034: Domain Names - Concepts and Facilities - Defines DNS architecture, including the CNAME restriction and domain name hierarchy
• RFC 5321: Simple Mail Transfer Protocol - Specifies SMTP delivery, MX lookup procedures, priority handling, and the A record fallback behaviour
• RFC 7505: A "Null MX" No Service Resource Record - Defines the null MX record for domains that do not accept email
• Google Workspace MX record values - Official Google MX setup documentation
• Microsoft 365 DNS records - Official Microsoft 365 DNS configuration guide

Start Monitoring Your MX Records

Your MX records are the single point that determines whether email reaches your domain. A misconfiguration, an expired hostname, or an unauthorized change can silently break email delivery for hours before anyone notices.

The Email Deliverability Suite monitors your MX records daily alongside SPF, DKIM, and DMARC. It checks that your records exist, that hostnames resolve, that priorities are correct, and that nothing has changed unexpectedly. When something breaks, you get an alert, not an email from a customer asking why they can't reach you.