Why was my email delayed?

An email is delayed when GET /emails/{id} reports status delivery_delayed. GET /emails/{id}/explain then returns verdict delay. When the receiving server answered, the sentence quotes it — "Not delivered yet. mx.example.com answered 451 4.7.1 greylisted, try again later. Delivery is retried automatically." — and with no answer it reads "Not delivered yet; delivery is retried automatically." The email.delivery_delayed event from GET /emails/{id}/events carries the evidence for that attempt: reason when the delay is recorded during sending, response when the receiving server reported it.

What to read

GET /emails/{id} is the status. GET /emails/{id}/events is the log, newest facts included. GET /emails/{id}/explain is the one-sentence answer and whether retrying the same send can succeed.

curl -sS -X GET https://api.agentisend.com/emails/9c8f8f0e-3d1a-4d3f-9a1e-2b7c1a0f5e42/explain \
  -H "Authorization: Bearer $AGENTISEND_API_KEY"

200
{
  "actions": [],
  "evidence": {},
  "id": "9c8f8f0e-3d1a-4d3f-9a1e-2b7c1a0f5e42",
  "retryable": false,
  "status": "example",
  "verdict": "example",
  "what_happened": "example"
}

The explain sentence carries the evidence, so a greylisting reply, a full mailbox and a pause on the account read differently. A delay that later ended in a delivery reads as delivered, not delay.

A message held by our own sending-speed limits reads differently again: "Held in our queue by sending-speed limits for Google; nothing is wrong with the recipient.", followed by the time it goes out when that is known. Its retryable is false and its only step is to do nothing: it leaves on its own, and a second send only adds a copy to the same queue.

What happens next

Retries continue on their own. They stop once the next wait would push the sum of the minimum backoffs past 24 hours. That budget is elapsed backoff, not the time since POST /emails accepted the message. When it is spent, the status becomes failed and the event is email.failed. A message that could not be delivered in the whole time it may wait in our queue fails the same way; GET /emails/{id}/explain says so, sets retryable to true, and a new send needs a new Idempotency-Key.

Nothing on this page is an inbox-placement rate. GET /emails/{id} is the status of this message.

Next

• Why did my email bounce?
• Email for AI agents
• Event catalogue lists email.delivery_delayed and email.failed.