MX Record Configuration: A Practical Setup Guide

Do not index

A domain migration can leave a company with a perfectly valid-looking DNS zone and no reliable inbound email. The MX record still points to the old provider, senders keep retrying a retired server, and important replies, invoices, alerts, or onboarding messages disappear into bounce loops. At the same time, a team may be investigating SPF, DKIM, DMARC, or blacklist issues even though the immediate failure is that the receiving host can't accept SMTP connections.

MX record configuration is an operational deliverability problem, not just a DNS editing task. The record must point to the right hostname, the hostname must resolve, and the destination must be available to receive mail. This guide shows how to configure MX records, validate them, and connect the result to the wider email infrastructure that controls inbox placement and business continuity.

Table of Contents

What an MX Record Does and Why It Matters The production consequence A practical first check MX Priority, Targets, and the Rules That Actually Apply Target validity matters Equal priorities Adding an MX Record Step by Step in Major DNS Panels Provider-agnostic setup Google Workspace and Microsoft 365 examples Multiple MX Hosts, TTL, and DNS Propagation TTL during a migration Verifying MX Records and Testing End to End Read the resolver view Test transport, not just DNS Common MX Mistakes and How to Fix Them Pointing to the wrong kind of target Reversing the preference order Creating an invalid hostname Leaving the old provider live MX in the Full Deliverability Stack and Next Steps Questions that often surface during a cutover

What an MX Record Does and Why It Matters

An MX record is a DNS record that tells sending mail servers where a domain accepts incoming email. When a sender delivers a message to user@example.com, the sender queries DNS for the domain's MX records, selects a target according to its preference value, resolves that target, and attempts SMTP delivery. SMTP relies on MX records to determine the destination mail server rather than using an IP address directly, as explained in Cloudflare's MX record overview.

MX records have a different job from other email DNS records:

MX routes incoming mail to receiving hosts.

SPF authorizes sending systems for a domain.

DKIM adds a cryptographic signature to outgoing messages.

DMARC evaluates alignment and publishes policy and reporting instructions.

A domain can pass SPF, DKIM, and DMARC checks while still failing to receive mail if its MX target is stale, unreachable, or unable to accept SMTP. That failure often appears as missing messages, delayed delivery, or sender-side retry errors rather than an obvious browser-style DNS error.

The production consequence

A syntactically correct record can still route mail to a dead server, a blocked port, or an old provider that refuses the recipient. A sender may then retry the preferred host, fall back to another configured host, or eventually return a non-delivery report. The business impact is direct: replies don't arrive, transactional messages fail, support conversations break, and a migration can damage trust even when outbound authentication is configured correctly.

The right question isn't only “Does the MX record exist?” It's “Can the published target receive mail end to end?”

A practical first check

Before changing anything, identify:

The domain's authoritative DNS provider.

Every published MX target.

The email provider that should receive mail now.

Whether each target resolves to an A or AAAA record.

Whether the intended server accepts SMTP connections.

Remove obsolete targets only after confirming that no active system still depends on them. An old MX entry isn't harmless clutter. It can divert delivery toward infrastructure that the organization no longer controls.

MX Priority, Targets, and the Rules That Actually Apply

MX records are ordered by ascending preference. The lowest number is tried first, so priority 10 comes before priority 20, and priority 20 comes before priority 30. The numbers are preferences, not performance scores. Microsoft guidance follows the same rule, with the primary mail router placed at the lowest number, often 0 in a multi-record setup.

The underlying standardization goes back to January 1986, when RFC 974 and RFC 973 replaced older mail-routing record types with MX and defined the preference field as an unsigned 16-bit integer, from 0 through 65535, with the lowest value tried first. The historical details are documented in the MX record reference.

Consider this configuration:

Priority	Target Host	Outcome
10	`primary.example.net`	Sender tries this host first
20	`backup.example.net`	Sender uses it if the preferred host is unavailable
30	`archive.example.net`	Sender reaches it only after higher-preference targets fail

If the host with priority 10 refuses the connection or times out, the sending system can try the next higher preference. A backup with a larger number isn't normally used while the primary is healthy.

Target validity matters

An MX target must be a fully qualified hostname, not an IP literal. That hostname must resolve through an A or AAAA record, and the resulting server must be prepared to receive SMTP traffic on port 25. A record such as mail.example.net is structurally useful only if DNS resolves it and the host is operational.

The target also shouldn't be an obsolete or conflicting entry from a previous provider. A zone can publish records that look neat in a control panel while still sending mail to an unavailable system.

Equal priorities

Multiple MX records can share the same preference. Sending systems may distribute delivery among those targets, creating a form of load balancing. This is different from a standby design, where the secondary target receives a higher preference and is used after the primary becomes unavailable.

Some DNS panels label the field preference, while others call it priority. The ordering can also look reversed in a visual interface. The safest practice is to inspect the actual published values, not rely on the panel's row order.

