Fix MX Priority Misconfigured (Wrong Failover Order)

What's happening

MX records carry a priority value (also called preference) that controls which server sending MTAs try first. RFC 5321 Section 5.1 says senders MUST sort by ascending priority and try the lowest first. Equal priorities are randomized to load-balance.

Misconfigured priorities produce subtle failures. A backup MX with priority 10 might be ahead of the primary at priority 20, sending all mail through the backup which may have stale forwarding rules, weaker spam filtering, or just lower throughput. Or two providers' records get mixed and senders try both, creating duplicate deliveries.

The most common pattern: a domain is migrated from one provider to another, the new provider's MX records are added, but the old provider's records are not removed and the priorities collide. Sending MTAs try the old provider first because of lower numeric priority and mail bounces (account no longer exists at the old provider) or vanishes (old provider blackholes).

Why it matters

Inbound mail loss or delay. Mail routed to a defunct backup provider bounces hours later, and senders see delayed bounces with no clear cause. Mail routed to a low-throughput backup queues up and arrives slowly.

Spam filtering inconsistency. The primary provider may have well-tuned filters; the backup may not. Mixing priorities means some legitimate mail goes through the backup and gets junked while the same sender's other mail reaches the primary inbox.

Compliance and audit failures. Domains routing mail through unintended servers fail SOC 2 controls around vendor management and data flow documentation. The chain of custody for sensitive mail is unclear.

Common causes

• Mail provider migration left old MX records in place at higher priority than new ones.
• Manual entry typo (priority 10 instead of 100, or 1 instead of 10).
• Equal priorities across multiple providers led to round-robin mixing.
• Provider documentation was misread (some providers list priorities differently from DNS field order).
• Backup MX from a third-party service is at lower numeric priority than primary.

Detect this on your site

Run a quick scan with the Email Checker. The tool surfaces this exact issue with the records and context needed to apply the fix below.

How to fix it

1. 1

   List all current MX records with priorities

   Run dig +short MX example.com. Output is sorted in ascending priority. Each line is " ". Read carefully — the first line is the most-preferred server and where mail will go first.

2. 2

   Identify which records belong

   Cross-reference each MX target against your current and former mail providers. Records pointing to providers you no longer use (e.g. an old Mandrill, Mailtrap, or self-hosted MX) should be deleted. Records pointing to your active provider should match their documentation.

3. 3

   Delete obsolete MX records

   In Cloudflare DNS, Route 53, Google Domains, or Namecheap, delete every MX record that does not belong to your current mail provider. Set TTL on remaining records to 300 during the change so corrections propagate fast.

4. 4

   Reorder priorities to match provider docs

   Most providers specify exact priorities. Microsoft 365 uses 0. Google Workspace uses 1. Self-hosted setups commonly use 10 for primary, 20 for secondary, 30 for tertiary. Set each MX record's priority to match documentation precisely.

5. 5

   Verify ordering with dig and a real send

   Run dig +short MX example.com again and confirm output matches your intent. Send a test message from a third-party Gmail or Outlook account and check Received headers — the receiving server should be your active primary provider's hostname.

6. 6

   Document the MX inventory

   Add the MX configuration to your runbook with each record annotated by purpose (primary, backup, vendor migration). Future operators changing DNS will see what each record is for and not introduce regressions.

Example

; Wrong — old Mandrill backup at priority 5 ahead of Google primary at 10
example.com. IN MX  5 mx.mandrill.com.
example.com. IN MX 10 smtp.google.com.

; Right — Google primary only
example.com. IN MX  1 smtp.google.com.

; Self-hosted with redundancy
example.com. IN MX 10 mx1.example.com.
example.com. IN MX 20 mx2.example.com.
example.com. IN MX 30 mx-backup.example.net.

Three correct patterns and one common migration-residue bug.

Related fixes