MX Record Configuration: A Practical Step-by-Step Guide

Do not index

A domain can look healthy on the surface while email falls apart underneath. A recruiter's reply never arrives, a welcome message vanishes, or a provider migration leaves inbound mail bouncing in the background. In a lot of teams, the root cause isn't the message content, it's mx record configuration, the DNS layer that decides where mail for a domain lands.

That's why MX mistakes hurt deliverability in a way many teams underestimate. A stale hostname, the wrong priority order, or an old provider left behind can create broken routing that's hard to notice until customers complain. A clean setup supports reliable inbound mail, smoother provider handoffs, predictable failover, and a stable base for the rest of the authentication stack.

For teams evaluating infrastructure, a practical starting point is the email hosting for small business because hosting and routing choices often determine whether MX changes stay simple or turn into a recurring fire drill.

Table of Contents

When a Missing MX Record Quietly Breaks Your Email Program What an MX Record Does The pieces that matter most Configuring MX Records Across Major DNS Providers Google Workspace Microsoft 365 Cloudflare and Amazon Route 53 GoDaddy Setting Priorities, TTLs, and a Backup MX How to think about the numbers TTL choice affects change speed Verifying Propagation with dig, nslookup, and Online Tools Three ways to check the record What to confirm after lookup Common MX Mistakes That Damage Deliverability The recurring failures MX Configuration and the Broader Authentication Stack

When a Missing MX Record Quietly Breaks Your Email Program

A SaaS company migrates from one hosted mail platform to another on a Friday evening. The new provider is live, the inboxes still open, and nobody notices that an old MX entry was left in place. By Monday, inbound messages are split between two destinations, some replies vanish, and support starts seeing complaints that look like spam filtering but are really routing confusion.

That scenario comes up constantly because MX problems hide in plain sight. The record doesn't make the message, write the copy, or authenticate the sender. It decides which mail host receives the domain's mail, and if that decision is wrong, every team downstream pays for it.

For a marketing lead or ops owner, the business impact is immediate. Sales threads stall, transactional mail gets delayed, and the domain starts to look unreliable even when the content is fine. That kind of failure damages confidence in the entire sending program, which is why a clean routing layer matters as much as the content layer.

The operational fix is rarely glamorous, but it's decisive. Remove obsolete MX entries, publish the correct hostname-based targets, keep a backup path available, and make sure the mail flow matches the current provider. That's the same mindset used in a proper email deliverability guide, because deliverability is never just about what gets sent, it's about whether the message reaches the right mailbox in the first place.

A good MX setup gives the sending side four things it can trust. It gives reliable inbound routing, it supports clean handoffs between providers, it creates failover when the primary host is unreachable, and it gives SPF, DKIM, and DMARC a stable foundation to work from. Skip that foundation, and every later diagnostic becomes noisier than it should be.

What an MX Record Does

An MX record is the DNS record that tells other mail servers which mail host should accept email for a domain. It lives in DNS, not in the mailbox, and it is the routing decision that sends inbound mail to the right destination. If that record points to the wrong host, or points to a hostname that no longer belongs to your provider, inbound mail can fail while the rest of the stack looks fine.

The structure is simple, but the details matter. The host is often the apex domain, commonly represented as @, the target is the mail exchanger hostname, and the preference value decides which host gets tried first. Lower numbers are tried before higher ones, so a primary record usually sits below its backups in numeric priority.

The pieces that matter most

A few rules separate a clean configuration from a brittle one.

Host: usually @ for the root domain, unless a subdomain needs its own mail path.

Target: a fully qualified hostname such as mail.example.com, not a raw IP address.

Priority: lower values are tried first, so a primary might use 10 and backups might use 20 or 30.

TTL: often set between 3600 and 86400 seconds, which is 1 hour to 24 hours, to balance stability and propagation speed. Cloudns operational guidance notes that range and also recommends using FQDNs, deleting obsolete MX records, and keeping a backup MX.

That hostname rule is not optional. MX targets point to names, and those names are then resolved through A or AAAA records, which is why MX should never be published as a direct IP address. Keeping the target as a hostname also gives you room to change mail providers without rewriting every sending path that depends on the domain.

A practical setup usually follows the same pattern. Use one primary hostname, add at least one backup hostname, and keep the TTL high enough that the zone stays stable but not so high that provider changes get stuck in caches. The exact values depend on the provider, but the logic does not change. A stale MX hostname is a quiet failure mode, because mail can still be accepted somewhere, just not where your team expects it to land.

