Daily and hourly sending limits are the per-period dispatch caps that protect your IP reputation by preventing sudden large volume spikes — the primary trigger for ISP spam filtering and blacklisting. This article explains exactly how these limits work, when they reset, how messages behave when limits are reached, and strategies for working effectively within them.
Why Daily and Hourly Limits Exist
Internet Service Providers (Gmail, Outlook, Yahoo) use sending volume patterns as a key spam signal. A sender that suddenly dispatches 10,000 emails in one hour — especially from a relatively new IP or domain — triggers automated spam filters and temporary blocks. Daily and hourly limits protect you from this by enforcing a sending cadence that looks natural and trustworthy to receiving mail servers.
Limits Per Plan
| Plan | Monthly Quota | Daily Limit | Hourly Limit | Per-Minute Rate |
|---|---|---|---|---|
| 10k Plan | 10,000 | 500 | 50 | ~1 |
| 20k Plan | 20,000 | 1,000 | 100 | ~2 |
| 30k Plan | 30,000 | 1,500 | 150 | ~3 |
How the Limits Reset
| Limit Type | Reset Trigger | Reset Time |
|---|---|---|
| Monthly quota | Billing period renewal | Your plan renewal date at midnight UTC |
| Daily limit | Calendar day rollover | Midnight in your configured timezone (e.g. 00:00 IST = 18:30 UTC previous day) |
| Hourly limit | Clock hour rollover | Top of every clock hour (00 minutes) in your configured timezone |
What Happens When a Limit Is Reached
| Limit Reached | Behaviour | Message Status |
|---|---|---|
| Hourly limit hit | New send requests are accepted but queued — messages wait for the next hour window to open | Queued — will deliver when hourly window resets |
| Daily limit hit | New send requests are accepted but queued — messages wait until midnight reset | Queued — will deliver at start of next day |
| Monthly quota exhausted | All send requests are rejected — no queuing occurs | Rejected — messages do not send until quota renews or plan is upgraded |
Viewing Your Current Usage in Real Time
Via Dashboard
The Plan Details panel on the MigoSMTP dashboard shows current quota usage. For daily and hourly usage, check the top banner which shows today's sent count, and the 7-day volume chart for daily patterns.
Via API
GET https://api.migosmtp.com/v1/account/usage
Authorization: Bearer YOUR_API_KEY
{
"daily_limit": 1500,
"daily_used": 842,
"daily_remaining": 658,
"hourly_limit": 150,
"hourly_used": 67,
"hourly_remaining": 83,
"daily_reset_at": "2026-06-08T18:30:00Z",
"hourly_reset_at": "2026-06-07T16:00:00Z"
}
Strategies for Working Within Limits
For Transactional Email (OTPs, Password Resets)
- Keep a real-time buffer — never let your hourly usage reach above 80% during peak hours. If usage is high, delay non-critical transactional sends (like newsletter confirmations) while prioritising OTPs and resets.
- Monitor the
hourly_remainingfield via API before each send in high-traffic periods. - Consider upgrading to a higher plan if your peak-hour OTP volume consistently approaches the hourly limit.
For Marketing/Bulk Email
- Schedule bulk sends to start at the beginning of the day (just after midnight reset) to maximise the day's available capacity.
- Split large campaigns across multiple days using the
send_atparameter to stay within daily limits. - Avoid sending bulk campaigns during peak transactional hours (9 AM – 12 PM IST) — schedule them for the afternoon or overnight.
Monitoring Limits Programmatically
// Before each bulk send, check remaining capacity
async function canSendBulk(recipientCount) {
const usage = await migosmtp.getUsage();
if (usage.monthly_remaining < recipientCount) {
throw new Error(`Monthly quota insufficient: ${usage.monthly_remaining} remaining`);
}
if (usage.daily_remaining < recipientCount) {
const resetTime = new Date(usage.daily_reset_at);
console.log(`Daily limit reached. Scheduling for ${resetTime.toLocaleString()}`);
return { canSend: false, scheduledFor: usage.daily_reset_at };
}
return { canSend: true };
}