Adding an MX Record Step by Step in Major DNS Panels

The interface differs between DNS providers, but the record fields are consistent. The domain owner needs the correct receiving hostname from the mail provider, not an IP address copied from a server dashboard.

Provider-agnostic setup

Open the authoritative DNS zone. Select the apex domain that should receive mail. If the panel asks for a host or name, use @ or leave the field blank, depending on the interface.

Choose MX as the record type. Enter the fully qualified target hostname supplied by the mail provider.

Set the preference. Use the provider's documented value. If the setup has a primary and backup, the primary needs the lower number.

Choose a TTL. A normal post-migration value can sit in the 3600 to 86400 second range, while a shorter value is more flexible during a cutover. This operational range is described in MX change best-practice guidance.

Save and inspect the result. Some panels require one row per MX record. Others accept multiple values under one record type. Both interfaces can work if the authoritative output contains the intended targets and preferences.

Google Workspace and Microsoft 365 examples

For Google Workspace, the provider's current documentation should control the exact target set. A commonly supplied primary entry uses smtp.google.com with priority 1, alongside the documented aspmx fallback cluster. The entries should be copied exactly from the active administrative setup, because provider instructions can change.

For Microsoft 365, the tenant supplies a unique hostname in the form msXXXXXXX.mail.protection.outlook.com. That hostname can be entered with the provider's stated preference, commonly 0 or 10, but the tenant value matters more than a generic example.

Before saving, check whether the panel has a verification feature. It may detect a duplicate MX record, an invalid target format, or an existing parking record. For an additional controlled DNS test during a migration, teams can use the RETRO//STRESS DNS testing tool to inspect how the zone is being returned.

Multiple MX Hosts, TTL, and DNS Propagation

A valid MX record can still fail in production. If its target server is unreachable, blocked, misconfigured, or left stale after a provider migration, sending systems may defer or abandon delivery. Choose the record set around the receiving architecture, not around DNS syntax alone.

Setup Type	Example Priorities	Best Use Case	Trade-Off
Single target	One primary value	Small, provider-managed setup	Fewer records, less redundancy
Equal-priority targets	Same preference on two hosts	Distribution across receiving hosts	Both hosts must be healthy
Primary and backup	Primary lower, backup higher	Failover during an outage	Backup needs testing and maintenance

Multiple targets add capacity or failover only when every published host is monitored and able to accept SMTP connections. Equal-priority hosts may receive delivery attempts across the set. A higher preference value makes a host less preferred, so a backup with priority 100 normally remains unused while the primary is available. It becomes relevant when the preferred host refuses connections, times out, or cannot accept mail.

The sending system controls retry timing and selection details. DNS administrators cannot guarantee when a sender will try the backup. Test each target independently, keep its certificates and routing current, and remove retired hosts promptly.

TTL during a migration

TTL determines how long recursive resolvers may cache an MX answer. For a planned change, lower the TTL to about 300 seconds, wait for the previous TTL to expire, then publish the new target. Restore the normal TTL after delivery has been observed on the new infrastructure. A 24-hour TTL can delay a cutover by roughly a full day because cached answers remain valid after the authoritative zone changes. The RFC 974 information page provides the relevant standards context.

A controlled migration sequence is:

Prepare early: Lower the TTL about 48 hours before the planned cutover.

Add deliberately: Publish the new receiving host with its intended preference.

Observe traffic: Confirm that delivery attempts reach the new infrastructure and that the host accepts them.

Retire safely: Remove the old target only after the migration has been validated.

Propagation is not one global event. Recursive resolvers, ISP caches, and local systems can retain different answers until their individual cache periods expire. Changes may appear within minutes in some locations, while extreme caching cases can take up to 72 hours to be recognized universally. During that interval, senders may use different versions of the zone.

For a plain-language explanation of resolver caching, see what is dns propagation in email. A syntactically correct record is only the starting point. Confirm that each target is reachable, current, and prepared to receive mail before treating the migration as complete.

Verifying MX Records and Testing End to End

The authoritative DNS panel shows what was entered. A resolver lookup shows what sending systems may see. Both views matter during MX record configuration because a successful save doesn't prove that caches have updated or that the receiving server is reachable.

Read the resolver view

Run a short lookup from a workstation:

dig MX example.com +short

The response should show the published preference and target hostname. A second query can test a specific public resolver:

nslookup -type=mx example.com 8.8.8.8

An empty answer section can mean that no MX record is published or that the queried resolver hasn't received the new answer. A SERVFAIL response points to a DNS resolution problem that needs investigation before SMTP testing.

The response should be compared with the intended design:

Target names: Every hostname should belong to the active receiving infrastructure.

Preference order: The primary should carry the lowest value.

Record completeness: No legacy parking or retired-provider entries should remain.

Resolver consistency: Different resolvers should converge as cached answers expire.

