When emails cannot be dispatched immediately — due to daily or hourly limit enforcement, recipient server deferral, or retry scheduling — they are placed in the MigoSMTP sending queue. Understanding how the queue works, how to monitor it, and how to manage stuck messages is essential for maintaining smooth, reliable email delivery.
What the Queue Is
The MigoSMTP queue is a managed buffer that temporarily holds messages before they are dispatched. Messages enter the queue for several reasons:
| Reason for Queuing | Trigger | Expected Resolution |
|---|---|---|
| Hourly limit reached | More emails submitted than the hourly limit allows | Dispatched when hourly limit resets at top of next hour |
| Daily limit reached | Daily dispatch cap hit before midnight | Dispatched from midnight when daily limit resets |
| Scheduled send | send_at parameter set to a future timestamp |
Dispatched at the specified time |
| Soft bounce / deferral | Recipient server temporarily refused the message (server busy, rate limit) | Retried automatically on MigoSMTP's retry schedule |
| Transient server error | Intermittent upstream error during delivery attempt | Retried automatically |
How to View the Current Queue
Via the Dashboard
- Log in to MigoSMTP.
- The In Queue card on the main dashboard shows the current count of messages pending delivery.
- Go to Reports → Delivery Reports and filter by Status = Queued or Deferred to see the individual queued messages.
Via the API
GET https://api.migosmtp.com/v1/reports/messages?status=queued Authorization: Bearer YOUR_API_KEY // Returns paginated list of queued messages with message_id, // recipient, queued_at, expected_send_at, and queue_reason
Queue Status Meanings
| Status | Meaning | Action Required |
|---|---|---|
| Queued | Message accepted; waiting for capacity (hourly/daily limit) | None — will dispatch automatically when limit resets |
| Scheduled | Message set for a future send_at time | None — will dispatch at specified time; cancel if needed |
| Deferred | Attempted delivery; recipient server temporarily rejected — will retry | None — auto-retried; investigate if persistent (>24 hours) |
| Delivered | Successfully delivered to recipient server | None |
| Bounced | Permanently rejected — invalid address or domain | Remove from your list; address auto-added to suppression |
Understanding Deferred Messages
A deferred message is one that MigoSMTP attempted to deliver but the recipient's mail server responded with a temporary rejection (a 4xx SMTP response code). Common causes of deferral:
- Recipient server busy — too many simultaneous connections; try again later.
- Rate limiting by the ISP — Gmail and Outlook throttle receiving from senders with high volume to protect their users.
- Greylisting — some servers temporarily reject first-time messages from unknown senders, then accept on retry.
- Server maintenance — recipient mail server is temporarily down.
MigoSMTP retries deferred messages automatically using an exponential backoff schedule:
| Attempt | Delay After Previous | Cumulative Time |
|---|---|---|
| 1 (initial) | Immediate | T + 0 |
| 2 | 5 minutes | T + 5 min |
| 3 | 30 minutes | T + 35 min |
| 4 | 2 hours | T + 2h 35m |
| 5 | 6 hours | T + 8h 35m |
| 6+ | 12 hours between attempts | Up to 72 hours total |
| Final | After 72 hours total | Marked as permanently failed; not retried further |
How to Cancel a Queued or Scheduled Message
// Cancel a single queued or scheduled message
DELETE https://api.migosmtp.com/v1/email/{message_id}
Authorization: Bearer YOUR_API_KEY
// Cancel all scheduled messages in a batch
DELETE https://api.migosmtp.com/v1/email/scheduled/{batch_id}
Authorization: Bearer YOUR_API_KEY
Cancellation window: A queued message can be cancelled while it is in Queued or Scheduled status. Once dispatch begins (the message moves to Sending status), cancellation is no longer possible.
Best Practices for Queue Health
- Monitor queue size during bulk sends — a rapidly growing queue may indicate you are sending faster than your limits allow. Slow down your submission rate to match capacity.
- Set up a queue size alert — in Dashboard → My Alerts, set an alert if the queue exceeds a threshold (e.g. 500 messages) to catch unexpected build-ups.
- Use the In Queue metric as a health indicator — a consistently large queue suggests your plan limits are too low for your volume, or a deferral issue is causing messages to pile up.
- Do not flood the queue — submitting thousands of messages simultaneously does not speed up delivery; they all go through the same limits. Use batch submission with controlled timing.