What does MX record priority mean?

MX priority is a number that tells sending mail servers which of your mail servers to try first. Lower numbers = higher priority. A server with priority 10 is tried before priority 20.

What is the best MX record priority value?

There's no single best value. Use 10 for your primary server and 20 (or higher) for backups. The absolute values don't matter — only the relative order. Priority 1 and 2 works the same as 10 and 20.

What happens if two MX records have the same priority?

Sending servers randomly pick between them, distributing load roughly evenly. This is a simple way to load-balance incoming email across multiple servers.

Do I need a backup MX record?

For most setups, no. Modern email providers (Google Workspace, Microsoft 365) handle redundancy internally. A backup MX only helps if you run your own mail servers.

Does MX priority affect email sending (outbound)?

No. MX records only control where incoming email is delivered. Outbound email is handled by your application's SMTP configuration, not MX records.

MX Record Priority Explained (With Examples)

When a domain has multiple MX records, priority determines which mail server gets tried first. Lower numbers mean higher priority. That's the core concept — the rest is configuration details.

TL;DR

MX priority = a number on each MX record. Lower = tried first.
Primary server: priority 10. Backup: priority 20.
Same priority = random selection (load balancing).
MX records only affect incoming email. They don't affect outbound sending.

How MX priority works

When someone sends an email to you@yourdomain.com, their mail server looks up your MX records:

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

The sending server tries mail1 first (priority 10). If mail1 is down or unreachable, it falls back to mail2 (priority 20).

The numbers are relative, not absolute. These two setups behave identically:

# Setup A
MX  10  mail1.example.com.
MX  20  mail2.example.com.

# Setup B — same behavior
MX  1   mail1.example.com.
MX  5   mail2.example.com.

Using increments of 10 is convention, not a requirement. It just leaves room to insert servers between existing priorities without renumbering everything.

Common MX configurations

Google Workspace

yourdomain.com.  MX  1   ASPMX.L.GOOGLE.COM.
yourdomain.com.  MX  5   ALT1.ASPMX.L.GOOGLE.COM.
yourdomain.com.  MX  5   ALT2.ASPMX.L.GOOGLE.COM.
yourdomain.com.  MX  10  ALT3.ASPMX.L.GOOGLE.COM.
yourdomain.com.  MX  10  ALT4.ASPMX.L.GOOGLE.COM.

Google uses priority 1 for the primary server, 5 for two alternates (load-balanced between them since they share priority), and 10 for two more fallbacks.

Microsoft 365

yourdomain.com.  MX  0  yourdomain-com.mail.protection.outlook.com.

Microsoft uses a single MX record with priority 0. All redundancy is handled behind their endpoint — no need for multiple records.

Single server

yourdomain.com.  MX  10  mail.yourdomain.com.

One server, one record. This is fine for most custom setups. If the server is down, sending servers will queue the email and retry for up to 5 days (per RFC 5321).

Same priority = load balancing

When two MX records share the same priority, sending servers pick randomly between them:

yourdomain.com.  MX  10  mail1.yourdomain.com.
yourdomain.com.  MX  10  mail2.yourdomain.com.

Traffic splits roughly 50/50. This is a simple way to load-balance incoming email without a dedicated load balancer. Google Workspace uses this pattern with their ALT1/ALT2 servers at priority 5.

Backup MX records

A backup MX kicks in when the primary is unreachable:

yourdomain.com.  MX  10  primary.yourdomain.com.
yourdomain.com.  MX  20  backup.yourdomain.com.

In practice, most teams using managed email providers (Google Workspace, Microsoft 365, Fastmail) don't need explicit backup MX records. The provider handles failover internally.

Backup MX records make sense when:

You run your own mail servers
Your primary server has unreliable uptime
You need a geographically distributed fallback

A misconfigured backup MX can become a spam target. Spammers sometimes bypass the primary and send directly to lower-priority servers, hoping for weaker filtering. Make sure backup servers have the same spam filtering as your primary.

How to check your MX records

Command line

# macOS / Linux
dig MX yourdomain.com +short

# Output:
# 10 mail1.yourdomain.com.
# 20 mail2.yourdomain.com.

# Windows
nslookup -type=MX yourdomain.com

Online tools

Use our deliverability checker to verify MX records along with SPF, DKIM, and DMARC in one step.

How to set MX records

MX records are configured in your domain's DNS settings. The exact interface depends on your DNS provider (Cloudflare, Route 53, Namecheap, etc.), but the fields are the same:

Field	Value
Type	MX
Name	`@` (or your domain)
Mail server	`mail.yourdomain.com`
Priority	`10`
TTL	3600 (1 hour)

After adding or changing MX records, allow up to 48 hours for DNS propagation — though most changes take effect within an hour.

MX records vs email sending

A common misconception: MX records control incoming email delivery, not outbound sending.

	Incoming (receiving)	Outgoing (sending)
Controlled by	MX records	SMTP config in your app
DNS records	MX	SPF, DKIM, DMARC
Example	Someone emails you@yourdomain.com	Your app sends a welcome email

If you're setting up email sending from your application, MX records aren't what you need. You need SPF, DKIM, and DMARC — see our email authentication guide.

Next Steps

Set up sending authentication: DKIM, SPF, and DMARC Explained
Verify your setup: Deliverability Checker
Understand email domains: What Is an Email Domain?
Start sending: Framework Guides for integration with your stack