What they do

When a server wants to deliver mail to you@yourdomain.com, it queries the MX records for your domain. Those records name the hostnames that accept mail, each with a priority number. Lower numbers are tried first; equal numbers share load.

Google Workspace typically publishes a single record pointing at smtp.google.com with priority 1. Older setups list five separate Google hostnames at different priorities, which still works and is simply the previous configuration.

Inbound only

MX has nothing to do with your outbound mail. You can send from a domain with no MX record at all. The confusion matters during migrations: pointing MX at a new provider before the mailboxes exist means inbound mail is rejected or lost for the length of the gap, while outbound carries on as though nothing happened.

What they reveal

MX records are public, which makes them the fastest way to identify who hosts mail for any domain — useful for knowing whether you are sending into Google, Microsoft or something else, since they filter differently. They also expose a gateway sitting in front of the mailbox, because appliances like Proofpoint and Mimecast take the MX position themselves.

Syntax and priority

An MX record has two parts: a priority number and a hostname. Lower numbers are tried first; equal numbers are used in rotation. The hostname must resolve to an A or AAAA record — an MX pointing at a CNAME is invalid, and while many resolvers tolerate it, some senders will not deliver.

Google Workspace uses one record: 10 smtp.google.com. Microsoft 365 uses one per domain in the form 0 yourdomain-com.mail.protection.outlook.com, where the target is derived from your domain name and shown in the admin portal. Older Workspace setups have five aspmx.l.google.com records at priorities 1 through 10; they still work, but new domains should use the single record. Anything else on a Workspace or M365 domain is either a leftover or a mistake.

Failure modes

The registrar's parking MX. A new domain often comes with an MX pointing at the registrar's mail parking or forwarding service. Mail sent to the domain goes nowhere and, worse, the domain looks like it has never been set up. Replace it, do not add to it.

Two providers at once. After a migration the old provider's MX is still there at a lower priority. Some mail routes to the old server, some to the new, and replies to your cold email vanish into a mailbox nobody checks. A domain has one mail provider; delete the other's records the day you cut over.

Long TTLs during a migration. An MX at a 24-hour TTL keeps sending mail to the old provider for a day after you change it. Drop the TTL to 300 seconds a day before the switch, change the record, then raise it again once it has settled. The TTL checker shows the current value; the propagation checker shows which resolvers have picked up the change.

MX that never answers. The hostname resolves, but nothing is listening on port 25, or the certificate has expired. Senders queue and eventually bounce with a 5.4.4 or a timeout, and you find out when a prospect says their reply came back. The SMTP connection tester connects to the MX and reports what it sees.

Null MX and domains that should not receive

A domain that sends but must never receive — a bounce subdomain, or a domain you use only for outbound with replies routed elsewhere — can say so with a null MX: 0 . (priority zero, a single dot). Senders that support it fail fast instead of retrying for days. Be careful with it on a cold email domain: Gmail rejects mail whose From domain has a null MX with a 5.7.27, because a sender you cannot reply to is a sender it does not trust. Cold email domains should receive, and their MX should point at the mailbox the replies land in.

Every reply-to and every bounce address in a campaign needs a working MX behind it. The MX checker identifies the provider for any domain and flags parked, mixed and unreachable records; run it across the fleet with the domain checker after any migration.

Check yours

These run free in your browser. Nothing you type reaches a server.

Common questions