After a company switches on its own email, the most common complaint is: "I can send mail, but nothing reaches us." The culprit is almost always the MX record. The MX (Mail Exchanger) record tells other mail servers which server should receive mail for your domain. If it is wrong, the sending server delivers mail to the wrong place, or cannot find a destination at all and bounces the message after retrying for a while. Here are the six causes we see most often and how to check each one.
Start by looking at the current state
Before changing anything, see how your MX records look to the rest of the world. Each record shows a priority and a mail server name; the lower the number, the higher the priority.
dig misol-mebel.uz MX +short
10 mail.misol-mebel.uz.
dig mail.misol-mebel.uz A +short
203.0.113.251. The MX points to an IP address
An MX value must be a host name, not an IP address. Some DNS panels accept an IP anyway, but the standard requires a name and many mail servers treat such a record as invalid. Create an A record for mail.misol-mebel.uz first, then use that name in the MX.
2. The MX target has no A record or is a CNAME
The MX may name a host that leads nowhere: its A record was deleted or still holds the old server's IP. Standards also forbid an MX target from being a CNAME. Many servers follow it anyway, but relying on that is risky, so give the target its own A (and if needed AAAA) record.
3. Old MX records were never removed
When changing providers, people add the new MX and forget the old one. If the old server has a lower number, most mail goes there, where mailboxes are deleted or unread. If both share the same priority, mail is split randomly and staff report that "some messages arrive and some do not".
4. The record is on the wrong name or lacks a trailing dot
The MX belongs on the domain itself, usually shown as @ in panels. Putting it on mail or www leaves info@misol-mebel.uz with no MX at all. In hand-edited zone files, a name without a trailing dot gets the zone name appended.
; wrong: becomes mail.misol-mebel.uz.misol-mebel.uz
@ IN MX 10 mail.misol-mebel.uz
; right: trailing dot
@ IN MX 10 mail.misol-mebel.uz.5. The record was changed where DNS is not hosted
DNS can only be managed where the domain's NS records point. If the NS points to Cloudflare and you edit MX in the hosting panel, nobody sees the change. Find the name servers first, then query them directly.
dig misol-mebel.uz NS +short
dig @ns1.misol-dns.uz misol-mebel.uz MX +short6. DNS is fine but the mail server rejects the domain
Sometimes the MX is perfect and mail still bounces. Then the problem is on the server: the domain is not configured as local, the mailbox does not exist, or it is full. The bounce text tells you which: "User unknown", "Relay access denied" or "Mailbox full". Also confirm the server answers on port 25.
nc -vz mail.misol-mebel.uz 25Example: a furniture shop after moving its mail
A furniture shop in Tashkent kept its site where it was and moved mail to a separate corporate service. Sales reported that half of the order emails were missing. dig MX showed two records, the new server and the old hosting server, both with priority 10, so mail was split between them. After the old MX was deleted and the TTL expired, everything arrived at the new server, and messages from the old mailbox were moved by hand.
What to expect after the change
Senders keep the old answer cached for the record's TTL, so lower the MX TTL a day before a planned migration. Temporarily undeliverable mail is usually queued and retried for hours or days rather than lost at once. If your domain and mail are at sayt.uz, you can compare MX and the related A records side by side in the cabinet's DNS section.