The email deliverability DNS debugging guide provides additional context for reading MX results with nslookup.

Test transport, not just DNS

DNS verification is only the first layer. A hostname can resolve correctly while port 25 is blocked, the host is offline, or the SMTP service rejects incoming connections. A transport check should attempt a TCP connection to the MX target, open an SMTP session with EHLO, and confirm that the server returns a banner. A STARTTLS probe can then show whether the server advertises encrypted transport.

A complete checklist separates the layers:

DNS layer: MX exists and returns the expected target.

Resolution layer: Target resolves to A or AAAA records.

Transport layer: Port 25 accepts a connection.

SMTP layer: The server responds to the handshake.

Operational layer: The host accepts mail for the domain and doesn't route recipients into a failure loop.

A live diagnostic report can combine these checks. mailX, for example, runs MX lookup, SMTP connectivity, and STARTTLS checks in one report, helping flag a target that is syntactically valid but unavailable before real messages are attempted.

Common MX Mistakes and How to Fix Them

Production audits repeatedly find the same errors. Each one can look plausible in a DNS panel, which is why line-by-line verification matters more than visual confidence.

Pointing to the wrong kind of target

An MX record should point directly to a hostname that resolves through A or AAAA records. It shouldn't point to a CNAME, and it shouldn't contain an IP literal. The corrected design publishes the receiving hostname as the MX target and manages its address record separately.

Wrong: MX points to a CNAME alias.

Right: MX points directly to mail.example.com, with that hostname resolving through an A or AAAA record.

Resolvers and mail systems may reject or mishandle an invalid target. The failure can present as delayed or missing inbound mail rather than a clear configuration warning.

Reversing the preference order

A primary at 50 and a backup at 5 tells senders to try the backup first. The corrected arrangement assigns the lower value to the intended primary.

Wrong: Primary 50, backup 5.

Right: Primary 10, backup 20.

The absolute values are less important than their ordering. Administrators often leave gaps between values so future changes don't require renumbering every record.

Creating an invalid hostname

If a panel automatically appends the domain, entering a fully qualified target without understanding the interface can produce a duplicated name. A missing or unintended trailing dot in zone-file workflows can create an unresolvable hostname.

Wrong: A target becomes mail.example.com.example.com.

Right: The published target is the intended fully qualified hostname.

The same problem occurs when a hostname is entered but no A or AAAA record exists for it. DNS appears populated, but the sender cannot resolve the destination.

Leaving the old provider live

A registrar parking MX or a retired provider's record can intercept mail after a cutover. The correction is to remove obsolete entries after confirming that the new provider is live and that no required service still depends on the old target.

The operational fix is simple: inspect every target, resolve it, test SMTP, and compare it with the current provider's requirements. If a target is stale, don't assume that a higher-priority record makes it irrelevant. A failed primary can cause senders to fall back to a stale secondary.

MX in the Full Deliverability Stack and Next Steps

MX determines where incoming mail goes. SPF tells receiving systems which infrastructure is authorized to send for a domain. DKIM signs outgoing messages, while DMARC evaluates alignment between the visible From domain and authenticated sending identities, then applies a policy such as p=none, p=quarantine, or p=reject.

A sensible deployment order starts with inventory. Teams should identify every sending and receiving system, publish and validate SPF and DKIM, review DMARC reports before tightening enforcement, and confirm MX and SMTP availability before a provider cutover. A broken MX can hide the value of successful authentication because replies and system messages never reach the intended mailbox.

The broader Email Deliverability Best Practices framework should include both DNS records and live infrastructure checks. It isn't enough to collect a clean score while a receiving host is unreachable or a domain remains listed on a blocklist.

Questions that often surface during a cutover

Do MX records affect sending through a third-party SaaS tool?They primarily control inbound routing. Outbound deliverability from another service still depends on that service's authentication, alignment, reputation, and sending behavior, but replies to the domain depend on the published MX setup.

Can a domain receive mail without an MX record?Some senders may attempt fallback behavior under DNS rules, but relying on that is fragile. Domains that intentionally don't accept email can publish a null MX, defined by RFC 7505 as a single MX record with preference 0 and a zero-length target, without any other MX record alongside it.

What happens while the old MX answer is cached?Different senders can continue using the old target until their cached TTL expires. The new provider may be ready while some delivery attempts still reach the old infrastructure, so monitoring should continue through the transition and after the zone has converged.

The safest next step is a live MX lookup, target-resolution check, SMTP test, and broader deliverability review before cutover and again after the migration window. That workflow catches the failure that a DNS-only inspection misses.

mailX provides a free live diagnostic layer for MX, DNS, SPF, DKIM, DMARC, BIMI, blacklist status, SMTP, IMAP, and related infrastructure checks, with plain-English explanations and exact remediation steps. Visit mailX to validate the receiving path before changing providers, and connect it to an AI workflow through its API or MCP support so automated systems don't send or migrate blindly.