Email MX Records: Configuration and a Safe Switchover

An MX record tells sending mail systems where to deliver messages for your domain. When someone writes to info@example.uz, the sender's server queries MX for example.uz, selects a suitable host, and opens an SMTP connection. A mistake in one DNS record can therefore affect all incoming mail for the domain even while the website continues to work normally.

MX does not create mailboxes, move historical messages, or authorize a server to send on behalf of the domain. Those jobs require configured mailboxes, SMTP and IMAP, and SPF, DKIM, and DMARC. The relationship is explained in “SPF, DKIM, and DMARC: How a Domain Authenticates Email”.

What an MX record contains

An MX record has three important parts: the domain name, priority, and receiving-server name. A sample record looks like this:

example.uz.  3600  IN  MX  10  mail.example.uz.

example.uz is the domain receiving mail. 3600 is the TTL—the period for which a DNS response may remain cached. 10 is the priority, and mail.example.uz is the mail server's fully qualified domain name.

Lower priority numbers are preferred. With MX records at 10 and 20, a sender tries the host at 10 first and may try 20 if the first is unavailable. Equal priorities permit selection among several servers, but they do not create a reliable cluster by themselves. Queue, mailbox, and delivery-rule synchronization must still be designed separately.

The MX target must be a hostname, not an IP address. That name needs a valid A record, AAAA record, or both. Under SMTP rules, an MX target must not be a CNAME alias. Cloudflare adds another distinction: a normal mail host is published as DNS only. The standard Cloudflare HTTP proxy does not accept SMTP traffic on behalf of your mail server.

How a sending server selects the route

The process begins with a DNS query, not by opening the website or checking a hosting panel. The sender receives the MX list, orders available targets by priority, resolves the selected name to an IP address, and attempts an SMTP connection. If the connection fails temporarily, the sender normally queues the message and retries according to its own policy.

This clarifies two common misconceptions. First, MX primarily controls incoming mail. For outgoing mail, the client uses the SMTP server in its settings, while other mechanisms authenticate the message. Second, a backup MX is useful only when it can safely accept mail for your recipients and pass it to the main system. An arbitrary second server may introduce another failure point or an avenue for unwanted mail.

If a domain has no MX record, SMTP defines a fallback attempt to the domain itself, but a production configuration should not depend on it. An explicit, correct MX record makes the route clear, testable, and portable between providers.

What to prepare before changing DNS

Begin with a short inventory, not the Save button. You need a complete list of active addresses, aliases, groups, and forwarding rules. Every address that clients or services already use must have a defined destination in the new system. Otherwise DNS will route messages to a server that does not recognize the recipient.

Before changing MX, confirm that:

• all required mailboxes and aliases exist;
• the new server accepts the domain and individual recipients;
• its SMTP port is reachable from outside the network;
• the server name matches its TLS certificate;
• SPF, DKIM, and DMARC are ready for outgoing mail;
• access to the old system remains available for archive migration;
• the previous TTL is known and DNS cache time has been allowed for.

Old messages do not “move through MX.” MX determines the route for new incoming mail. The archive is copied separately, often through IMAP, and then checked by folder and message count. See “Migrating Business Email Without Losing Incoming Messages” for the full sequence.

How to switch with less risk

You can lower the TTL ahead of a planned migration so future changes leave caches sooner. This helps only after the previous, longer TTL has expired; cached answers do not disappear from other resolvers on command. Once the change is verified, restore a normal TTL to avoid unnecessary DNS queries.

A practical sequence is:

1. Record the current MX, A/AAAA, SPF, DKIM, and DMARC values and the time checked.
2. Prepare and test the new mail system before changing the public route.
3. Lower the TTL in advance if the DNS panel and schedule permit.
4. Replace MX with the supplied server name and enter the priority as a separate number.
5. Verify that the MX target resolves to the expected IP and is not proxied as web traffic.
6. Send test messages from several independent external services.
7. Monitor reception logs, queues, and errors on both the old and new servers.
8. Keep the old system running until the agreed observation period and archive migration are complete.

Mailcore prepares MX, SPF, DKIM, and DMARC values for the specific domain and validates them before switchover. Public MX remains unchanged until approval and control tests are complete. This process reduces organizational error, accounts for DNS caches, and includes tests from external senders. See how to connect business email to your domain for the full setup guide.

How to check the result from several locations

The DNS panel shows the zone owner's intent; the public response from authoritative servers is what matters. Query it with:

dig MX example.uz
dig A mail.example.uz

On Windows, use nslookup -type=mx example.uz. Inspect the MX target, priority, TTL, and target address. Repeat the query through another public resolver or external network because your local provider may still have an old response cached.

After checking DNS, confirm real delivery: send a message to the new mailbox, reply from it, and inspect the technical headers. For an incoming test, confirm acceptance and the correct final mailbox. For an outgoing test, inspect SPF, DKIM, and DMARC results, the server's reverse name, and the recipient's response. These checks establish the technical basis for deliverability; the recipient still makes the final filtering decision.

Common mistakes and their consequences

An IP address instead of a hostname. The MX target field takes a domain name. The IP belongs in that name's A or AAAA record.

MX on a subdomain instead of the root. A record for mail.example.uz does not control messages to user@example.uz. DNS panels commonly represent the root as @, a blank field, or the domain itself; the interface determines the format.

Proxying the mail host. Cloudflare's orange cloud is for supported proxy traffic. A normal SMTP mail host remains DNS only.

Removing the old MX before mailboxes are ready. The new server may reject real recipients. Create and test addresses before changing the route.

Turning off the old service too early. Some senders may still see a cached MX value. A transition period and monitoring of both systems helps catch these deliveries.

Expecting MX to fix outgoing deliverability. MX is for receiving. Investigate outgoing problems using SMTP responses, authentication headers, reputation, and recipient rules. See why messages go to spam for a practical guide.

Short checklist

Before saving, make sure MX belongs to the correct domain, contains a hostname, and has the right priority. Check the target's A/AAAA record, absence of accidental web proxying, readiness of all addresses, and continued access to the old system. Afterward, query public DNS, run incoming and outgoing tests, retain the technical headers, and monitor queues.

The core principle is simple: MX is a route pointer, not a migration tool or a certificate of email quality. A dependable switchover follows an agreed sequence—prepare the server, validate the records, change the route, test actual delivery, and only then retire the previous arrangement.

Sources

• RFC 5321: Simple Mail Transfer Protocol
• Cloudflare: DNS records for email
• Cloudflare: Network ports compatible with the proxy
• Google Workspace: Troubleshoot MX records