Configuring MX Records Across Major DNS Providers

The DNS console changes from platform to platform, but the job does not. Publish the provider's exact mail target, set the right priority, and confirm the record is created as MX, not as a generic host entry or a proxy rule. The most common failure here is not a bad hostname. It is a console that makes a mail record look like something else, then leaves the domain accepting inbound traffic in the wrong place.

Google Workspace

Google Workspace is one of the easier places to make a quiet mistake because the setup depends on when the account was created. For users who signed up after April 2023, one source states the configuration uses a single MX record pointing to smtp.google.com with priority 1 and TTL 3600 seconds. Older setups still rely on multiple MX entries, so copying an old template from a blog post can leave a domain with extra routing paths that no longer match the tenant. Unstoppable Domains' MX record overview calls out that signup-era split directly.

Microsoft 365

Microsoft 365 uses a provider-specific hostname format, commonly example-com.mail.protection.outlook.com, with priority 0. The important part is not memorizing the string, it is matching exactly what Microsoft publishes for the tenant. The record can be syntactically valid and still route poorly if the priority is wrong, because mail systems will try the lowest number first.

Cloudflare and Amazon Route 53

Cloudflare and Route 53 are DNS layers first, mail platforms second. They store the record you publish. That flexibility is useful, but it also makes it easy to leave behind a stale MX entry, copy a proxy-style setting that should never apply to mail, or assume the console is correct just because the form saved without error.

A safe operator habit is to verify four things before saving.

Host is @ or the intended subdomain, not a random label.

Target is a hostname, never a direct IP.

Priority matches the provider's documentation, especially if backups are involved.

Old MX records are removed, not left to coexist with the new provider.

GoDaddy

GoDaddy still shows up in legacy domains, especially where the DNS was set years ago and nobody has touched it since. The main risk there is drift. Teams change mail platforms, leave the old zone intact, and forget that the old MX answer can still receive traffic if it remains published.

Provider	Priority	Target Host	Recommended TTL
Google Workspace	1	`smtp.google.com`	3600 seconds
Microsoft 365	0	`example-com.mail.protection.outlook.com`	Provider-defined
Cloudflare	Provider-defined	Provider-defined hostname	Provider-defined
Amazon Route 53	Provider-defined	Provider-defined hostname	Provider-defined
GoDaddy	Provider-defined	Provider-defined hostname	Provider-defined

Setting Priorities, TTLs, and a Backup MX

A single wrong priority can send inbound mail to the wrong place. I have seen domains look healthy in DNS and still miss mail because the lowest number pointed at a stale hostname, or because a backup record was left in place after a migration. That kind of mistake does not always fail loudly. It breaks delivery and can erode sender reputation when remote servers keep retrying or give up on a misrouted destination.

How to think about the numbers

Priority is an ordering rule, not a quality score. The lowest number gets tried first, so a primary at 10 is attempted before a backup at 20, and both are tried before a host at 30. The practical question is how fast you want failover to happen, and how much separation you want between the active system and the fallback.

A lower backup priority usually means mail can move to the alternate host sooner when the primary is unavailable. A higher backup priority keeps the backup quieter until the primary clearly stops answering. That trade-off matters because a backup MX that is too eager can start handling traffic you did not intend it to see, while one that is too distant may not catch mail quickly enough during an outage.

The backup hostname itself has to be real. It must resolve, accept mail for the domain, and be maintained like part of the mail stack, not treated as a placeholder. If the hostname is stale or incomplete, failover does not protect inbound mail, it just pushes the problem one step down the line. For teams aligning routing with the rest of the mail stack, email security services 2026 is a useful reference point for the broader operational picture.

TTL choice affects change speed

TTL sets the trade-off between change speed and cache stability. Shorter TTLs help during migrations because resolvers refresh sooner, which makes provider switches easier to verify. Longer TTLs reduce lookup churn in steady state, but they also keep old answers alive longer and can delay recovery if you need to correct a bad MX target.

A practical setup often uses a primary at 10 and a backup at 20 when the backup should take over quickly if the main host fails. A primary at 10 and backup at 30 creates more distance between active and standby systems, which fits cases where the backup exists for resilience rather than shared traffic. The right choice depends on whether you want the backup to absorb mail fast or stay out of the way until the primary is clearly down.

