Zero-retention transactional email

Blindrelay never stores email body, subject, headers, or plaintext recipient addresses, except while a deferred delivery waits to retry (up to 24h). Turn retries off and they never touch disk. For DPOs and security reviewers, the guarantee is enforced by system design — not a retention policy you negotiate in a DPA.

What "zero retention" means in practice

Message content exists in process RAM from API accept until the signed MIME payload is handed to SMTP, then the structured body is discarded. A short-lived send buffer may remain until the SMTP status code is read. A message the recipient's server defers waits on the mail host's disk for up to 24 hours unless you turn retries off. After delivery, only coordination metadata survives briefly — and the recipient address is stored only as one-way hashes, never as plaintext.

There is no message log table, no search index, no preview pane, and no resend feature. If content were retained, those surfaces would exist. They do not, by design.

What persists after send

How the architecture enforces it

• Narrow data model — The in-flight record holds id, from, recipient hash, domain, status, and timestamp. No body column exists in the schema.
• Queue contract — The envelope queue accepts coordination metadata only, so message content cannot be persisted by construction.
• Automated verification — Every release runs a no-content-on-disk integration test. A failing check is a release blocker.

For your security questionnaire

Message content is not retained on Blindrelay infrastructure. Delivery observability is exported to the customer's OTLP collector or webhooks. The in-app dashboard shows aggregate counters only — not a message log.

Ready to send? See pricing, the API reference, or compare Resend vs Blindrelay.