MX Records Explained: How Email Routing Really Works

Every time someone sends you an email, their mail server performs a DNS lookup before it can deliver anything. That lookup specifically targets MX records — the DNS entries that tell the sending server which mail server accepts messages for your domain. If your MX records are missing, wrong, or pointing to a non-existent host, email delivery fails. No bounce to the sender in many cases, just a lost message. Understanding how MX records work is foundational to running any reliable business email setup.

What Is an MX Record?

An MX record (Mail Exchanger) is a DNS record type that maps a domain name to one or more mail servers. When a sending server wants to deliver email to you@yourdomain.com, it queries DNS for the MX records of yourdomain.com. The response returns one or more hostnames — the servers authorized to receive mail for that domain.

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

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

Breaking that down:

• yourdomain.com. — the domain being queried
• 3600 — the TTL (time-to-live) in seconds; how long DNS resolvers cache this record
• IN MX — the record class and type
• 10 — the priority value
• mail.yourdomain.com. — the hostname of the mail server

Understanding Priority Values

The number in an MX record is a priority (sometimes called preference). Lower numbers mean higher priority. When multiple MX records exist, the sending server tries the lowest-numbered one first.

For example:

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

With this setup, all delivery attempts go to mail1 first. If that server is unavailable or refuses the connection, the sender falls back to mail2. This is the standard pattern for primary and backup mail servers.

If two MX records share equal priority values, sending servers will split traffic between them — effectively load-balancing delivery attempts across both servers.

The Difference Between MX Records and A Records

MX records point to hostnames, not IP addresses. The hostname listed in an MX record must itself have an A record (or AAAA for IPv6) that resolves to an IP address. A common mistake is pointing an MX record directly to an IP — this is technically invalid and will cause delivery failures with many sending servers.

Equally important: MX records should never point to a CNAME. The DNS standard prohibits this combination, and while some mail servers tolerate it, many will refuse delivery to CNAME-pointed MX targets entirely. Always use a hostname with a direct A record.

Backup MX: When It Helps and When It Doesn't

A backup MX — a secondary server with a higher priority number — is intended to accept mail when your primary server is unavailable. In theory this sounds useful. In practice, it comes with a meaningful tradeoff worth understanding.

Spam senders are aware of the backup MX pattern and deliberately target secondary hosts, because those servers sometimes have weaker spam filtering than the primary. If your backup MX accepts everything and forwards it on, it can pass spam to your primary that would otherwise have been rejected.

For most modern hosted email setups, a highly available primary provider makes a backup MX unnecessary. If you do implement one, ensure it applies the same filtering rules as your primary and authenticates correctly before forwarding.

Common MX Record Mistakes

Leaving old MX records in place after a migration

When you move from one email host to another, the old MX records need to be removed — not just supplemented with new ones. Leaving both sets active splits your incoming mail between two providers, causing you to miss messages at whichever server you're no longer monitoring.

Setting TTL too high before a migration

If your MX record has a TTL of 86400 (24 hours), a change you make today won't reach all DNS resolvers for up to 24 hours. Lower your TTL to 300 seconds a day or two before any planned migration. This ensures fast propagation when you make the actual switch.

MX pointing to a non-existent host

If the hostname in your MX record doesn't resolve, delivery fails silently. This happens after server consolidations or when a hosting account lapses. Always verify that the A record for your MX target is live and resolving correctly.

Missing trailing dot in zone files

In DNS zone files, fully qualified domain names end with a trailing dot. Some DNS management interfaces add this automatically; others don't. A hostname without the trailing dot in the wrong context gets interpreted as a relative name, often producing something like mail.yourdomain.com.yourdomain.com — which obviously won't resolve to anything useful.

How to Query Your MX Records

From the command line on Linux or Mac:

dig MX yourdomain.com

On Windows:

nslookup -type=MX yourdomain.com

The response shows all MX records for your domain along with their priority values. Cross-reference these against what your email provider specifies in their setup documentation.

MX Records and Email Authentication

MX records don't directly affect your SPF, DKIM, or DMARC configuration — but they interact with those systems indirectly. Your SPF record specifies which servers are authorized to send mail for your domain. Your MX records specify which servers receive it. Understanding the difference matters: your SPF record should list your outbound sending infrastructure, not your inbound MX hosts, unless those happen to be the same servers.

See the MailDog DNS security guide for authentication setup details, or refer to the documentation for the exact MX records to configure for your MailDog account. If you're planning a migration involving MX changes, the support team can help you plan the transition to avoid gaps in delivery.