When someone sends a message to name@example.uz, their mail server first asks DNS where mail for example.uz should go. The answer comes from MX records. This article explains how they work, how to check them, and which mistakes come up most often.
What an MX record is
MX (Mail Exchanger) is a DNS record type that lists the servers accepting mail for a domain. Each MX record has two parts: a priority number and the hostname of a mail server.
example.uz. 3600 IN MX 10 mx1.example.uz.
example.uz. 3600 IN MX 20 mx2.example.uz.
mx1.example.uz. 3600 IN A 192.0.2.10
mx2.example.uz. 3600 IN A 198.51.100.20Here, mail for example.uz is accepted by mx1 and mx2, and their IP addresses are defined by separate A records. Note that an MX record always points to a hostname, never directly to an IP address.
Delivery works like this:
- The sending server takes the domain from the recipient address (everything after
@). - It looks up the MX records for that domain.
- It sorts them by priority and tries to connect over SMTP on port 25.
- If a server is unreachable, it tries the next one. If none respond, it queues the message and keeps retrying, usually for several days.
If a domain has no MX records at all, the standard (RFC 5321) says senders should fall back to the domain's own A record. Don't rely on that: an explicit MX record is more predictable and easier to troubleshoot.
Priority: lower number wins
The number in an MX record is its preference value. The lower the number, the higher the priority, so a server with priority 10 is tried before one with priority 20.
| Setup | Behavior |
|---|---|
10 mx1, 20 mx2 | mx1 is primary; mx2 is used only when mx1 is unavailable |
10 mx1, 10 mx2 | Load is spread roughly evenly between the two |
A single 10 mx1 | One server; during an outage, messages wait in the sender's queue |
Only the relative values matter: 10/20 behaves exactly like 1/5. Steps of 10 are a common convention because they leave room to add a server in between later.
Don't add a backup MX from an old or third-party service "just in case." If the backup server doesn't know your mailboxes or filters spam poorly, it becomes a path for spam and lost messages.
TTL: how fast changes take effect
TTL (time to live) is how many seconds other DNS servers may cache a record. With a TTL of 3600, some senders may keep using the old MX for up to an hour after you change it.
- For normal operation, 3600–86400 seconds (one hour to one day) is fine.
- Before moving to a new mail provider, lower the TTL to 300–600 seconds a day or two in advance so the switch propagates faster.
- Once the move is done and verified, raise the TTL back.
For a full switchover plan, see our guide to migrating email without losing messages.
How to check MX records
Windows: nslookup
nslookup -type=mx example.uzTo query a specific public resolver instead of your ISP's cache, add its address at the end, for example nslookup -type=mx example.uz 8.8.8.8.
Linux and macOS: dig
dig MX example.uz +short
10 mx1.example.uz.
20 mx2.example.uz.Then confirm that each server name resolves to an IP address:
dig A mx1.example.uz +short
192.0.2.10It also helps to compare the domain's authoritative server with public resolvers. Find the authoritative servers with dig NS example.uz +short, then query one directly: dig @ns1.example.uz MX example.uz. If the authoritative server already returns the new data but a public resolver still shows the old one, you just need to wait for the TTL to expire.
Online tools such as mxtoolbox.com show your MX records and test whether the servers respond. They're handy when you don't have a command line nearby.
Common mistakes
| Mistake | What happens | Fix |
|---|---|---|
| MX points to an IP address | The record is invalid; some senders won't deliver | Use a hostname and define its IP with an A record |
| MX points to a CNAME | Not allowed by the standard; sender behavior is unpredictable | Point MX to a name that has its own A record |
| Old MX records left next to new ones | Some mail still goes to the old server | Remove every MX record of the previous provider |
| Missing trailing dot in a zone file | You end up with mx1.example.uz.example.uz | Use the full name with a trailing dot in zone files; in web panels, follow the panel's format |
| Records added in the wrong place | Edited at the registrar while DNS is hosted elsewhere | Check the NS records and edit the zone where they point |
| Record created for a subdomain | The name field says mail instead of the root | For the root domain, use @ or leave the field empty, depending on the panel |
The last two are the most common. If you're not sure where your domain's DNS is managed, see our article on choosing and registering a domain.
MX is only part of the setup
MX handles incoming mail. To keep your outgoing messages out of spam folders, your domain also needs SPF, DKIM, and DMARC. These are separate TXT records and don't replace MX.
For domains that never receive mail, there is the "null MX" (RFC 7505): a record of MX 0 . tells senders not to bother, so they bounce the message right away instead of retrying for days.
When you connect a domain to MCMail, we send you the exact MX and other DNS records. If mail stops arriving after an MX change, message our support at @mycloudsupport and include the output of dig MX or nslookup so we can find the cause faster.