MX Record Setup: Step-by-Step Guide

What Is an MX Record?

MX stands for Mail Exchange. An MX record is a DNS entry that tells sending mail servers where to deliver messages destined for your domain. Without MX records (or with bad ones), mail sent to you@yourdomain.com is rejected, deferred, or routed to the wrong server — every inbound communication is at risk.

MX records live at the apex of your domain (the same place you publish your SPF record) — for yourdomain.com, the MX record sits at the host @. Other DNS record types map directly from a name to a value; MX records have a two-piece value: a priority (a small integer) and a destination hostname (the mail server that accepts mail for your domain).

A minimal MX configuration looks like this:

yourdomain.com. 3600 IN MX 10 aspmx.l.google.com.

This single record says "deliver mail for yourdomain.com to aspmx.l.google.com (a Google Workspace MX host) with priority 10." Real production domains publish several — typically a primary plus one or two alternates for redundancy.

For a refresher on how MX fits alongside the rest of the authentication stack, read the SPF, DKIM, and DMARC Explained → guide.

How MX Priority Works

When a domain publishes more than one MX record, the sender picks the one with the lowest priority number (highest preference) first. If the primary server is unreachable, the sender falls back to the next-lowest priority, and so on. The convention most providers use:

• Priority 10 — the primary mail server. The simplest, most common value.
• Priority 20 — the secondary; receives inbound mail when priority 10 is unreachable.
• Priority 30+ — additional backups. Common when Google Workspace publishes multiple alternates (aspmx.l.google.com at 10, alt1.aspmx.l.google.com at 20, alt2.aspmx.l.google.com at 30, etc.).

The key intuition: lower number = preferred. A common misconfiguration is to set the primary at priority 20 and the backup at priority 10, which routes inbound mail to the backup first by mistake. The number reads like a ranking column, but functionally it is "ordered low-first."

Step 1: Decide Where Inbound Mail Should Land

Before you publish MX records, decide which mail server receives inbound mail for your domain. The four common destinations:

• Google Workspace. The set of MX hostnames aspmx.l.google.com, alt1.aspmx.l.google.com, alt2.aspmx.l.google.com, alt3.aspmx.l.google.com, alt4.aspmx.l.google.com at priorities 1, 5, 5, 10, 10.
• Microsoft 365. One MX record pointing at yourdomain-com.mail.protection.outlook.com at priority 0 (Microsoft’s MX is internally redundant — a single record is fine).
• Fastmail. in1.fastmail.com at priority 10 and in2.fastmail.com at priority 20.
• Self-hosted mail server. Your own hostname at a low TTL priority, plus a backup MX at a separate provider for redundancy. Treat the backup as a queue that forwards into your primary when the primary comes back up — most backup MX services queue, not store-and-forget.

Pick ONE destination per subdomain. Multiple competing destinations means mail is split unpredictably between inboxes — customers, vendors, and partners will not know where their messages land.

Step 2: Publish the MX Records at the Apex

MX records live at the apex of your domain (the host @, the same place you publish your SPF TXT record). The exact UI varies per DNS provider:

• Cloudflare → DNS → Records → Add → Type MX, Name @, Mail server the destination hostname, Priority the priority value. Add one record per MX server.
• Route 53 → Hosted zones → Create record → Simple routing → Record type MX, Name the apex, Value the destination hostname with priority. One record per server.
• Google Cloud DNS → Record sets → Add record set → MX, Name the apex (use @ for the root), Mail exchange the destination hostname, Preference the priority value.
• GoDaddy / Namecheap → DNS Management → Add → Type MX, Host @, Points to the destination hostname, Priority the priority value.

DNS propagation for MX records is typically 5–30 minutes, but allow up to 24 hours for full propagation across global resolvers. Lower TTL (300 seconds) during bring-up so a wrong record can be corrected without waiting a day; raise TTL to a normal value (3600–14400 seconds) once the configuration is verified.

Step 3: Publish a Backup MX for Redundancy

Every production domain should have a backup mail server reachable via MX. When the primary is unreachable — planned maintenance, an outage, a regional incident — inbound mail queues at the backup rather than bouncing. The three common patterns:

• Use the provider’s built-in alternates. Google Workspace, Fastmail, and most managed providers publish alternates already ( alt1, alt2, alt3) — publish them all and the provider runs the redundancy for you.
• Add a second provider as a cold-standby. If you are self-hosted, publish your primary MX at priority 10 and a small backup-provider MX (a queue-only service) at priority 20. The backup queues mail and forwards it when your primary is reachable again.
• Plan a long recovery window. Backup MX is for short outages (minutes to a few hours), not for multi-day disasters. Most backup providers retry for 5–7 days before giving up and bouncing the queued mail — set your expectations to that horizon.

A single MX record is a single point of failure. If that server is down, every inbound mail is rejected with a 4xx SMTP response and held by the sender until retry budgets expire — and beyond that, lost.

Step 4: Verify MX with `dig MX`

Once the records have propagated, verify from any external resolver. The canonical command:

dig MX yourdomain.com +short

The output should list every MX record you published, sorted by priority (lowest number first), each with the priority and destination hostname:

10 aspmx.l.google.com.
20 alt1.aspmx.l.google.com.
30 alt2.aspmx.l.google.com.

