What Are MX Records? A Cold Email Sender's Guide for 2026

MX records (Mail eXchange records) are the DNS entries that tell the internet where to deliver mail for a given domain. They’re foundational — without correct MX records, no email can be delivered to your domain at all — but most cold email teams treat them as something IT set up once and never look at again. That’s usually fine, until the day MX records become the reason your campaigns are silently failing. This article covers what MX records do, why they matter to cold email senders specifically, how to inspect them, and the misconfigurations that break sending. It pairs with the email deliverability guide and the Google Workspace MX setup guide.

An MX record is a DNS record that lists the mail servers responsible for receiving email on behalf of a domain. Each MX record has a priority value (lower = preferred) and a server hostname. When someone sends mail to you@yourdomain.com, their server queries DNS for your domain’s MX records and delivers to the highest-priority server that responds.

What MX records do in practice

Every domain that receives email must have at least one MX record. The record format looks like:

yourdomain.com.  IN  MX  10  smtp.google.com.
yourdomain.com.  IN  MX  20  smtp2.google.com.

This says: “Mail for yourdomain.com should go to smtp.google.com first (priority 10), and if that’s unreachable, try smtp2.google.com (priority 20).”

The priority numbers create a fallback chain. Lower numbers are tried first. Multiple MX records with the same priority distribute load across servers — sending systems pick one at random.

For cold email senders specifically, MX records matter in three ways:

Receiving replies. Your prospects’ replies need to land in your inbox. If your MX records are misconfigured, replies bounce. You won’t notice immediately because the bounce goes to the prospect, not to you — they just stop hearing back from you, and you think they ignored the reply.

Email verification. Verification services check MX records to determine whether a domain can receive mail at all. Domains with no MX records or with broken MX records get flagged as undeliverable, regardless of the specific address.

Reputation signal. Receiving systems use MX configuration as one signal in domain legitimacy assessment. A domain with no MX records but high outgoing volume looks suspicious — legitimate domains have proper receiving infrastructure.

How to inspect MX records

The simplest way to check MX records is the dig command:

dig +short MX yourdomain.com

This returns the MX records for the domain. Online tools like MXToolbox, DNSChecker, or What’s My DNS provide the same information in a browser interface, plus additional diagnostics.

What to verify when inspecting:

• At least one MX record exists. No MX records = no email reception.
• The MX hostnames resolve to actual mail servers. Each hostname should have an A or AAAA record pointing to a real IP.
• The priorities make sense. Production setups typically have a primary (low priority number) plus 1–3 backups (higher priorities).
• The mail servers actually accept connections on port 25. Connecting via telnet mailserver.com 25 or using a tool like Email Tester confirms the server is responding.
• PTR records exist for the mail server IPs. Receiving systems check that the MX hostname has a matching reverse DNS entry.

Common MX record misconfigurations

No MX records at all. Domains without MX records can’t receive email. Some teams set up sending without configuring receiving, assuming “we don’t need receiving.” But cold email needs receiving — replies have to land somewhere.

MX records pointing to non-existent servers. A leftover MX record pointing to an old mail provider (after migration) causes delivery attempts to fail. Production teams audit MX records after every infrastructure change.

Priority order misconfigured. When the primary MX has high priority (high number) and the backup has low priority, sending systems prefer the wrong server. This usually doesn’t break delivery but produces unusual routing.

Duplicate MX records at the same priority. Some DNS configurations end up with duplicate records — the duplicate doesn’t cause an error but can confuse load distribution.

Subdomain MX records missing. If you send from outreach.yourdomain.com, the subdomain needs its own MX records (or inherits from the parent — verify which based on your DNS provider’s behavior). Forgetting subdomain MX records means replies to subdomain addresses fail.

MX records with CNAME aliases. RFC says MX records should point to A/AAAA records, not CNAMEs. Some DNS providers allow it but receiving systems may reject the configuration. Always point MX records to hostnames with direct A records.

When to update MX records

Update MX records when:

• Migrating email providers (e.g., from Gmail to Office 365 or vice versa). The migration provider will give you the new MX values; update DNS and wait for propagation.
• Adding a new subdomain for sending. New subdomains need their own MX records if they’ll receive mail.
• Adding a third-party mail filtering service (Mimecast, Proofpoint, Barracuda) — these become the primary MX with the underlying mail provider as backup.
• Switching to a new transactional email provider — usually doesn’t require MX changes (transactional providers are sending-only) but verify against the provider’s documentation.

Don’t update MX records:

• For cold email tools like Smartlead, Lemlist, Apollo — these are sending platforms, not receiving. They don’t need MX records.
• To “improve deliverability” without a specific reason — MX records affect receiving, not sending placement.

The pattern: MX records are foundational, simple, and often overlooked. Setting them up correctly is a 5-minute task; misconfiguring them produces silent failures that can run for weeks before anyone notices. Production teams verify MX configuration as part of every domain audit and any infrastructure change.