---
title: "MX Record"
description: "An MX record tells sending mail servers which hosts accept email for a domain, and in which order to try them."
url: "https://mailmum.io/glossary/mx-record/"
---

# MX Record

An MX (Mail Exchanger) record is the DNS record that tells a sending server
which hosts accept mail for a domain, and in which order to try them. It is the
first lookup in every delivery attempt: before a message can be sent to
`someone@example.com`, the sending server has to ask what handles mail for
`example.com`.

```sh
$ dig +short MX example.com
10 mx1.example.net.
20 mx2.example.net.
```

## How is the priority interpreted?

The number is a preference, and **lower wins**. A sending server tries priority
10 first and falls back to 20 only if the first is unreachable. Equal
priorities are used round-robin, which spreads load rather than providing
fallback.

This is how email achieves redundancy without
[anycast](https://mailmum.io/glossary/anycast-routing/): several independent, separately addressed
[mail transfer agents](https://mailmum.io/glossary/mail-transfer-agent-mta/), with the sending
server choosing between them and retrying on failure. The resilience lives in
the protocol rather than in the routing table.

A secondary MX is only useful if it can actually deliver onward and knows which
recipients exist. A backup that accepts everything and discovers later that the
address is invalid becomes a [backscatter](https://mailmum.io/glossary/backscatter/) source, which
is why unmaintained secondary MX hosts are a favourite target for spammers.

## What if a domain has no MX record?

The sending server falls back to the domain's A or AAAA record and attempts
delivery there. This implicit fallback still works, but relying on it is
fragile: it couples your mail routing to wherever your website happens to be
hosted.

If a domain should never receive mail, say so explicitly with a null MX
([RFC 7505](https://www.rfc-editor.org/rfc/rfc7505)):

```txt
example.com.  3600  IN  MX  0 .
```

A single dot as the target, at priority 0, tells senders to reject immediately
rather than queue and retry for five days. This belongs on every domain you own
that only exists for redirects, or for brand protection.

## What are the common MX mistakes?

* **Pointing an MX at a CNAME.** Not permitted — the target of an MX
  record must be a hostname with an A or AAAA record. Some senders tolerate it,
  others do not, and the failures are intermittent and hard to trace.
* **Using an IP address as the target.** Also invalid. The value must be a
  hostname.
* **A missing trailing dot** in a zone file, turning `mx1.example.net` into
  `mx1.example.net.example.com`.
* **An MX host with no matching [PTR record](https://mailmum.io/glossary/pointer-record-ptr/).**
  Inbound delivery still works, but the same host sending outbound will fail the
  forward-confirmed reverse DNS check described under
  [hostname](https://mailmum.io/glossary/hostname/).
* **Forgetting the secondary after a migration,** leaving an old server listed
  that still accepts mail and silently drops it.

## How do MX lookups show up in mail logs?

A failed MX lookup is one of the most common reasons a message sits in the
[queue](https://mailmum.io/glossary/email-queue/):

```txt
(Host or domain name not found. Name service error for name=gsmail.com
type=MX: Host not found, try again)
```

That is a temporary DNS failure, so the message is deferred rather than bounced
— the recipient domain may be misspelled, or its DNS may genuinely be
down. If many unrelated destinations show this at once, the problem is your own
resolver rather than theirs.

## How do you check your MX setup?

```sh
$ dig +short MX example.com
10 mx1.example.net.

$ dig +short A mx1.example.net
192.0.2.25

$ dig -x 192.0.2.25 +short
mx1.example.net.
```

All three should agree: the MX names a host, the host resolves to an address,
and the address resolves back to the same name. Then confirm the host actually
answers on port 25 — an MX record pointing at a machine that no longer
runs an [SMTP](https://mailmum.io/glossary/simple-mail-transfer-protocol-smtp/) service defers
every message sent to the domain for five days before anyone finds out.

## Related reading

* [Manage Postfix mail server queues like a
  pro](https://mailmum.io/posts/manage-postfix-mail-server-queues/) — where a failed MX
  lookup ends up, and how to inspect it.
* [Monitoring Postfix email queue and add push
  notifications](https://mailmum.io/posts/monitoring-postfix-email-queue-with-push-notifications/)
  — alerting on the queue growth a broken MX record causes.