Before you publish the zone, confirm the backup host resolves cleanly and check that the MX target also lines up with your broader authentication setup, including your spf checker. MX controls where mail goes, but sender identity still has to hold together or delivery will suffer for a different reason.

Verifying Propagation with dig, nslookup, and Online Tools

A zone file can look correct in the control panel and still fail in practice. DNS resolvers cache answers, authoritative servers can lag behind the edit you just made, and an old MX answer can keep routing mail to the wrong host long after the dashboard says the change is live. Give propagation time to settle, then verify with nslookup, dig, or another lookup tool before you assume inbound mail is fixed.

Three ways to check the record

dig is the cleanest check when you want to see the answer section and confirm the target host and priority order. nslookup is familiar on Windows and makes it easier to see which resolver is answering. An online lookup tool, such as MXToolbox or Google Admin Toolbox, helps catch stale legacy entries or a target that does not resolve.

The key check is whether the listed host resolves, whether the priority order matches the intended routing, and whether any old record is still present. A zone can appear close enough to pass a casual glance and still send mail to the wrong place.

What to confirm after lookup

The target hostname resolves cleanly, which shows the mail host exists and DNS can reach it.

The priority order matches the intended failover path, not the old provider's setup.

No legacy MX entries remain, because one forgotten record can split inbound delivery.

A live inbound message lands on the expected server, which is the final proof that routing matches the zone.

For teams folding DNS checks into broader hygiene work, the spf checker is a useful next step. MX can route mail to the right place, but SPF still needs to line up or the domain can carry a different delivery problem.

Common MX Mistakes That Damage Deliverability

A misconfigured MX record rarely breaks loudly. It usually fails in the background, then shows up as missing replies, delayed inbound mail, or a mailbox provider that seems unreliable for no obvious reason. That is why MX record configuration deserves the same attention as any other deliverability control. A single wrong priority, a stale hostname, or a leftover record can quietly reroute inbound mail and make the whole domain harder to trust.

The recurring failures

Pointing MX at an IP address: Most mail systems expect a hostname, not a raw IP, so the lookup path breaks and delivery can fail or behave inconsistently.

Leaving old MX records in place: Old and new providers can both receive traffic, which splits inbound delivery and makes message loss hard to trace.

Reversing priority numbers: If the backup host gets the lower number, it becomes the first choice and your failover order no longer matches the plan.

Ignoring SPF, DKIM, and DMARC: MX only routes mail. It does nothing to authenticate senders, so a clean inbound path can still leave the domain exposed if identity controls are weak.

The operational mistake I see most often is treating MX as a one-time DNS task. It needs review whenever the mail stack changes, including provider swaps, security changes, or domain restructuring. If nobody revisits it, the symptoms are practical and expensive. Replies disappear, mail lands in the wrong place, and the domain starts collecting reputation problems that take time to unwind.

For teams that want the broader delivery and reputation picture in one place, email authentication belongs in the same review cycle, because DNS routing and sender identity only work when they stay aligned.

MX Configuration and the Broader Authentication Stack

A clean MX setup keeps inbound mail pointed at the right host, but it does more than move messages. It shapes whether the rest of your mail program has a stable path to work with. If the domain routes replies to an old system, a backup host, or a hostname that no longer matches the current provider, the authentication stack has to compensate for the confusion. That is where deliverability starts to slip in ways teams often miss.

SPF defines which sending IPs are allowed. DKIM adds a cryptographic signature so receivers can check whether the message changed in transit. DMARC uses those two signals to decide what happens when alignment fails. MX sits beside that stack, not inside it, but a bad record can still distort the way legitimate mail and abuse move through the domain. When routing is sloppy, the sender identity signals become harder to interpret.

I have seen domains with technically sound SPF, DKIM, and DMARC still struggle because MX pointed somewhere stale. Replies vanished into the wrong mailbox, support teams lost thread continuity, and the domain started to look unreliable even though the authentication layer was intact. That is why email authentication belongs in the same review cycle as MX changes. DNS routing and sender identity only work together when they are kept aligned.

The practical rule is simple. Keep MX records current, keep authentication aligned with the active mail system, and control routing changes as carefully as any sender-side policy update. That will not guarantee inbox placement on its own, but it removes avoidable noise and gives the rest of the deliverability program a cleaner foundation to work from.