Queue safety · 11 min read
Gmail bulk sender limits: a four-second queue is not safe.
A fixed dequeue interval does not make transactional email compliant. Safe delivery starts with domain-wide accounting, quotas before enqueueing, authenticated sending, durable retries and OTP-aware expiry.
The rate calculation
One message every four seconds compounds quickly.
That pace is more than four times 5,000 messages per day. A queue timer is a throughput control—not a recipient, tenant, abuse or reputation policy.
01 / Classification
Five thousand is a classification threshold, not a target.
Gmail evaluates messages sent to personal Gmail accounts across the whole primary sending domain. Changing the local part or moving traffic to a subdomain does not create a separate allowance. SenderMesh therefore tracks Gmail-directed volume across sendermesh.com as one domain-wide stream.
The theoretical evenly spaced interval for 5,000 messages in 24 hours is:
That arithmetic is useful for capacity planning, but 4,999 is not a compliance strategy. Google’s classification persists after a domain crosses the threshold, and sender requirements are good engineering practice before that point.
Alert near 4,000 Gmail-bound messages/day. Require a human review near 4,500/day. Treat either event as a capacity and reputation checkpoint, not permission to race toward the threshold.
Read Google’s bulk sender FAQ and email sender guidelines alongside your own Postmaster Tools data.
02 / Quotas before enqueueing
Reject or challenge abusive demand before it becomes queue depth.
Every accepted job consumes storage, retry capacity and sender reputation. Apply limits atomically before enqueueing so parallel requests cannot oversubscribe the same allowance.
| Scope | Initial limit | Concrete effect |
|---|---|---|
| Email identity | 1/min · 5/hour · 10/day | Slows resend abuse against one recipient. |
| IP or device | Around 20/hour | Contains distributed account targeting from one source. |
| Evaluation client | 100/day | Limits unproven integrations while traffic is reviewed. |
| Verified client | 1,000/day | Supports normal production use with an attributable tenant. |
| Primary domain | Track all Gmail-bound volume | Prevents subdomains and clients from hiding aggregate load. |
Use generic public responses so the limiter does not reveal whether an account exists. Internally, keep enough privacy-reduced metadata to investigate abuse without storing message bodies or plaintext API tokens.
03 / Sender controls
Rate limits cannot compensate for an unauthenticated sender.
SPF
Authorize the infrastructure that uses the SMTP envelope sender.
DKIM
Sign mail with a domain that aligns with the visible From address.
DMARC
Publish policy and reporting; verify alignment, not only pass results.
TLS
Require encrypted transport between SenderMesh and downstream MTAs.
Reverse DNS
Ensure the sending IP resolves to a valid, stable mail hostname.
Spam rate
Monitor complaints continuously; keep below 0.3%, ideally below 0.1%.
Authentication and reputation are continuous controls. Watch bounces, complaints, quota rejections and aggregate Gmail-bound volume together rather than treating a successful SMTP response as final delivery.
04 / Queue design
Choose a queue that can represent time, priority and ownership.
A Redis list using RPUSH and BLPOP is acceptable for a prototype. It is simple and fast, but scheduled retries, priority work and crash recovery require additional bookkeeping.
Prototype
Redis list
- Minimal operational surface
- Good for disposable early traffic
- Manual recovery semantics
Preferred
Streams or sorted set
- Consumer ownership or due-time scores
- Retry and priority scheduling
- Better crash recovery
For one low-volume server, SQLite in WAL mode is also acceptable. Keep the database outside the document root, make claims and state transitions atomic, and ensure a restarted worker can distinguish ready, in-flight, deferred and terminal jobs.
05 / Retry safely
A retry must still be useful when it finally runs.
Retry temporary SMTP 4xx responses with exponential backoff and jitter so workers do not synchronize into another spike. Suppress permanent 5xx recipients instead of retrying them into a reputation problem.
Non-negotiable invariant
Expired OTPs must never be sent.
Store the code’s delivery deadline with the job. Check it before every claim and again immediately before SMTP submission. Expiry terminates the job even when retry attempts remain.
Operational principle
Control demand, not only dispatch speed.
A safe transactional-email system combines identity, source, client and primary-domain quotas with authenticated sending, durable state and message-aware expiry. The dequeue interval is the last control in that chain—not the first.
Review your delivery architecture