Glossary term
MX records: how inbound mail finds your domain
What an MX record is
An MX (Mail Exchange) record is the DNS record that names the servers willing
to accept email for your domain. When any mail server on the internet wants to
deliver a message to someone@yourdomain.com, its first move is an MX lookup
on yourdomain.com — the answer tells it where to connect.
A typical set of MX records for a Google Workspace domain:
yourdomain.com. 3600 IN MX 1 aspmx.l.google.com.
yourdomain.com. 3600 IN MX 5 alt1.aspmx.l.google.com.
yourdomain.com. 3600 IN MX 5 alt2.aspmx.l.google.com.
Each record pairs a preference number with a mail server hostname. Lower preference wins: senders try the priority-1 host first and fall back to the 5s only if it is unreachable. The behavior is defined in RFC 5321 alongside the rest of SMTP.
MX records govern inbound mail only. This trips people up constantly: your MX records can point at one provider (where your team reads mail) while your newsletters go out through an entirely different platform. Outbound authorization is SPF and DKIM territory; MX is the receiving address plate on your door.
How an MX record differs from an A record
An A record maps a hostname to an IP address — general-purpose DNS plumbing used for websites, APIs, anything. An MX record answers one specific question: "who accepts mail for this domain?" And it answers with a hostname, not an IP. That hostname then needs its own A (or AAAA) record to resolve to an address.
The indirection is deliberate and load-bearing. Because MX points to a name, your mail provider can renumber its servers without every customer editing DNS, and a domain can delegate mail handling to infrastructure it does not own — which is exactly what every hosted-mailbox arrangement is.
The specification is explicit on two related points that DNS panels let you violate anyway: an MX record must not point to an IP address literal, and it must not point to a CNAME. Both misconfigurations mostly work with lenient senders, then fail unpredictably with strict ones — the worst kind of breakage, because your own test messages from a forgiving provider deliver fine.
If a domain has no MX record at all, RFC 5321 tells senders to fall back to the domain's A record and attempt delivery there. This "implicit MX" rescue keeps ancient configurations limping along, but running mail on a fallback behavior is not a configuration, it is an accident that has not happened yet.
How an MX record works
The delivery sequence, from the sending server's perspective:
- Extract the domain from the recipient address.
- Query DNS for the domain's MX records.
- Sort by preference, lowest first. Equal preferences are used in random order, which doubles as load balancing.
- Resolve the chosen hostname to an IP, connect on port 25, and start the SMTP conversation.
- If the connection fails, move down the list. If all fail, queue and retry later — for hours or days — before bouncing the message back to the sender.
Preference numbers only rank; their absolute values mean nothing. 1/5/10
and 10/50/100 behave identically. The backup entries exist for resilience:
when the primary is down, mail flows to the secondary, which typically queues
and forwards when the primary recovers.
One special case worth knowing: a domain that never receives mail can say so
explicitly with a null MX (RFC 7505) — a single record with preference 0
and a . target:
yourdomain.com. 3600 IN MX 0 .
Senders that understand it fail immediately with a clear error instead of retrying for days. Publishing null MX on parked domains and pure web domains is basic hygiene; it also removes those domains as plausible spoofing targets when combined with a restrictive SPF record.
You can see any domain's records, preferences and resolution with the MX lookup tool, or check MX alongside SPF, DKIM and DMARC in one pass with the email DNS check.
MX records and your deliverability
Strictly speaking, MX records handle receiving, and deliverability is about sending. The connection is real but indirect — and worth understanding, because "our MX is fine, we get mail" hides several sender-side effects.
Some receivers check your MX before accepting your mail. A common anti-spam heuristic: does the sending message's From domain accept replies? A domain with no MX (and no A fallback) looks like a fire-and-forget spam domain, and some filters score it accordingly. Sending from a domain that cannot receive is a self-inflicted reputation handicap — and it also breaks every reply, unsubscribe confirmation and out-of-office exchange your recipients attempt.
Broken MX silently destroys feedback channels. Bounce processing, reply
handling and abuse mailboxes (postmaster@, abuse@) all depend on inbound
mail working. A misconfigured MX means your list-hygiene pipeline runs blind
while everything appears normal on the outbound side.
Verification and challenge flows. Address-verification probes and some challenge-response systems connect to your MX as part of validating your domain. Timeouts and refusals there degrade you invisibly.
None of this earns placement points when correct. Like most DNS hygiene, MX correctness is a threshold: nobody rewards you for clearing it, and various systems penalize you for missing it.
Limitations and failure modes
The migration-day gap. The classic MX incident: a company switches mail providers, updates the MX records, and finds out hours later that mail is bouncing — the old provider was deactivated before DNS TTLs expired, or one secondary record still points at the decommissioned system, or the new provider was never told to expect the domain. During a migration, verify from outside your network, keep both systems accepting mail through the overlap, and lower the TTL well before the switch, not during it.
Pointing MX at a CNAME. Prohibited by the specification, tolerated by some senders, refused by others. It typically enters a zone via a copy-paste from a hosting panel that uses CNAMEs for everything. The fix is mechanical: point MX at a hostname with a direct A record.
Pointing MX at an IP literal. Same category. Some sending implementations quietly cope; strict ones treat the record as unusable.
Stale backup MX. A secondary record pointing at a server that no longer runs mail software produces intermittent, maddening symptoms: mail delivers fine except during primary outages — precisely when the backup matters — or except from the fraction of senders that hit the dead secondary first after a transient primary refusal.
The spam-magnet backup. A backup MX that accepts mail with weaker filtering than the primary becomes the entry point of choice for spammers, who deliberately target the highest-preference (least preferred) record. If you run your own backup MX, it needs recipient validation and filtering parity with the primary — or you are better off without one, letting senders' own retry queues provide the resilience.
Wildcard and inherited records. Wildcard DNS entries can hand every
subdomain an MX record you never intended, quietly making
anything.yourdomain.com a deliverable address and a spoofing surface.
Related terms
SMTP, SPF record, PTR record, hard bounce, soft bounce, greylisting, list hygiene.
Frequently asked questions
How do I check my domain's MX records?
Run the domain through the MX lookup, which shows every
record, its preference, and whether the target hostname resolves. From a
terminal, dig MX yourdomain.com gives the raw answer.
What does MX priority mean, and which number wins? The lower number wins. Senders try the lowest-preference host first and use higher-numbered records only as fallbacks. The absolute values are meaningless; only the ordering matters.
Do MX records affect my outgoing email? Not directly — outbound mail never consults your own MX. Indirectly, yes: some receivers distrust From domains that cannot accept mail, and replies, bounces and verification probes all need your inbound path working.
Can a domain send email without an MX record? Yes. Sending is governed by SPF, DKIM and your outbound infrastructure. But a sending domain that cannot receive scores as suspicious with some filters and breaks every reply — give sending domains a working inbound path.
How many MX records should I have? Whatever your mail provider specifies — no more, no fewer. Hosted providers publish their exact required set. Records left over from a previous provider are the most common surplus, and they cause real misdelivery.
What is a null MX record?
MX 0 . — an explicit statement that the domain accepts no mail, defined in
RFC 7505. Publish it on domains that genuinely never receive, so senders
fail fast instead of retrying for days.
After any provider change or DNS edit, check the records from the outside rather than trusting the panel — the email DNS check shows your MX together with the rest of your mail DNS in one view.