Can a Domain Have Multiple MX Records? How Priority Works, and Why Two Mail Providers Do Not Mix

This post contains affiliate links. If you buy something through one of them, Veravix may earn a commission at no extra cost to you.

Yes, a domain can have multiple MX records, and most real ones do. What trips people up is what the extra records are for. They give one mail provider a way to stay reachable when a server is busy or down. They are not a way to run two mail providers side by side, and treating them that way is how mail quietly disappears during a migration.

This guide explains how a sending server picks between several MX records, then shows what 69 well-known domains actually publish, from public DNS lookups I ran on 18 October 2026. The rules come from the SMTP standard itself (RFC 5321, section 5.1) and from Google’s own MX setup page. The survey numbers are my own.

How a sending server chooses between your MX records

Each MX record has two parts: a priority number and the name of a mail server. When someone sends mail to you, their server looks up your MX records, sorts them by priority, and tries the lowest number first. The standard says lower numbers are more preferred. Only if that server cannot take the message does the sender move to the next one.

Two details matter in practice:

• Equal priorities are shuffled. If several records share a priority and the sender has no reason to prefer one, RFC 5321 says it must randomize them to spread the load. Two records at priority 10 mean roughly half your mail goes to each.
• Fallback is for trouble, not for choice. The standard requires a sender to be able to try the addresses in order until a delivery succeeds, and says it should try at least two. A server that is down or temporarily refusing mail is passed over. A server that is up and answers is used, and that is the point where a stray extra record causes damage.

Two more rules from the same section are worth knowing. The name in an MX record has to point to a host that resolves to an address, not to an alias (a CNAME), and it should be a hostname rather than an IP address. And if a domain has no MX records at all, the standard treats the domain’s own address record as an implicit MX with priority 0, so mail can still be tried against your web server, which usually does not accept it.

What 69 real domains publish

I looked up the MX records of 71 well-known domains through Google’s public DNS service: large tech and hosting companies, WordPress and WooCommerce properties, news sites, email and marketing tools, and the direct-to-consumer brands from my Shopify email survey. Two were dropped: notion.so returned no MX record at all, and hismile.com’s nameservers refused the query. That leaves 69.

Pattern	Domains	Typical example
One MX record	16	Microsoft 365 domains such as github.com, godaddy.com and allbirds.com, or a single smtp.google.com as on 4ocean.com
Several records, all the same priority	19	Pairs of load-shared servers, such as the Proofpoint gateways behind zoom.us and dropbox.com, both at priority 10
Several records at different priorities	34	Google’s older five-record set, or a primary and a backup such as namecheap.com (5 and 10)

So 53 of the 69 publish more than one record, and 34 of those use real tiers. Twenty-three domains publish five or more Google mail servers, the older layout (one server at priority 1, then pairs at 5 and 10), which Google says remains supported. Google’s current instruction for new setups is a single record, smtp.google.com at priority 1, and it tells you to remove any other MX records, because old or incorrect ones can stop mail working properly. Only 4 of the 69 use that single Google record on its own, while 7 others use a single Microsoft 365 record.

The two domains this site’s mail runs on follow the common primary and backup shape: mx1.hostinger.com at priority 5 and mx2.hostinger.com at 10, both with a 14,400 second TTL, the pair the Hostinger mailboxes here use. Both records belong to the same provider, which is the normal case.

The one domain that mixes two providers, and why it does not count

Of the 69, exactly one publishes records from two different companies: zendesk.com. Its two Mimecast servers sit at priority 0, and four Google servers sit behind them at priorities 110 to 130. Read that as a design, not a coincidence. Mimecast is a mail security gateway that inspects each message first, and the Google servers are the mailboxes behind it. Mail is meant to reach the gateway, and the Google records are the fallback path if the gateway is unreachable.

That is a deliberate arrangement with a clear primary and a clear reason for the second provider. It is very different from adding a new provider’s MX record next to an old one and hoping both inboxes fill up. A sender does not deliver to both. It delivers to whichever record it tries first and that accepts the mail.

What goes wrong when two providers share the same priority

Suppose you move from one provider to another and add the new records without removing the old ones, both at priority 10. By the shuffling rule above, any given sender may pick either set. Some messages reach the new mailbox and some reach the old one, and nothing tells you which. Because both servers are up, neither one hands the message on to the other, so the sender never falls back. The practical result is that important mail appears missing for days when it is simply in a mailbox you stopped checking.

Different priorities do not fully fix this either. If the old records have the lower number, they win while they stay reachable, and your new mailbox receives mail only when the old one is down. The cleaner rule is the one Google states: during a move, end up with only the records for the provider you now use.

How to switch providers without losing mail

1. Lower the TTL first. The TTL is how long other servers may cache your MX records. A day or two before the move, set the records’ TTL to something short such as 300 seconds, so the change spreads quickly. Records with a 14,400 second TTL can be remembered for four hours.
2. Create the new mailboxes before you change DNS, and confirm the new provider shows your domain as ready to receive.
3. Replace the records in one edit. Remove the old MX records and add the new provider’s records together. Google notes that changes can take up to 72 hours to be recognised everywhere.
4. Keep the old mailbox open for a few days. Senders with the old records cached will still deliver there until their cache expires, so check it for stragglers.
5. Test from outside. Send messages to the new address from accounts at two other providers, and run a lookup to confirm what the world sees.

If SPF, DKIM and DMARC are part of the same move, there are step-by-step guides for Microsoft 365 and Google Workspace DKIM. MX records only decide where incoming mail goes. They do nothing for outgoing mail, which is where the authentication records come in.

Check what your domain publishes right now

On Windows, macOS or Linux, a one-line lookup shows your records and their priorities:

nslookup -type=mx yourdomain.com

On macOS or Linux, dig MX yourdomain.com +short prints them in priority order. Then check four things:

• Every record belongs to the provider you actually use today.
• Each value is a hostname, not an IP address and not a name that is itself a CNAME.
• No record is left over from a previous host or a registrar’s parked-domain default.
• The priority numbers match your intent: a single provider’s own pattern, or a deliberate gateway in front of a mailbox as in the Zendesk case.

A domain that never receives mail can say so explicitly. RFC 7505 defines a null MX, a single record with priority 0 and a dot as the host, which tells senders at once that there is nothing to deliver, instead of letting them queue and retry against a web server. None of the 69 domains I looked at used it, and Notion’s apex domain published no MX record at all, so the implicit rule above applies there. If you want a parked domain to refuse mail cleanly, the null MX is the documented way, though the same RFC advises against publishing one on a domain you send mail from.

If mail to your domain is already misbehaving and the records look right, a proper deliverability test is the next step, and the blacklist check guide covers the case where a clean-looking setup is still being blocked.

Checked for accuracy on 18 October 2026. MX lookups were made through dns.google on that date. Providers were classified by the hostnames in the records, and TTL values shown by a public resolver count down as they are cached, so only my own domains’ values are quoted.