MX records and mail routing

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.

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.

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.

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.

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.

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 16 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.