Ensure your Zimbra server has correct DNS settings, including the **MX (Mail Exchange) records**. MX records determine the email routing for your domain. Use a DNS lookup tool to verify they point to the correct server.
Make sure your **firewall is properly configured to allow incoming email traffic** (port 25, 110, 143, etc.) to the Zimbra server. Also, check the **network connectivity** between your server and the external world.
Check the status of Zimbra services (SMTP, POP3, IMAP) to ensure they are running. Then, examine the mail server log files for specific error codes or warnings related to delivery failures.
Verify your Zimbra server's Spam Filtering and Antivirus settings aren't overly aggressive. If using a client (Outlook, Thunderbird), verify the Email Client Settings (server address, ports, credentials).
Test with another email account to check if the issue is sender-specific. If all else fails, consult Zimbra documentation and Support for server-version specific guidance.
Many businesses start by fixing a mail issue in isolation. Something stops working, users complain, and the immediate goal becomes restoring flow. But email systems rarely operate on their own. What looks like a simple “i can send but cannot receive mail service” situation often traces back to decisions made across hosting, DNS, security layers, even past migrations. In practice, one fix leads to another question. Mail routing points to server configuration. That connects to how domains are managed. Then comes filtering, authentication, and how different tools are allowed to interact. It doesn’t stay contained for long. We’ve seen teams resolve the surface issue, only to face repeated disruptions a few weeks later. Not because the fix was wrong, but because adjacent systems were left untouched. Email depends on alignment. Small mismatches build up quietly. So while the starting point may be a receiving issue, the work often expands. Infrastructure, access controls, monitoring. Sometimes even application behaviour. Each layer influences whether messages reliably reach the inbox or disappear without a trace. That’s usually when businesses begin exploring the surrounding areas. Not as separate services, but as connected decisions that need to hold together over time.
Different kinds of teams. Some running lean setups, handling things internally until something breaks. Others with structured IT environments, still facing unexpected mail flow issues at odd hours. Ecommerce businesses where a missed email means a missed order update. Service companies where client communication depends entirely on timely inbox delivery. Internal teams who only notice the problem when escalations start piling up. A few come in after trying multiple fixes. DNS changes, server tweaks, switching providers. Things improve for a while, then the same pattern returns. Slightly different, but familiar. There are also teams in transition. Moving platforms, restructuring systems, or tightening security. Email tends to be the first place where misalignment shows up. Some know exactly what’s wrong. Others just know something isn’t adding up. The context changes. The underlying patterns, less so.
If you can send mail but nothing is coming in, your MX (Mail Exchanger) Records are likely pointing to a "Black Hole." This happens after a DNS migration or a domain renewal lapse. The world is trying to deliver mail to an IP that no longer hosts your mailbox. At JIL, we see ₹2 Lakh ($2,170) B2B contracts vanish because a client changed their "Nameservers" and forgot to port the MX entries. Use dig mx yourdomain.com—if you don't see our server listed, you don't exist to the outside world.
Your "Sent" folder works because it’s just pushing data out, but your "Inbox" is a physical container on the server. If that container is 100% full, the server will "Bounce" every incoming message with a 552 5.2.2 Over Quota error. You’re trying to pour water into a full glass. Upgrading your storage (roughly ₹1,200 or $13 extra) is a 5-minute fix, but the "Missing" emails are gone forever—they won't "catch up" once you clear space. In 2026, if you aren't monitoring your Zimbra Quota Alerts, you're just waiting for a blackout.
"But I updated my MX records 2 hours ago!" That doesn't matter to a mail server in London that has your old records cached for 24 hours. This is TTL (Time To Live) Friction. If your old host had a high TTL, you are in a "Dark Window" where half the world sees your new JIL server and the other half sees a "User Not Found" error. It’s a ₹0 problem that only time can fix. Don't keep "Testing" it; you're just filling your logs with junk.
If your records are perfect but the inbox is still empty, our SpamAssassin / Amavis layer might be too aggressive for your sender. If a vendor is sending from a server with no SPF or DKIM, JIL’s security will drop the connection before it even hits your "Junk" folder. This "Silent Drop" is a security feature, not a bug. We can whitelist specific IPs for a ₹1,500 ($16) audit fee, but we’d rather you tell your sender to fix their 1990s-era mail setup.
Is the mail actually missing, or is your IMAP IDLE connection just "Hung"? We’ve seen users complain about "Not Receiving" when the webmail shows 50 new messages. Your Outlook or Mac Mail has stopped "Listening" to the server. Close the app, kill the process, and restart. If you’re still using POP3 in 2026, you deserve the sync issues you’re getting. Switch to IMAP or MAPI; otherwise, you’re just gambling with your data integrity.
Fill out the form and our team will get back to you shortly. We are here to help you with your queries and support.
