MX Record Priority Explained: 7 Setups Compared

How MX Priority Actually Works

When a sending mail server looks up your domain's MX records, it gets a list of servers and their priority values. It sorts them by priority—lowest number first—and attempts delivery starting at the top.

If the first server accepts the connection, delivery happens there. The other servers never get contacted. If the first server is unreachable (connection timeout, host down, port closed), the sender moves to the next-lowest priority and tries again.

This is failover, not load balancing. All mail goes to one server unless that server is unavailable. The priority value is a preference order, not a weight or distribution ratio.

Single Mail Provider Setups

Most small to mid-size domains use one mail provider—Google Workspace, Microsoft 365, or a hosting company's mail service. The provider gives you a list of MX records to add, each with a priority value already assigned.

Google Workspace typically uses five MX records with priorities 1, 5, 5, 10, and 10. Microsoft 365 uses a single record at priority 0 or 10 depending on the plan. These values are chosen by the provider to control failover within their infrastructure.

You should use the exact values the provider specifies. Changing them breaks their intended failover order and can route mail to servers not ready to accept it. In tickets I handled, customers who modified Google's priorities to create even spacing (10, 20, 30, 40, 50) sometimes saw delivery delays because Google's infrastructure expects the 5/5/10/10 pattern for internal routing decisions.

• Use provider-supplied priority values without modification
• Gaps between values (1, 5, 10 vs 1, 2, 3) don't affect performance
• Equal priority values in single-provider setups (like Google's two servers at priority 5) work because the provider controls all listed servers

Backup MX Server Configurations

A backup MX server accepts mail when your primary server is down, then queues or relays it to the primary once it's reachable again. This prevents mail loss during outages.

Set the backup priority significantly higher than the primary. If your primary is at 10, use 50 or 100 for the backup. Small gaps (10 and 15) work functionally but leave no room to insert another server later without renumbering everything.

The backup must be configured to relay mail to your primary domain, not deliver it locally. Otherwise you'll have mail split across two servers with no way to consolidate it. Check that the backup isn't listed as an open relay—some attackers scan for backup MX servers with weak relay controls.

• Primary at 10, backup at 50 is a standard pattern
• Backup server should queue mail for 4-5 days before bouncing
• Verify relay rules with a test message during a planned outage

Multi-Provider Split Configurations

Some organizations want to split mail between two providers—maybe Google Workspace for executives and a self-hosted server for bulk mail. This requires routing based on recipient address, not MX priority.

MX records can't route by recipient. If you list Google's servers at priority 10 and your self-hosted server at priority 20, all mail goes to Google first. Google then decides what to do with it based on whether the recipient exists in their system.

The usual solution is to set up recipient routing at the lower-priority provider to forward specific addresses to the other provider, or use subdomains (mail.example.com vs bulk.example.com) with separate MX records. Trying to load-balance with equal-priority MX records produces unpredictable results because sending servers pick randomly, and your providers don't coordinate delivery.

Equal Priority and Load Distribution Myths

RFC 5321 states that when multiple MX records have the same priority, the sending server should select one randomly. In theory, this spreads mail across servers.

In practice, it's a mess. Some sending servers always pick the first record alphabetically by hostname. Others cache the random choice and send all mail to the same server for hours. Mail providers like Google and Microsoft explicitly document that equal-priority MX records are unsupported or unreliable.

If you need actual load distribution, put multiple mail servers behind a single hostname and use DNS round-robin or a load balancer at the network layer. Or use a single MX hostname that resolves to an IP handled by your provider's load balancing infrastructure. MX priority won't give you even distribution.

• Equal priorities produce random selection, not even distribution
• Sending server implementations vary—some ignore the random rule
• Most mail providers don't support equal-priority setups in their documentation

Common Misconfigurations and Fixes

Setting all MX records to the same priority accidentally is the most frequent mistake. Check your DNS zone after saving changes—some control panels default new records to priority 10.

Another issue: leaving an old provider's MX records in place with higher priority values after migrating. Mail still flows to the new provider (lower priority), but if the new provider has an outage, senders fall back to the old servers. If those old servers reject the mail or no longer exist, delivery fails.

Forgetting to update MX records after changing your mail server's IP address doesn't directly break MX priority, but it causes the same symptom—mail bounces—so it gets reported as a priority problem. Verify the hostname in each MX record still resolves to a working IP before adjusting priority values.

• Run dig example.com MX to see current records and priorities
• Remove MX records for decommissioned mail servers
• Test with external tool (MXToolbox or similar) after DNS changes
• Wait for TTL expiration (usually 1-4 hours) before declaring a fix broken

Choosing Priority Values for Your Setup

Start your primary server at 10. It's the de facto standard and leaves room below (0-9) if you ever need to add a higher-priority server temporarily.

Space additional servers by 10-20 points (10, 20, 40, or 10, 30, 50). This leaves room to insert a server between existing ones without renumbering everything. If you use 10, 11, 12, adding a server between the first two means changing the rest.

For most single-provider setups, use the values the provider specifies. For backup MX servers you control, put them at 50 or higher. For testing a new mail server before making it primary, add it at a high priority (90), test manually by sending to that server's IP directly, then lower its priority to 5 and raise the old primary to 15 once you've confirmed it works.