Zoho Mail Not Receiving Emails on a Custom Domain: Fix Checklist

Someone emails your custom-domain address and it never shows up in Zoho Mail — no bounce to the sender, nothing in your inbox, nothing obviously wrong in the admin console. That gap between "nothing looks broken" and "mail isn't arriving" is what makes this error frustrating: there's no single error message to search for, just an absence.

The good news is the list of actual causes is short. Almost every case comes down to MX records, domain verification, or spam filtering, and each one leaves a specific trace you can check in under five minutes.

What this error literally means#

"Not receiving emails" on a custom domain almost always means one of two things is true: the sending mail server never found Zoho's servers to deliver to, or it found them and Zoho rejected or quarantined the message before it reached your inbox.

The first case is a DNS problem — MX records that don't point at Zoho, or point at Zoho and something else at the same time. The second is a Zoho-side policy problem — domain verification incomplete, or a spam/incoming-mail rule catching messages that should have landed.

• DNS-side: MX records missing, wrong, or still cached from the old provider
• Zoho-side: domain not verified, or incoming policy quarantining the message
• A third, less common case: the mailbox itself was never created for that address

Causes table: cause, how to confirm, fix#

Fix 1: correct the MX records#

MX records tell the internet which servers handle mail for your domain. If they still point at a previous host — or a registrar's default parking page — mail addressed to your custom domain never reaches Zoho at all, and the sender usually gets no bounce because their server did successfully deliver to whatever the MX record pointed at.

For a Zoho Mail organization created under the standard zoho.com data center, the MX records are mx.zoho.com (priority 10), mx2.zoho.com (priority 20), and mx3.zoho.com (priority 50). If your organization was created under a regional data center (zoho.eu, zoho.in, zoho.com.cn, and similar), the hostnames carry that region instead — check the exact values shown in your own admin console rather than assuming the .com set, since using the wrong region's MX records will not deliver mail even though they look almost identical.

1. 1

   Open your DNS provider's control panel

   This is wherever you manage DNS for the domain — your registrar, or a separate DNS host like Cloudflare.

2. 2

   Find the current MX records

   Look for any existing MX entries. Note every one, including priority numbers — you'll need to remove non-Zoho entries in the next fix.

3. 3

   Add or update MX records to Zoho's values

   Use the exact hostnames and priorities shown in Zoho Mail's admin console under Domains > MX for your specific organization.

4. 4

   Wait for propagation

   DNS changes can take anywhere from a few minutes to 48 hours to fully propagate, depending on the previous record's TTL.

Fix 2: remove leftover MX entries#

This is the cause that looks the most like it should already be fixed. You added Zoho's MX records, they show up correctly in a lookup, and mail still doesn't arrive — because an old MX record from a previous provider is still sitting in DNS alongside them.

Mail servers try MX records in priority order, lowest number first, and fail over to the next one only if the first is unreachable — not if it's simply the wrong destination. If an old record still resolves to a live server (even a dead mailbox on that server), incoming mail can land there instead of Zoho, and nothing about that failure is visible from the Zoho side.

1. 1

   List every MX record currently on the domain

   Use an external MX lookup tool rather than your DNS panel's own cached display, which can lag behind the live record.

2. 2

   Identify anything that isn't mx.zoho.com / mx2.zoho.com / mx3.zoho.com (or your region's equivalents)

   Common leftovers: a previous host's mail servers, a forwarding service, or a placeholder record a template added automatically.

3. 3

   Delete the non-Zoho records

   Zoho should be the only mail exchanger for the domain. Keep the three Zoho MX entries at their documented priorities.

4. 4

   Re-run the MX lookup to confirm

   Only Zoho's records should appear. If an old record persists after deletion, check for a duplicate zone or a cached DNS resolver.

Fix 3: finish domain verification#

Zoho requires proof that you control the domain before it will route mail for it. Until verification completes, the domain sits in a pending state in the admin console — and depending on how far setup got, mail can bounce back to the sender or simply not be accepted, rather than reaching a mailbox.

Zoho offers a few verification methods: adding a TXT record, adding a CNAME record, or uploading an HTML file to the domain's web server. Pick whichever your DNS or hosting setup makes easiest — they're equivalent, not tiered.

1. 1

   Open Domains in the Zoho Mail admin console

   Check the status column for your domain. "Verified" should appear before you rely on MX routing.

2. 2

   Choose a verification method

   TXT record, CNAME record, or HTML file upload — the console shows the exact value to add for whichever you pick.

3. 3

   Add the record or file, then trigger verification

   Return to the admin console and confirm verification. DNS-based methods may need a few minutes to propagate before the check succeeds.

How to tell which cause you have#

Start outside Zoho, not inside it. An external MX lookup tool run against your domain tells you in seconds whether the problem is DNS-side or Zoho-side, and that split cuts the diagnostic tree in half immediately.

• MX lookup shows no Zoho records at all → Fix 1: MX records were never set
• MX lookup shows Zoho records plus another host → Fix 2: remove the leftover entry
• MX lookup is correct and Zoho-only, but the console still flags the domain unverified → Fix 3: finish verification
• MX and verification both check out, but the message is sitting in Spam or a quarantine folder in the admin console → adjust the incoming policy or allowlist the sender
• The address doesn't exist under Users in the admin console at all → the mailbox itself needs creating

Preventing it#

Most of these failures trace back to a migration or a DNS change made without a follow-up check. Two habits catch almost everything before it becomes a support ticket.

First, whenever you touch DNS for a domain that receives mail, run an external MX lookup immediately after — not the next day, right after. Second, check the Zoho admin console's domain status and quarantine folder on a schedule, not only when someone complains mail didn't arrive, since silent quarantines don't generate an alert on their own.

The reason a quarantined message is invisible from the sender's side is that Zoho's incoming policy evaluated the message, decided to hold it, and never generated a bounce — the sender's server has no idea anything happened after acceptance. AI Emaily's spam and cold-email filtering runs after the message has already landed in a connected mailbox, scoring sender behavior and domain reputation rather than making a single silent accept-or-drop call, and every action it takes is visible in an audit log you can review and reverse. We build AI Emaily.