/queue-management

name: "Mimecast Queue Management"
description: >
  Mimecast email delivery queues: inbound and outbound queue types, queue
  message states, retry behavior, and the signals that identify stuck
  messages, delivery delays, and backlog conditions.
when_to_use: >-
  When checking Mimecast delivery queue health or diagnosing delayed or stuck mail. Use when:
  mimecast queue, email queue, delivery queue, mimecast backlog, mimecast delivery delay, stuck
  email, mimecast outbound queue, or mimecast inbound queue.

Mimecast Queue Management

Overview

The Mimecast delivery queue holds messages that are in transit — inbound messages being scanned and processed, outbound messages awaiting delivery to recipient servers. Queue monitoring is essential for detecting delivery backlogs, identifying stuck messages due to recipient server issues, and understanding the state of mail flow during incidents (e.g. a downstream mail server outage). A healthy queue processes messages within seconds; messages sitting in the queue for minutes or longer indicate a potential problem.

Anti-triggers

• **Releasing or deleting a held message** — this skill reports queue

contents and cannot change a message's disposition; use `Mimecast Message Tracking`.

• **Finding one specific email** — the queue shows current in-transit

state only. Anything already delivered, bounced, or rejected has left it; search with `Mimecast Message Tracking`.

• **Why a message was blocked** — queueing is a delivery outcome, not a

security verdict. For the threat reasoning use `Mimecast Threat Intelligence`.

Key Concepts

Queue Types

| Queue | Description | |-------|-------------| | **Inbound** | Messages received from external senders, being scanned before delivery to internal mailboxes | | **Outbound** | Messages from internal users being delivered to external recipients | | **Hold Queue** | Messages explicitly held by policy or administrator action (see message-tracking skill) |

Queue Message States

| State | Meaning | |-------|---------| | `queued` | Waiting to be processed | | `retrying` | Delivery failed, scheduled for retry | | `deferred` | Recipient server temporarily unavailable; Mimecast will retry | | `held` | Manually held or policy-blocked |

Retry Behavior

When Mimecast cannot deliver a message (e.g. the recipient mail server is down), it enters the message into a retry schedule:

• First retry: ~5 minutes
• Subsequent retries: exponential backoff, up to 4 days
• After 4 days without successful delivery: bounce notification sent to sender

API Patterns

Get Delivery Queue Status

mimecast_get_queue_status

**This tool takes no arguments.** Its input schema is empty — there is no `direction` filter, no `status` filter, and no paging. Every call returns the same whole-gateway snapshot, and any narrowing happens in your own code after the fact.

**Example response:**

{
  "inbound": {
    "count": 12,
    "oldest": "2026-03-02T09:00:00Z",
    "details": [
      {
        "id": "eNqrVkpJLU...",
        "created": "2026-03-02T09:00:00Z",
        "status": "queued",
        "from": "vendor@external.com",
        "to": ["user@client.com"],
        "subject": "Purchase Order #4892",
        "reason": ""
      }
    ]
  },
  "outbound": {
    "count": 3,
    "oldest": "2026-03-02T08:30:00Z",
    "details": [
      {
        "id": "eNqrVkpABC...",
        "created": "2026-03-02T08:30:00Z",
        "status": "deferred",
        "from": "user@client.com",
        "to": ["recipient@destination.com"],
        "subject": "Report Q1 2026",
        "reason": "550 5.1.1 The email account does not exist"
      }
    ]
  }
}

Key fields:

• `inbound` / `outbound` — the two queue directions, each an object. Either

may be absent; treat a missing key as "no data returned", not as zero.

• `count` — messages currently in that direction's queue
• `oldest` — an **ISO 8601 timestamp**, not an age in seconds. Compute the

age yourself as `now − oldest` before comparing against a threshold.

• `details[]` — per-message entries. **Every field is optional and the

array itself may be absent even when `count` is non-zero.** An agent that iterates `details` without checking `count` will report a clean queue on a backlogged gateway.

• `reason` — free text explaining the current state. It often carries the

SMTP response, but it is not guaranteed to, and it is not a parsed error code.

What this tool does not give you

The queue snapshot has no per-message retry accounting: there is no `retryCount` and no `nextRetry`. You cannot tell how many delivery attempts a message has had or when the next one is due, so any rule of the form "escalate after N retries" is not implementable against this tool. Use age (`created`) and `reason` instead.

To work with a *subset* of messages — deferred only, held only, one sender, one recipient — use `mimecast_find_message`, which does take filters, including `status` with `queued`, `deferred`, `held`, `bounced`, `failed`, `delivered`, `accepted`, `blocked`, and `processing`. The queue tool is a gauge; message tracking is the query interface.

Common Workflows

Daily Queue Health Check

1. Call `mimecast_get_queue_status` — it takes no arguments and returns both directions at once 2. For each of `inbound` and `outbound`, derive the age of the backlog from `oldest` (`now − oldest`), then compare:

• Under 60 seconds: healthy
• 60–300 seconds: minor delay, monitor
• Over 300 seconds: investigate

3. Read `count` per direction. A rising outbound `count` with an ageing `oldest` is the backlog signal 4. Scan `details[].status` for `deferred` entries and read their `reason`. If `count` is non-zero but `details` is empty or missing, say so — do not report the queue as clean

Investigate a Stuck Message

1. Call `mimecast_find_message` with `status: "deferred"` — the queue tool cannot filter, and message tracking is the