MX record checker and mail routing guide

MX records are the least glamorous part of cold email infrastructure and one of the fastest ways to break a campaign. SPF, DKIM, and DMARC decide whether your mail goes out clean. MX records decide whether anything can come back. A sending domain with missing or wrong MX records sends fine and then bounces every reply. Here is what MX does, the exact records per provider, and the mistakes worth checking before launch.

For an agency, that makes MX a client-launch decision: identify the intended provider, assign any routing fix, run an inbound test, and preserve the fresh evidence before sending starts.

What an MX record is

An MX (Mail Exchange) record tells the world which servers receive mail for a domain. When someone replies to you@yourdomain.com, their mail server looks up the MX records on yourdomain.com and delivers to the host listed there.

yourdomain.com  MX  1   smtp.google.com.

Each record has a priority number and a hostname. Lower priority is tried first. Multiple records provide failover:

yourdomain.com  MX  0   yourdomain-com.mail.protection.outlook.com.

MX records do not affect outgoing mail at all. They are purely about receiving.

How to check MX records

Enter the root domain, without https:// or www, in the free MX record checker. The result should show at least one mail host and the provider you expect.

Read the result in this order:

1. Record exists. An empty result means replies cannot be routed to a mailbox on this domain.
2. Target is correct. Google Workspace, Microsoft 365, Zoho, and other providers use recognizable mail hosts. A host from an old provider is a migration problem.
3. Priority is intentional. The lowest number is attempted first. Extra records are useful only when the provider documents them.
4. Target resolves. Each MX target must ultimately resolve to a mail server address. A visible hostname by itself is not proof that delivery works.
5. Real mail arrives. After changing DNS, send a message from an unrelated provider and confirm that it reaches the expected inbox.

The checker performs a live public DNS lookup. It does not log into Google Admin, Microsoft 365, or the mailbox, so the final delivery test remains necessary.

Why it matters for a cold email launch

• Replies are the entire point. A cold email campaign is measured in replies. If the sending domain has no MX records, or records pointing at a dead host, every reply bounces back to the prospect. The campaign looks like it failed when it actually worked and then dropped the answer.
• Bounces need somewhere to land. Bounce notifications route via MX too. Without them, your sending tool cannot see hard bounces, your list never gets cleaned, and your bounce rate compounds.
• Receivers check for them. A domain that sends mail but cannot receive any looks like throwaway spam infrastructure. Several filters treat a missing MX as a negative signal on inbound mail from that domain.
• Wrong MX means silent inbox mismatch. If the MX points at Google but the inboxes were created in Microsoft 365, mail is delivered into mailboxes nobody opens.

Run the right check before launch

Use the checks in sequence. An MX lookup answers whether the public mail route exists. A launch decision needs more than that.

1. Run the MX record checker to confirm that the root domain publishes the expected receiving hosts.
2. Send a test message from an unrelated mailbox and confirm it reaches the reply inbox you will monitor.
3. Run the cold email domain checker to check MX alongside SPF and DMARC before the campaign goes live.

The one-domain check is public DNS evidence. It cannot confirm a mailbox license, inbox routing rule, or that a real reply is being monitored. Verify those operational steps before launch.

How to set it up

Step 1: Decide where the domain’s mail lives. For cold email domains this is the inbox provider you bought mailboxes from, almost always Google Workspace or Microsoft 365.

Step 2: Publish the provider’s records.

Google Workspace (current single-record form):

yourdomain.com  MX  1  smtp.google.com.

Older Google setups use five records (aspmx.l.google.com priority 1, plus four alt hosts). Both work; do not mix the two schemes.

Google’s current Workspace documentation uses smtp.google.com with priority 1 for new setups. Accounts configured before 2023 may still use the legacy aspmx records, and Google says working legacy configurations do not need to change. See Google’s official MX setup instructions.

Microsoft 365:

yourdomain.com  MX  0  yourdomain-com.mail.protection.outlook.com.

The exact host is shown in the Microsoft 365 admin center under the domain’s DNS records. It encodes your domain name, so copy it rather than retyping.

Step 3: Remove everything else. Delete parking-page MX records from the registrar and records from any previous provider. Only the current provider’s hosts should remain.

Step 4: Verify. Look up the records and confirm the provider is the one you expect. The MX checker resolves the records and detects the provider. Then send a test message to the domain from an outside mailbox and confirm it arrives.

What a null MX record means

A null MX record uses a target of . to state that the domain does not accept email:

example.com  MX  0  .

That is valid for a parked or non-mail domain. It is a launch blocker for a cold email sending domain that expects replies, bounce notices, or working inboxes. Do not add a second normal MX record beside a null MX record. Replace the null record with the exact records from the active mailbox provider.

Google MX checker versus a DNS lookup

A Google Admin diagnostic can confirm whether records match a Google Workspace setup. A general MX lookup answers a different first question: what mail hosts does public DNS return right now, regardless of provider?

Use both when troubleshooting Google Workspace:

• Run the OutboundQA MX checker to inspect the public answer and provider detection.
• Compare the result with Google’s current smtp.google.com instructions or the supported legacy record set.
• Confirm the domain is verified and Gmail is activated in Google Admin.
• Allow for the published DNS TTL and test a real inbound message.

A clean public lookup cannot see a suspended Workspace account, missing license, disabled Gmail service, or mailbox-level routing rule.

Replies and bounces, specifically

Two flows depend on MX and both are invisible until they break:

• Replies: prospect hits reply, their server looks up your MX, delivers to your inbox provider, your sending tool picks it up via IMAP or API. Broken MX cuts this at step two, and the prospect gets a bounce from your domain seconds after replying. That is worse than no reply handling at all.
• Bounces: when your cold email hits a dead address, the receiving server sends a failure notice to your return-path address, which resolves through MX. Sending tools use these notices to mark bad addresses and stop sending to them. No MX, no bounce processing, and your bounce rate climbs with every batch, which feeds directly into the spam-rate math in the bulk sender requirements.

Common mistakes

1. No MX records at all. Common on domains bought in bulk and pointed straight at a sending tool. The domain sends but cannot receive.
2. Registrar parking MX left in place. Replies route to the registrar’s null host instead of your inboxes.
3. MX pointing at the old provider. The domain moved from Microsoft to Google but the records did not. Mail lands in mailboxes nobody checks.
4. MX pointing at a CNAME. The MX target must be a hostname with an A or AAAA record, not a CNAME. Some receivers reject delivery to CNAME targets.
5. Trailing dot and typo errors. smtp.google.com.yourdomain.com from a missing trailing dot in a zone file is a classic. Verify by lookup, not by reading the zone editor.
6. Priority confusion. Two records at the same priority split delivery between them. Fine when intentional, a bug when one host is stale.

FAQ

Does a sending domain really need MX records if all replies go to a master inbox? Yes. Reply-to redirection happens after delivery. The reply is first delivered via the sending domain’s MX, so the records must exist and point somewhere real.

Do MX records affect whether my outgoing mail authenticates? No. Outgoing authentication is SPF, DKIM, and DMARC. But receivers may score inbound-capability as part of reputation, so the records still matter for outcomes.

How many MX records should I have? Exactly what your provider documents. One for current Google and Microsoft setups. More is not better; stale extras are a liability.

How fast do MX changes take effect? After DNS propagation, so within the record TTL. Budget an hour and verify by lookup before sending.

MX is one of the infrastructure checks OutboundQA runs before a launch. Resolve a domain’s records with the MX checker, or run MX, SPF, and DMARC in one pass with the cold email domain checker.