What is a DNS MX record?

An MX record is a DNS record that tells other mail systems where to deliver email for a domain. MX stands for Mail Exchanger. When someone sends a message to user@example.com, the sending mail server looks up the MX records for example.com, chooses an appropriate mail exchanger, and then connects to that server using SMTP.

MX records do not contain mailboxes, passwords, routing rules, or spam filtering logic. They are pointers. Each record names a mail host and includes a priority value. Lower priority numbers are tried first. If the preferred mail host is unavailable, the sender can try another MX record with a higher number.

A domain can have one MX record or several. A small organization may point mail to a single hosted provider. A large organization may publish multiple records for regional delivery, redundancy, or staged migration. The important point is that the MX record controls inbound mail delivery for the domain, so mistakes can interrupt email even when the website and other DNS records still work.

What an MX record looks like

An MX record has three main parts: the owner name, the priority, and the mail exchanger hostname. In a DNS zone, it may look like this:

example.com. 3600 IN MX 10 mail1.example.net.
example.com. 3600 IN MX 20 mail2.example.net.

The 3600 value is the TTL, or time to live, in seconds. It tells resolvers how long they can cache the answer. MX identifies the record type. The numbers 10 and 20 are preferences, with 10 preferred over 20. The final names are the mail hosts that should accept inbound SMTP for the domain.

The mail exchanger should be a hostname, not a raw IP address. That hostname normally has A and AAAA records so senders can resolve it to network addresses. The hostname should also be configured to receive mail for the domain; publishing an MX record alone does not create a working mail server.

Priority, redundancy, and delivery behavior

MX priority is sometimes misunderstood as load balancing. It is closer to an ordered preference list. Sending mail servers generally try the lowest-numbered available record first. If multiple MX records share the same priority, senders may distribute attempts between them, but behavior can vary.

Redundant MX records are useful only if the backup systems are genuinely ready to accept, queue, filter, and forward mail. A backup mail host that accepts messages but cannot deliver them internally can create confusing delays. A host that accepts all mail without equivalent anti-abuse controls can become a spam entry point.

For cloud email providers, the provider usually supplies the exact MX values and priorities. Copy them carefully. A typo in the exchanger hostname, an omitted trailing dot in some DNS control panels, or an old provider record left behind after migration can cause partial delivery failures.

Relationship with SPF, DKIM, and DMARC

MX records control where inbound mail goes. DKIM and DMARC cover signing and authentication policy for outbound mail. SPF, DKIM, and DMARC help receiving systems decide whether outbound mail claiming to come from the domain is authentic. They are related because they all live in DNS and affect email trust, but they solve different problems.

Changing MX records does not automatically update SPF. If a new mail provider also sends outbound mail for the domain, the SPF record may need to include that provider. DKIM keys may need to be published as TXT records under provider-specific selector names. DMARC reports may reveal whether the migration is working for outbound mail.

This distinction matters during email migrations. Teams often test inbound delivery after changing MX records and assume the project is complete, while outbound authentication remains misconfigured. The result can be delivered inbound mail but poor outbound reputation, spam placement, or failed DMARC checks.

Operational failure modes

The most visible failure is no inbound mail. This can happen if MX records are removed, point to a retired provider, or reference a hostname that no longer resolves. It can also happen when the mail server exists but rejects the domain because it has not been configured as an accepted domain.

Intermittent failure is harder to diagnose. It can occur when one of several equal-priority MX hosts is broken, when a backup accepts mail but delays forwarding, or when DNS caches still contain old records during a migration. Long TTL values can make these problems last longer after a fix.

Security failures are also possible. An abandoned third-party MX record can point mail toward a provider account the organization no longer controls. Weak backup mail exchangers can bypass filtering. Misaligned migration steps can cause users to miss password resets, invoices, legal notices, or customer support requests.

Evaluating an MX setup

Start by listing the MX records from more than one resolver. Confirm that each exchanger hostname resolves, accepts SMTP where expected, and belongs to the intended mail provider. Check that priorities match the provider's documentation or the organization's architecture.

Review the domain's SPF, DKIM, and DMARC records at the same time. They are not MX records, but email reliability and security depend on the whole set. If the organization uses separate providers for marketing, ticketing, billing, and employee mail, document which systems send mail and which systems receive it.

Test delivery from external accounts, not only from inside the same provider. Internal tests can hide routing problems because some providers short-circuit delivery within their own platform. Watch mail logs, bounce messages, spam placement, and user reports after changes.

Rollout checks for MX changes

Before changing MX records, reduce TTLs well ahead of the migration if the current TTL is long. Record the old values, the planned new values, and the expected cutover time. Make sure the destination mail platform is configured to accept the domain before DNS changes go live.

During the cutover, publish the new MX records exactly as intended and check them from multiple networks. Send test mail to different mailbox types, including shared mailboxes, aliases, distribution groups, and application-generated recipients. Keep the old mail path available until caches expire and delivery evidence is clean.

After the migration, remove stale MX records only when the new path is stable. Review outbound authentication, mail security policies, and monitoring. MX records are simple, but they sit at the front door of business email, so the safest changes are planned, observed, and reversible.

Related learning

• What is a DNS DKIM record?
• What is a DMARC DNS record?
• What is a DNS NS record?