Route by the limits that actually exist.
Every provider has per-hour and per-day caps. Mailers.io respects them — queueing, rotating, and failing over based on real-time quota state across every sending server you attach.
- Caps respected
- Per hourCaps respected
- Caps respected
- Per dayCaps respected
- Tiered routing
- PriorityTiered routing
- On cap or error
- FailoverOn cap or error
Sending limits are not a suggestion. They are the system.
Providers throttle for good reasons: shared infrastructure, reputation protection, abuse prevention. When your app hits a cap, the provider returns an error. Most apps either drop the send, retry into another error, or quietly lose the message.
Quota-aware routing treats those caps as first-class state. We track per-server usage in real time. Sends are routed to the highest-priority server that still has capacity. When every server is full, new sends queue. Nothing silently fails.
Quota state as a core routing input.
- Step 1
Configure caps
Set max per hour and max per day for every sending server — ESP or SMTP. Combine with priority levels.
- Step 2
Track in real time
The platform meters every send per server. Current usage is visible at any moment via dashboard or API.
- Step 3
Route or queue
New sends go to the top-priority server with capacity. Full servers are skipped; if all are full, sends queue.
Why routing by quota beats round-robin.
Per-hour and per-day caps
Two independent windows, enforced together. Reflects how providers actually rate-limit in practice.
Priority tiers
High-priority servers (e.g. your best-performing ESP) always fill first. Secondary servers catch overflow.
Automatic failover
Provider error or throttle? Sends fall through to the next healthy server in the pool.
Pool composition
Group servers by purpose — transactional pool, marketing pool, cold pool — and route independently.
Real-time quota dashboard
See current usage and remaining capacity per server. No guesswork on burst days.
Burst absorption via queue
When the stack is full, sends queue cleanly with timestamps. No silent drops, no duplicate retries.
Alerts on cap conditions
Get notified before a pool runs dry. Headroom, not surprises.
Reputation-safe by design
Caps reflect the provider's own limits. Honouring them is how reputation stays intact.
- You send high volume across multiple providers
- You have been surprised by provider throttle errors in production
- You want bursts to queue instead of drop
- You want clear visibility into remaining capacity
- Provider-side caps still exist; we honour them, not override them
- Quota math is only as accurate as the caps you configure — set them to match your actual plan limits
- Failover does not guarantee delivery; if every provider errors, the platform alerts and queues
Questions answered clearly.
Respect the caps. Protect the reputation.
Quota-aware routing turns every provider into a managed capacity pool instead of a single point of failure.