MX Lookup

Senders try the MX with the lowest number first. If it doesn't answer, they try the next one. Servers with the same number share the load randomly. The numbers themselves don't matter — 1, 5, 10 behaves exactly like 10, 20, 30 — only their order does.

As long as the old MX record's TTL — often 1 hour, sometimes 24 hours. During that window some senders still deliver to the old provider, so keep the old mailboxes open for a day or two. Use the DNS Propagation Checker with the MX type to see which resolvers already have the new servers.

No to both. An MX must point to a hostname that has its own A or AAAA record. An IP address in an MX is invalid and many senders refuse to deliver. A CNAME target is forbidden by RFC 2181 and RFC 5321 — most large senders tolerate it, but some reject it.

Senders fall back to the domain's A record (the 'implicit MX') and try to deliver to that IP — usually a web server that doesn't accept mail, so messages bounce or time out. If the domain should never receive email, publish a null MX ("0 .") so senders fail immediately and cleanly.

The MX hostnames give it away: *.google.com or googlemail.com means Google Workspace, *.mail.protection.outlook.com means Microsoft 365, mx.zoho.com is Zoho. Security gateways like Mimecast or Proofpoint often sit in front of the real provider; the SPF record usually reveals what's behind them.

Usually not. Senders queue and retry for several days if your mail server is down, so mail isn't lost. Google Workspace and Microsoft 365 already run redundant servers behind their MX names. A badly configured backup MX is a common spam entry point because it often has weaker filtering.