Each destination hostname should resolve to a real IP — verify with dig A aspmx.l.google.com +short for the primary, and the same for every alternate. A hostname that resolves to nothing or to a generic parking page means the MX is pointing the wrong way.

Use nslookup -type=MX yourdomain.com on Windows to confirm the same. Run a real inbound mail test from a Gmail or Outlook.com account before considering the configuration done.

For the symmetric half of this story — proving the IP itself has a hostname — read the Reverse DNS (PTR) Record Setup → guide.

Common MX Errors and Fixes

Five patterns account for almost every MX problem senders run into. Each has a deterministic fix.

Wrong priority order (backup ranked ahead of primary)

The primary MX is published at priority 20 and the backup at priority 10. Mail flows to the backup first, which usually queues rather than delivers immediately. Fix: publish the primary at the lowest priority number (10 is conventional) and the backup at a higher number (20).

MX hostname does not resolve

The destination hostname in the MX record is typed wrong, or it has been deprecated by the provider, or it is a CNAME chain that fails to resolve. Senders see a hard bounce or a 4xx deferral. Fix: re-check the destination hostname against your provider’s published MX documentation, run dig A <hostname> to confirm it resolves, and update to the current hostname.

Missing MX record entirely

No MX record is published at the apex. Incoming mail is rejected with a "no MX record for domain" error or, in some fallback behaviour, attempted at the domain’s A record (which almost always fails). Fix: publish at least one MX record at yourdomain.com pointing to your provider’s mail server hostname.

MX pointed at the wrong subdomain or third-party domain

The MX record points at a hostname like webmail.yourdomain.com that resolves to your website server, or at a domain you no longer own. Mail that does get delivered lands in the wrong place or never lands at all. Fix: re-publish the MX at the provider’s actual mail exchange hostname (e.g. aspmx.l.google.com for Google Workspace).

Single MX record (no redundancy)

The domain publishes exactly one MX record pointing at a single mail server. When that server is unreachable, every inbound message bounces after the sender’s retry window expires. Fix: publish a backup MX record at a higher priority value (20 or higher), pointing at the provider’s alternate mail server or a queue-and-forward backup service.

MX, SPF, DKIM, and DMARC: Putting It Together

MX and SPF/DKIM/DMARC cover opposite ends of the mail flow — MX handles inbound delivery, the other three handle outbound authentication, and a complete auth posture publishes both. Here is the canonical layout for a single domain at yourdomain.com that sends mail via Google Workspace (illustrative — substitute your provider):

yourdomain.com.  3600  IN  MX    10  aspmx.l.google.com.
yourdomain.com.  3600  IN  MX    20  alt1.aspmx.l.google.com.
yourdomain.com.  3600  IN  MX    30  alt2.aspmx.l.google.com.
yourdomain.com.  3600  IN  TXT   "v=spf1 include:_spf.google.com -all"
google._domainkey.yourdomain.com.  3600  IN  TXT  "v=DKIM1; k=rsa; p=<public-key>"
_dmarc.yourdomain.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com"

Five record types at three hostnames — published once, kept current — and every direction of mail flow works:

• Inbound delivery — the three MX records route incoming mail to Google Workspace mail servers, in priority order.
• Outbound authentication — SPF at the apex authorises Google Workspace to send, DKIM signs every outgoing message, and DMARC ties both to the visible From: header.
• Reporting — the DMARC rua= address receives daily RUA aggregate reports from Google, Microsoft, and Yahoo, so you can confirm every sender meets alignment.

Want to inspect what your DNS publishes right now? Run dig MX yourdomain.com +short, the validator below, or a dig TXT yourdomain.com +short to read the SPF record at the same apex.

MX Best Practices for Production Domains

• Publish at least two MX records. One primary and one backup covers the overwhelming majority of real outage scenarios. Two alternates (primary + backup at the primary provider, plus a queue-and-forward backup service) cover the long tail.
• Lower number is higher priority. Treat priority as an ordering, not a score — even if priority=5 looks like a higher score than priority=10, the 5-value host is what receiving servers prefer.
• Re-check with dig MX after every DNS change. Records that look right in the panel sometimes publish with formatting errors the panel hides — the resolver is the source of truth.
• Re-verify your MX hostname is current whenever you change provider. Switching mail providers is the highest-risk moment for stale MX records — the old provider’s hostnames stay resolvable and can accidentally keep receiving inbound mail for months.
• Pair MX with monitor-side visibility. A correctly configured MX still does not guarantee that mail arrives — spam filters, anti-malware layers, and recipient-side rules all act after the SMTP RCPT TO accept. Run seed-list placement tests to confirm inbound mail actually lands where you expect it to.
• Document MX-as-part-of-the-stack. MX is one of five record types that have to work together (MX, SPF, DKIM, DMARC, PTR). Maintain a one-page auth layout per domain — every record host, every value, the priority order, and the provider each piece ties to — so a deliverability incident can be diagnosed against an authoritative map.

Once MX is correct, the next step is the matching PTR record on your sending IP (Reverse DNS (PTR) Setup →) and the outbound authentication chain (SPF →, DKIM/DMARC →) so the other half of the mail flow closes the loop.