Inboxes are the center
of the product.
Create, list, filter, and inspect inboxes by team, status, address, agent principal, domain, and health. Each inbox carries a canonical address, aliases, a display identity, signing & DNS status, and a lifecycle state.
Inspect and operate inbox contents.
Inbox, threads, sent, drafts, archived, and delivery views. Read in the format you need — agent-extracted by default, or plain, HTML, and raw where authorized.
Read formats
Agent-readable extraction is the default. Request plain, HTML, or raw RFC 5322 where authorized. Reading content marks the message read — listing metadata does not.
Reply semantics
reply and reply_all are separate operations with normal recipient rules. To and Cc in v1; no auto-quoted body. Bcc is deferred.
Drafts that respect policy
Create, update, and discard drafts separately from the inbox. A policy-blocked send leaves the draft unsent — never a fake sent or blocked message.
Attachments, gated
Metadata is preserved; bytes require an explicit retrieval action behind a safety review. Spam attachments inherit spam provenance and warnings.
Labels & state
System labels power inbox, sent, spam, and archived state. Custom labels drive your workflow. Read-state is a first-class API — not an audit signal.
Delivery status
Track accepted, spam, rejected, and platform-blocked outcomes per message and thread, with links to the underlying decision events.
Managed by default.
Custom when you need it.
Customers shouldn't touch DNS for normal inbox creation. Postillion runs an authoritative serving layer and projects records from control-plane state — MX, DKIM selector TXT, SPF/DMARC, return-path, and verification.
Generated address per inbox with enough entropy to never recur. Inventory-checked on create.
Reassignable within workspace/domain rules. Reassignment affects future mail only — existing threads stay put.
Delegated mail subdomains preferred. Address creation is separate from domain verification.
Product-shaped controls.
ReBAC underneath, never exposed.
Five control families cover the surface — and you never see a raw OpenFGA tuple, model ID, or relationship name like sender_trust.
Access grants
What principals and credentials are allowed to do, scoped to workspace, team, inbox, or address.
Communication
Receive and send allow/block by address, domain, inbox, or workspace. Exact-domain matching — no implicit subdomain trust.
Sender identity
Which verified identities an inbox may send as. Routing an alias in does not grant send-as authority.
Directory visibility
Who can discover and contact what. Cross-workspace agent discovery is intentionally unsupported in v1.
Provisioning
Who can create and configure resources, and delegate that authority down a scope.
Explain & simulate
No broad effective-policy viewer in v1. Ask concrete "why allowed / denied?" questions and get safe, structured answers.
$ postillion explain delivery msg_7f3a ✓ allowed scope: inbox ibx_a1f9 (Triage Agent) sender dana@brightwave.io — DMARC aligned matched: communication.receive.allow · domain brightwave.io decision: accept → inbox · etag v18 · audited
Spam is a deliberate,
warning-heavy surface.
Postillion uses spam — not quarantine — for v1. Unknown authenticated external senders land here by default unless Open Inbound Policy allows them through. It never blends into the normal inbox or search results.
Browseable by scope and resource.
Append-only records for lifecycle, policy, delivery, relationship, auth, DNS, and content-access events. Streams and webhooks are ReBAC-filtered — only authorized events ever leave the building.