MX record
The DNS record that tells other mail servers where to deliver email addressed to your domain, with lower preference numbers tried first.
See it
What it is
An MX record tells a sending mail server which host accepts messages addressed to your domain. Each record pairs a mail server hostname with a preference number. Lower numbers are tried first, while equal numbers can share traffic. The target is a hostname that resolves to an IP address, not a raw IP pasted into the MX value.
You change MX records when moving inbound mail to Google Workspace, Microsoft 365, Fastmail, or another mailbox host. Google Workspace now hands out a single 'smtp.google.com' record where older setups listed five 'aspmx' hosts, so publish exactly the set your host gives you today, wait for DNS caches to age out, then test delivery from outside the domain before removing the old route.
Direction is where people go wrong: MX controls mail coming to your domain. It does not authorize mail going out, improve SPF, or choose the SMTP relay your app uses. A forgotten backup MX can keep accepting some mail on an old server, and a domain that intentionally receives no mail should publish the RFC 7505 null MX form '0 .' instead of leaving its intent ambiguous.
Ask AI for it
Create a safe MX migration plan for moving example.com inbound mail to Google Workspace. I will paste the exact MX values shown in the Google Admin console and the records currently in DNS. Produce the final DNS entries as host, type, preference, TTL, and target without inventing or correcting any Google-supplied hostname. Flag raw IP targets, stale backup MX records, CNAME conflicts at the same owner name, and an accidental RFC 7505 null MX. Order the rollout so the TTL is lowered before the cutover, both old and new routes are tested during the transition, and the old records are removed only after external mail lands in Google Workspace. Finish with 'dig MX example.com' and two outside-in delivery tests that prove the migration worked.