What an MX record is and why a missing one kills your cold email replies

Picture this: you spend two weeks building a lead list, writing sequences, warming up a domain. You launch. Opens look fine. Clicks look fine. Replies? Zero. Not low. Zero.

I’ve seen this exact scenario play out, and the cause was a single line in a DNS panel that nobody checked. No MX record on the sending domain, so every reply bounced back into nothing.

In this post, I’ll show you exactly what MX records do, how to read every field in one, how to check yours in about two minutes, and what breaks when they’re missing or wrong.

What are MX records?

Email traffic is a conversation between a sending server and a receiving server.

When an email is sent to a domain, the sending server needs to know where to route it.

To find out, it checks the receiving domain’s MX records.

An MX record is a DNS record that tells the sending server which mail server should receive the message. If MX records are found, the email goes to the corresponding server. If they’re not, your hard-earned replies get lost in cyberspace.

And you don’t have replies to spare. Current cold email reply rate benchmarks from lemlist put the average B2B cold email reply rate at 3.43%, which means roughly 97 out of 100 emails you send never get an answer. Why make that math worse by losing the 3 that do?

Here’s what an MX record looks like:

That value comes straight from Google’s current MX setup instructions, which state that the Google Workspace MX record value is smtp.google.com. Domains set up before 2023 may still be running the legacy five-record aspmx setup (aspmx.l.google.com and friends). Those still work, so don’t rip them out in a panic. But if you’re configuring a new domain today, one record is all you need.

At first sight the record looks complicated. It isn’t, once you know what each field means.

• •

  ➡️ The name field refers to the domain or subdomain you’re configuring the mail server for. For your main domain, the contents should always be “@”. If the MX record is for a subdomain, for example mail.yourdomain.com, then you enter “mail” here.

• •

  ➡️ The type field tells your DNS provider this is a mail exchange record, so it should always be set to MX, not TXT, A, or CNAME.

• •

  ➡️ The priority field is the one people get wrong. You can have multiple MX records for the same domain in case a mail server fails. The server with the lowest priority number is tried first, then the next lowest, and so on. To give a server top priority, you enter 0. You can also balance load by giving several servers the same priority number, which keeps a single server from getting overwhelmed during a heavy send.

• •

  ➡️ The value field, sometimes labelled mail server, holds the receiving mail server. This is where the sending server routes the email.

• •

  ➡️ The TTL field sets the time in seconds that the server caches your record. Shorter TTLs mean changes take effect faster, which matters on the day you migrate providers mid-campaign.

Ready to add or change a record? Our guide on how to set up MX records walks through the setup step by step, with examples.

MX records don’t authenticate anything on their own

Here’s the part a lot of guides skip. An MX record only answers one question: where does mail for this domain go? It says nothing about whether a sender is allowed to use your domain.

That job belongs to SPF, DKIM, and DMARC. SPF lists which servers may send on your behalf. DKIM signs your messages so receivers can verify they weren’t altered. DMARC tells inbox providers what to do when a message fails those checks.

So pair them. MX for routing, the other three for trust. Miss the authentication layer and your mail still routes correctly, straight into spam. Tools like lemlist’s automated domain authentication handle this setup for you, so you’re not editing SPF strings by hand at 11pm before a launch.

Final thoughts

MX records are the least glamorous part of outbound and the fastest way to waste a quarter of work.

The goal of outreach is to book meetings. You can’t book meetings without replies, and you can’t receive replies without a working MX record. That’s the whole argument.

But treat MX as one line item in a bigger setup. Routing gets you the reply. Authentication, warmup, and sending volume decide whether your message was ever seen in the first place. Keeping all of it healthy is what lets you protect your sender reputation at scale instead of firefighting one domain at a time.

Run the nslookup command on your sending domain right now. It takes two minutes. Then let lemlist handle the rest of the technical setup while you go write a better first line.

Start a 14-day free trial