Security

Your message content is not stored on Blindrelay. This is enforced by system design — not a retention policy you have to trust.

What we guarantee

• No content retention — Never stored, except while a deferred delivery waits to retry (up to 24h). Turn retries off and it never touches disk.
• Retries you control — Mail that cannot be delivered immediately waits on disk for up to 24 hours, then is deleted. Turn retries off and a temporary failure is final.
• No message store, no operator access — No email log, search index, preview, or resend feature — so Blindrelay staff have no sent mail to browse.
• Control-plane audit, not a message log — Account, domain, and API key changes are kept for 90 days. Individual sends are traced in your OTLP stack, not here.
• Observability stays in your stack — OTLP export or webhooks (relay_accepted, delivered, soft_bounce, hard_bounce, failed, complaint). The in-app dashboard shows hourly counters only.
• CLI and Agent Plugin use the same scoped keys — Grant each tool only the scopes it needs. Error output is scrubbed of recipient addresses before it reaches logs or model context.

What we process (and what we do not retain)

How the architecture enforces this

• Narrow data model — The in-flight record holds coordination metadata only: id, from, recipient hash, domain, status, and timestamp. It is deleted on terminal delivery. No body column exists in the schema.
• Content cannot enter the durable queue — The queue interface accepts coordination metadata only, so message content cannot be persisted by construction — not by policy.
• RAM-only body path — Message content lives in memory from accept until the worker builds the signed MIME payload, then the body is released. A send buffer may remain until the SMTP response arrives. On terminal delivery the in-flight record is deleted and only integer counters (and a minimal hashed bounce-correlation mapping for async DSN) remain.
• Automated verification — Every release runs an automated no-content-on-disk check that asserts persistent storage has no message-content columns and that a full send leaves no body or plaintext recipient address in the database. A failing check is a release blocker.

Relay vs. control plane

• What Blindrelay does — Accept a send, DKIM-sign, attempt SMTP delivery once, emit OTLP events and webhooks (relay_accepted, delivered, soft_bounce, hard_bounce, failed, complaint), and discard message content.
• What you do — Configure your OTLP collector or webhook on the Delivery page, build dashboards and alerts next to application metrics, and decide when to resend after a soft bounce or quota event.
• What we do not do — Store messages for search, offer a vendor message log, or run automated retry with retained content.

What we do not claim

We process your message in transit. To relay email, our servers must receive, DKIM-sign, and transmit your message once. Content is visible to the sending process only for that delivery.

Retries mean the message waits on disk. If the recipient's server cannot take a message right away, it waits on our mail host's disk, with its recipient address, for up to 24 hours and is deleted once delivered or expired. You can turn retries off for the workspace: the message stays in memory and a temporary failure ends as a soft bounce. You can then issue a new POST /v1/send when your OTLP pipeline or webhook handler says to. Every send accepts an Idempotency-Key header (24-hour TTL), so safe HTTP retries after a worker crash or network blip do not produce duplicate emails.

We cannot cryptographically prove we never looked. No SaaS email provider can offer absolute never-observed guarantees without client-side encryption. Our guarantee is no retention: there is nothing to exfiltrate, subpoena, or breach after delivery.

TLS protects data in flight, not from us. API connections use TLS 1.2+. That protects against network interception, not against the relay during processing.

We retain minimal metadata — only what the relay needs to operate. In-flight records (id, from, recipient hash, domain, status) exist only while a send is in flight. Terminal outcomes increment integer delivery counters and the record is deleted; a minimal bounce-correlation mapping (hash + domain, no content) may remain for async DSN/FBL for up to 72 hours. Suppression hashes (hash + reason only) block repeat sends to hard-bounced or complained addresses, protecting your domain reputation. Neither stores message content or plaintext recipient addresses.

Compliance

One-line answer 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. Retry and alerting policy remain with the customer application.

Security or Enterprise questions: info@blindrelay.app