All articles DNS & Domains

MX Records Explained: How Email Routing Works and What to Do When It Breaks

SSam wallness28 Jun 2026
MX Records Explained: How Email Routing Works and What to Do When It Breaks

Every time someone sends an email to your domain, their mail server runs a DNS lookup before delivery to find out where to send it. That lookup is for your MX records — the DNS entries that tell the internet which servers accept mail for your domain. Without them, or with them misconfigured, nobody can email you.

MX records are one of the most fundamental parts of email infrastructure, but they're also one of the most misunderstood when something goes wrong. This guide explains exactly how they work and what to check when they don't.

What an MX Record Actually Is

An MX record is a DNS record type that specifies one or more mail servers responsible for accepting email on behalf of your domain. When a sender's mail server (MTA) wants to deliver mail to user@yourdomain.com, it queries DNS for your domain's MX records, gets back a list of mail server hostnames, and connects to one of them to deliver the message.

A typical MX record in a DNS zone file looks like this:

yourdomain.com.   3600   IN   MX   10   mail.yourdomain.com.

Breaking this down:

  • yourdomain.com. — the domain the record applies to
  • 3600 — the TTL in seconds (how long other servers cache this record)
  • IN MX — the record class and type
  • 10 — the priority value
  • mail.yourdomain.com. — the hostname of the mail server

Priority Values and How Backup Mail Servers Work

The number in an MX record is the priority — lower numbers are tried first. Most domains have a single MX record with a priority of 10. But you can define multiple MX records at different priorities to create redundancy:

yourdomain.com.   IN   MX   10   mail1.yourdomain.com.
yourdomain.com.   IN   MX   20   mail2.yourdomain.com.

When a sending server tries to deliver email, it tries the priority-10 server first. If that server is down or unreachable, it falls back to the priority-20 server. This is the entire basis of backup MX configuration.

If two MX records share the same priority, sending servers distribute load between them at random. This is how some providers implement load balancing — multiple servers at equal priority share incoming delivery volume.

MX Records Point to Hostnames, Not IP Addresses

This is a common point of confusion: MX records must point to a hostname (an A or AAAA record), not directly to an IP address. Putting an IP address in an MX record violates the DNS specification and most mail servers will reject or ignore it.

The hostname in your MX record then needs its own A record pointing to the actual IP of your mail server. The full delivery chain is: domain → MX lookup → hostname → A record lookup → IP address → TCP connection.

What Happens Without MX Records

If your domain has no MX records, the sending server may fall back to the domain's A record as a last resort. In practice, most modern MTAs will return a bounce rather than rely on this fallback. The result is that senders receive NDRs saying your domain doesn't accept mail — even though your mail server may be running fine.

Checking Your MX Records

You can look up your MX records from the command line on Linux or macOS:

dig MX yourdomain.com

Or on Windows:

nslookup -type=MX yourdomain.com

The output shows your current MX records, their priorities, and the TTL. If you recently changed your MX records and they're not propagating, the TTL on the old records determines the waiting period — changes won't be visible everywhere until that TTL expires. This is why managing DNS TTL values before making changes matters so much.

Common MX Record Mistakes

Trailing Dot Missing in Zone Files

In DNS zone files, hostnames must end with a trailing dot to be treated as fully qualified domain names. Without it, the hostname gets appended with the domain name, creating a malformed address. Most DNS control panels handle this automatically, but if you're editing zone files directly, check for trailing dots on every hostname.

Pointing to a CNAME

MX records cannot point to a CNAME — the DNS specification explicitly prohibits it. The MX record must point directly to an A or AAAA record. Some DNS providers will let you create this configuration without warning, but it will cause delivery failures.

Stale MX Records After Migration

After migrating to a new mail provider, organizations sometimes leave old MX records pointing at the previous provider's servers. If the old server still accepts mail, messages can get delivered to the wrong location. Always remove old MX records completely when migrating, not just add new ones.

MX Hostname Doesn't Resolve

If the hostname in your MX record doesn't have a valid A record, delivery fails. Sending servers cannot connect to a hostname that doesn't resolve to an IP address. This frequently happens after moving to a new server without updating the corresponding A record for the mail hostname.

Backup MX and Spam: A Hidden Risk

If your backup MX server accepts messages without the same spam filtering as your primary server, it creates a vulnerability. Spammers sometimes specifically target backup MX servers because they often have weaker or no filtering. If you're using a backup MX, apply the same filtering policies as your primary to both servers.

MX Records and Your Hosting Provider

When you sign up with an email hosting provider, one of the first steps is always updating your MX records to point at their servers. The exact records vary by provider and are supplied during onboarding. For MailDog mail service users, the required MX records are listed in your account dashboard.

For help with the DNS side of your email setup, MailDog's DNS security tools cover the full authentication and routing configuration. Before editing live MX records, read our guide on making DNS changes without breaking email. If you need assistance, the contact page is the fastest way to reach us.

Keep MX Simple Until You Need Complexity

Most businesses need a single MX record pointing at their mail provider's servers. Add redundancy when your provider supports it or when uptime requirements demand it. Keep your record count low, your priorities clear, and your hostnames verified — and email routing will be one less thing you ever have to think about.

Related articles