KeyKeeperKNOW WHAT HAPPENED AFTER SEND
Follow the delivery.
See whether your message is queued, waiting for a retry, accepted by the next mail server, or bounced. Each recipient has its own result.
One send. A status you can follow.
The send response means KeyKeeper accepted your submission. Use its id to fetch GET /api/v1/agent/outbound/ID with your Bearer API key. The response includes each recipient and recent delivery events. List submissions through GET /api/v1/agent/outbound; use before=nextCursor for older pages. In the human inbox, open Sent to see the same delivery results.
| Status | Meaning |
|---|---|
| queued | The message is waiting for delivery evidence. |
| deferred | A temporary failure occurred. The mail server retries automatically. |
| delivered | The next mail server accepted the message, or KeyKeeper completed local delivery. |
| bounced | The mail server reported a permanent failure. |
| rejected | This recipient was rejected before queue acceptance; no accepted-send credit is used. |
| mixed | Recipients have different outcomes; inspect each result. |
| untracked | Recipient tracking is unavailable for this submission, including older mail. |
Acceptance does not prove inbox placement, delivery beyond a forwarding server, or that someone read your mail. Submission status remains separate: an uncertain SMTP response is never a reason to send again with a new idempotency key.
Let delivery changes reach your agent.
Existing callbacks keep their incoming-mail subscription. Opt an active callback into outgoing events with:
{"events":["message.received","message.delivery_updated"]}New callbacks can include the same events array when registering. Verification starts observation without historical backfill. Outgoing-only callbacks can subscribe to message.delivery_updated.
{
"id":"<event-id>",
"type":"message.delivery_updated",
"createdAt":"<observation-time>",
"data": {
"messageId":"<send-response-id>",
"recipientId":"<recipient-id>",
"status":"bounced",
"dsn":"5.1.1",
"category":"invalid_recipient",
"transport":"smtp"
}
}Notifications contain references and status codes. Recipient addresses, subject, body, attachments and raw server responses stay out of callbacks. Fetch the authenticated message status when you need the recipient address. Verify signatures and deduplicate event IDs using the webhook protocol. Events can repeat or arrive out of order; fetch current status before making a decision.
Stop repeating invalid-address sends.
A direct 5.1.1 invalid-address bounce blocks future sends to that address for your account, through both the API and SMTP. Authentication or policy failures, temporary failures, and invalid forwarding destinations do not create that block.
Inspect GET /api/v1/agent/outbound/suppressions. After confirming an address can receive again, DELETE /api/v1/agent/outbound/suppressions/ID releases it for future messages. Nothing is automatically resent. An accepted send that later bounces still uses its sending credit; rejection before queue acceptance follows the existing refund rules.
What is observed and retained.
Tracking uses trusted Postfix delivery logs, checked about every 15 seconds, for authenticated API and SMTP submissions made after tracking was enabled. Postfix owns the queue and temporary-failure retries, normally for up to five days. An ordinary incoming bounce email is not automatically trusted or allowed to block recipients; authenticated processing of later remote delivery reports is future work.
Recipient addresses are encrypted in the tracking database. Delivery metadata is retained for 90 days and webhook history for 30 days. Active invalid-address blocks persist until released. This is service-managed encryption, not end-to-end encryption. No tracking pixels or read receipts are added.