What shipped, and when.

The API has always been the foundation. It now has two siblings.

The CLI puts everything you could do by clicking into a shell script, a runbook, or a CI job: outsend trace prints a message’s full lifecycle with the provider’s own response on every event, outsend events tail follows the log live, and outsend doctor checks the things that actually break sending — DNS propagation, duplicated SPF records, key scope, reputation state, webhook health. Every command takes --json.

The MCP server gives agents the same surface, with one rule enforced throughout: every tool returns the evidence behind its answer, and the uncertainty it could not resolve. Reading and diagnosing are unbounded. Changing things is not — propose_remediation produces a plan a human reads, and apply_remediation needs that human to approve it, with the approval recorded against the plan id.

outsend explain and explain_failures are the same code: give them a set of failures and they return provider concentration, the likely signal, the evidence supporting it, and what they could not determine.

Docs: CLI · MCP server

Most deliverability problems are list problems wearing a disguise. Five detectors now run over your contacts and explain, in plain language, why each flagged address is a risk:

• No MX record — the domain has no MX records in DNS, or does not exist. Mail will hard bounce.
• Dormant — received email in the last 90 days but never clicked any of it.
• Role addresses — info@, admin@, noreply@. Shared inboxes with no individual reader.
• Disposable / typo — throwaway mailboxes and common typo domains like gmial.com.
• Duplicates — the same person across multiple rows, after Gmail dot and plus normalisation.

Each detector shows its candidates with a one-sentence explanation, and you can bulk unsubscribe or delete straight from the results. Finding the problem and fixing it should not be two different products.

Webhooks were already signed with a per-endpoint HMAC secret. Now every delivery attempt is recorded too: attempt count, response code, and response body.

This closes an awkward gap. We were asking you to trust our event pipeline while giving you no way to see whether the last hop actually worked. If your endpoint returned a 500 at 3am, that is now a row you can look at rather than a silence you have to infer.

Endpoints that keep failing move from active to paused, and repeated failure disables them — with the failure count visible, so you can see how you got there rather than discovering it as a surprise.

POST /api/v1/emails now accepts an Idempotency-Key header. The response for a given key is cached for 24 hours, so retrying with the same key returns the original result instead of sending a second message.

This removes a whole class of bug. A request that times out at the network layer has an genuinely unknown outcome — the message may have sent, or may not have. Without idempotency your only options are to retry and risk duplicates, or not retry and risk silence. Neither is good, and password resets are exactly where both are worst.

Your retry logic can now be as aggressive as your network is unreliable.