What is an MX record? How email finds your inbox

example.com.  MX  10  mx1.mailprovider.com.
example.com.  MX  20  mx2.mailprovider.com.

Each record contains a preference value and a hostname. The hostname must resolve to an address that accepts mail; an MX target must not be a raw IP address. Providers often ask you to publish several records for capacity and redundancy.

People often call the number a priority. Technically SMTP calls it a preference, and lower numbers are more preferred. The practical rule is simple: 10 is tried before 20.

1. Look up MX records for the recipient domain.
2. Sort the reachable destinations by preference, lowest number first.
3. If several hosts share the same preference, distribute attempts among them.
4. Try a less-preferred host when the preferred one cannot be reached.
5. Queue and retry temporary failures rather than treating every failed connection as a permanent bounce.

The exact retry behavior belongs to the sending server, so MX records do not guarantee instantaneous failover. A badly configured backup host can accept mail and then fail to relay it correctly, which is worse than simply letting the sender queue and retry.

Your inbound and outbound providers may be different. A company might receive mail through Microsoft 365 while sending newsletters through Mailchimp and transactional mail through Amazon SES. Its MX records point only to Microsoft; SPF and DKIM must also authorize and sign for the outbound platforms.

• Leaving old provider MX records active during a migration, causing some senders to deliver to the wrong system.
• Reversing priority values and accidentally preferring a backup or verification host.
• Pointing the MX value at an IP address instead of a hostname.
• Proxying a mail hostname through a web-only CDN feature.
• Publishing a hostname that has no usable A or AAAA record or no listening SMTP service.
• Adding a backup server that is not configured with the same recipients and anti-spam controls.

Use the MX lookup to see the public result in preference order. Before a provider migration, copy the exact destinations and values from the new provider, lower DNS TTL ahead of the change if appropriate, verify that accounts exist at the destination, publish the full new set, and remove the old set as the provider instructs.

Afterward, query more than once during the old TTL window and send tests from an external mailbox. DNS visibility proves routing data exists; an actual delivered message proves the destination is accepting mail for your users. For a deeper look at equal values and failover, read MX record priority explained.