{"id":520,"date":"2026-10-27T01:02:15","date_gmt":"2026-10-27T06:32:15","guid":{"rendered":"https:\/\/photonconsole.com\/blog\/?p=520"},"modified":"2026-10-27T10:04:48","modified_gmt":"2026-10-27T15:34:48","slug":"zoho-mail-smtp-limits-for-transactional-sending","status":"publish","type":"post","link":"https:\/\/photonconsole.com\/blog\/zoho-mail-smtp-limits-for-transactional-sending\/","title":{"rendered":"Zoho Mail SMTP Limits for Transactional Sending"},"content":{"rendered":"\n

Search for Zoho Mail’s daily sending limit and you will not find one, because there isn’t a daily limit. The limit is hourly.<\/p>\n\n\n\n

And it is not a number. It is a range \u2014 between 50 and 500 external emails per hour \u2014 and which end of that range you get is decided by Zoho, based on how it currently assesses your sending.<\/p>\n\n\n\n

That is a genuinely difficult thing to build an application against. You cannot size a notification queue against a ceiling that moves, and you will not be told when it moves.<\/p>\n\n\n\n

Quick Answer: What Are Zoho Mail’s SMTP Limits?<\/h2>\n\n\n\n

From Zoho’s own rates, limits and policies<\/a> page:<\/p>\n\n\n\n

Limit<\/th>Figure<\/th><\/tr><\/thead>
External outgoing, per hour<\/td>50 to 500<\/strong>, assessed dynamically<\/td><\/tr>
Internal outgoing, per hour<\/td>1,000<\/td><\/tr>
Recipients per external email, paid<\/td>150 across To, Cc and Bcc<\/td><\/tr>
Recipients per external email, free<\/td>100 across To, Cc and Bcc<\/td><\/tr>
Recipients per internal email<\/td>500<\/td><\/tr>
Bulk or burst sending<\/td>Not permitted<\/strong> under the business usage policy<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

The limits are applied on a rolling one-hour basis rather than resetting at midnight. That last row is the one that settles the question, and we will come back to it.<\/p>\n\n\n\n

Figures change, so confirm against Zoho’s page before planning around them.<\/p>\n\n\n\n

Why “50 to 500” Is the Real Problem<\/h2>\n\n\n\n
\"Zoho
A ceiling that moves is harder to build against than a low one that does not.<\/figcaption><\/figure>\n\n\n\n

Most sending limits are a contract: you get this many, and you plan accordingly. Zoho’s external limit is an assessment.<\/p>\n\n\n\n

Zoho describes the range as dynamic, based on sender reputation, recipient engagement and contact quality. Those are reasonable things for a mail provider to care about. They are also all lagging indicators you do not directly control, and none of them are exposed to you as a number.<\/p>\n\n\n\n

The practical consequence is a tenfold uncertainty band. At the top of the range you can send 500 an hour, which is 12,000 a day and workable for a small product. At the bottom you can send 50 an hour \u2014 and a signup burst of 80 people will not clear within the hour.<\/p>\n\n\n\n

# The planning problem, stated plainly\n\n  Best case:   500\/hour  ->  ~12,000\/day\n  Worst case:    50\/hour  ->   ~1,200\/day\n\n  Which one applies to you right now?  Not published.\n  When does it change?                 Not notified.\n  What moves it back up?               Reputation, over time.<\/code><\/pre>\n\n\n\n
A published flat rate \u2014 PhotonConsole’s, or any dedicated provider’s \u2014 removes the guess entirely, because the number does not move. On Zoho Mail you can build for the worst case, which means provisioning for 50 an hour and accepting that ceiling permanently. Or you can build for the best case and discover the difference during your busiest week. Neither is a good position for transactional mail, where the whole point is that a password reset arrives in seconds.<\/p>\n\n\n\n
Common Mistake<\/p>\n\n\n\n
Testing against the top of the range and sizing your system accordingly. A new account sending clean, engaged mail to a short list will sit comfortably near 500 an hour, so early testing looks fine. The number that matters is the one you get after a few months of real users \u2014 including the ones who signed up with a typo, never opened anything, and marked a notification as spam. Those are exactly the signals that move the assessment downward, and growth makes them more likely rather than less.<\/p>\n\n\n\n
The Policy Line Most People Never Read<\/h2>\n\n\n\n
Underneath the figures, the same page lists bulk and burst sending as not permitted under the business usage policy<\/strong>, and marks it as not supported.<\/p>\n\n\n\n
This is not a throttle. It is a statement that the use case is outside what the product is for. Zoho then does something the other mailbox platforms do not do nearly as clearly: it tells you where to go instead.<\/p>\n\n\n\n
The page directs email marketing to Zoho Campaigns and transactional email to Zoho’s separate communications platform. In other words, the argument this article is making is already Zoho’s own position. They have built a different product for this, and the Zoho Mail documentation points at it.<\/p>\n\n\n\n
Zoho’s Own Three-Product Answer<\/h2>\n\n\n\n
\"Zoho's
Three products, three jobs. Application email was never Zoho Mail’s.<\/figcaption><\/figure>\n\n\n\n
Zoho splits email across separate products by purpose, and the split is clean.<\/p>\n\n\n\n
Product<\/th>Intended for<\/th>What it refuses<\/th><\/tr><\/thead>
Zoho Mail<\/td>Human correspondence from mailboxes<\/td>Bulk and burst sending, by policy<\/td><\/tr>
Zoho Campaigns<\/td>Marketing and newsletters<\/td>Not a transactional path<\/td><\/tr>
Transactional platform<\/td>Application and system email<\/td>Bulk, promotional and marketing mail<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Note<\/p>\n\n\n\n
A naming caveat worth knowing before you go looking. Zoho’s transactional email product has been presented under more than one name \u2014 many developers know it as ZeptoMail, while Zoho Mail’s current documentation directs transactional sending to Zoho CPaaS, and the ZeptoMail documentation URL now serves pages titled for CPaaS. If you search for one name and land on the other, that is why. Check which product and which plan applies to your own account rather than assuming, because the limits and the console differ.<\/p>\n\n\n\n
What the transactional product actually gives you<\/h3>\n\n\n\n
Its email limits documentation<\/a> describes a different model from Zoho Mail’s, and a more sensible one for applications.<\/p>\n\n\n\n
Rather than an externally-assessed range, you set your own thresholds. A blocking limit<\/strong> caps the emails an agent can send per day, with anything beyond it blocked and the count resetting at midnight server time. A warning limit<\/strong> sits below it as an early alert. Exceeding the blocking limit produces an SM_151<\/code> error on the API, or a “Process failed” status over SMTP with the message not sent.<\/p>\n\n\n\n
That is a limit you can plan against, because you chose it. The trade is the mirror image of Zoho Mail’s: the same documentation states the service supports transactional communications only, and does not support bulk or promotional email such as newsletters or marketing campaigns.<\/p>\n\n\n\n
So Zoho’s products do not overlap, and none of them is a general-purpose sender. You pick the right one per message type, or you accept a policy problem.<\/p>\n\n\n\n
Recipients Per Message, and the Internal Split<\/h2>\n\n\n\n
The recipient caps are worth separating out because the internal and external figures differ by a factor of three to five.<\/p>\n\n\n\n
External mail from a paid account allows 150 recipients across To, Cc and Bcc, and 100 on a free account. Internal mail \u2014 to addresses on your own domain \u2014 allows 500, with a separate 1,000 per hour outgoing limit.<\/p>\n\n\n\n
That gap tells you what the product is optimised for. Internal notifications to colleagues are comfortable. Customer-facing mail is deliberately tighter, because customer-facing bulk mail is what the usage policy excludes.<\/p>\n\n\n\n
Quick Fix<\/p>\n\n\n\n
Sending Stopped and Resumed Without You Changing Anything<\/p>\n\n\n\n