MX records explained

MX is the only DNS type whose whole job is “where should SMTP go?” Everything else about mail — SPF, DKIM, DMARC — assumes this is right first.

When a client submits a message, the sending server looks at the domain after @ and queries MX. Each answer is a priority and a hostname. Lower priority numbers are tried first. Equal priorities are a tie the sender may share. If no MX exists, RFC 5321 allows a fallback to the A/AAAA of the domain itself. That fallback surprises people who deleted MX “because the website still works.”

Targets must resolve

An MX of 10 mail.example.com is useless if mail.example.com has no A or AAAA. Some providers want you to CNAME a subdomain to them; others want raw MX hostnames they publish, such as aspmx.l.google.com or example-com.mail.protection.outlook.com. Copy the vendor’s table exactly, including every backup host they list.

Cutover pattern

  1. Lower TTL on current MX.
  2. Create mailboxes and auth (SPF includes, DKIM keys) at the new provider before switching MX.
  3. Change MX, watch the MX lookup.
  4. Keep the old system accepting mail until TTL and queues drain.

If you switch MX before SPF includes the new ESP, you will receive mail and fail to send it cleanly. Do both, then add DMARC if it is not already there.

Check live records with the MX tool. Policy: email authentication.