01
Real MX, not a forwarder.
Inbound mail terminates on our mailserver and sits in your IMAP store. No third-party SMTP between the sender and the inbox — nothing to expire, no “catch-all” that silently drops on plan changes.
Mailbox · Sovereign mail
Real mail on infrastructure you administer.
Mailbox is what we run when we want full mail hosting — inbound MX, outbound SMTP, IMAP store, webmail, DKIM keys — on a box we own, with a small FastAPI control plane in front. Most “sovereign mail” products are forwarding aliases. This one isn’t.
Programmable mailbox provisioning. BIMI-ready DMARC posture. No third-party SMTP between your domain and the recipient.
Surface signal
Status
LIVE
Transport
Owned MX
Control plane
mail-api.eleven11.pro
Why this exists
Most “sovereign mail” is a forwarding alias.
When a vendor sells you “your own domain email,” what you usually buy is an alias that re-mails through their pool, an inbox you read on their tenant, and a deliverability reputation you share with every other tenant on the same IP. The minute the platform decides your traffic looks suspicious — or a neighbour sends a spam wave — your mail starts hitting Gmail’s spam folder and you have no recourse.
Mailbox is the opposite shape. Real MX. Real IMAP and SMTP. Real DKIM keys we own. The control plane is a small FastAPI service called mail-platform-api; the mail itself runs on docker-mailserver, on a box we administer, on an IP whose reputation belongs to one customer at a time.
Self-sustained by design
Owned, not rented.
Mail is the most load-bearing identity a company has. It should not be a tenant row in a SaaS spreadsheet, a forwarding alias on someone else’s pool, or a deliverability score determined by a stranger’s spam wave.
02
Outbound goes through your own SMTP.
Internal e11 services send via docker exec mailserver sendmail -t -i over the mounted socket. Port 25 is inbound-only. There is no relay through SendGrid, Postmark, or a hyperscaler’s shared sender pool — the From: address and the connecting IP belong to the same operator.
03
DKIM, SPF, DMARC — yours.
DKIM keys are generated on the server and rotated through the mail-platform-api control plane. DMARC posture is published at p=reject when you’re ready, which is the precondition Gmail needs before it will render your BIMI logo next to the sender name.
04
BIMI-ready.
An SVG Tiny PS logo at /logo.svg, a DMARC record at p=reject, and a BIMI TXT record — that’s the whole pipeline. We ship the logo asset and the DNS shape; the brand indicator falls into place the moment your DMARC clears the threshold.
05
Single source of truth.
Mailboxes live in docker-mailserver. The API mirrors metadata and issues setup commands; it doesn’t shadow the underlying account state. When you SSH in and run setup email list, what you see is what the control plane sees — not a stale Postgres mirror.
The primitive
Three records you can name. Typed.
Mailbox is built on a small, opinionated trio — a mailbox to receive, an identity to authenticate it, and an outbound channel that doesn’t cross a third-party trust boundary. Everything else is a control-plane call against one of those three.
01 · Mailbox
Mailbox
POST /mailboxes
A real account on the mailserver, with its own IMAP/SMTP credentials and quota. Provisioned through the API, materialised by setup email add inside the mailserver container. Not an alias, not a forwarding rule.
02 · Identity
Identity
DKIM · SPF · DMARC · BIMI
The cryptographic and DNS posture that makes a sender legitimate — DKIM key, SPF include, DMARC policy, BIMI logo. Each piece is a record we publish and a key we own; deliverability is a property of the identity, not a service tier.
03 · Channel
Outbound channel
docker exec sendmail
How the rest of the fleet sends mail. Internal services don’t SMTP-AUTH against an external relay — they exec sendmail over the mounted socket. Port 25 inbound, sendmail outbound. One transport, one trust boundary, no shared-pool surprises.
How it fits the fleet
The transport every other tool uses.
Mailbox is rarely the surface a customer thinks they’re buying — but it’s the From: line behind every other Eleven11 product. Outreach prospecting, alert delivery, consultation replies, operator credential rotation: same MX, same DKIM, same trust boundary.
outreach
Real outbound prospect mail goes through this stack. SMTP_USER and SMTP_FROM are [email protected] — a personal-looking sender, not an audit@ alias — because the connecting IP and the From: domain align under our DKIM.
alerts
alerts-api routes events of kind=email through the [email protected] mailbox. Channel passwords rotate via the operator /secrets UI; the mailbox itself is provisioned the same way as any customer mailbox.
consultation form
The eleven11.pro consultation form delivers via CONSULTATION_SMTP_HOST against this mailserver. [email protected] is a real account, not a forwarder — inbound replies land in IMAP, not in someone else’s ticket queue.
operator
Operator manages mail credentials through the same /secrets registry as the rest of the fleet. Rotating an SMTP password for outreach or alerts is one row update plus a setup email update inside the mailserver — audited, reversible, single-pane.
architect
Architect’s tenant-owner email is an env-driven identity that resolves to a mailbox in this stack. When a workspace ceremony promotes a draft, the audit trail and the From: line come from the same domain you administer.
mail-admin
/mail-admin in e11-web is the JWT-authenticated control surface for provisioning. It calls mail-platform-api directly from the browser; the human-auth migration moves this onto its own subdomain in Phase 5.
Surfaces & contracts
Six things you actually call.
Two routes a person opens, two control-plane calls a service makes, two health and provisioning endpoints. The smallest surface that does the job.
mail-api.eleven11.pro
Public control plane
The FastAPI service that creates mailboxes, rotates passwords, and surfaces health. /health is open; everything mutating sits behind a JWT.
/mail-admin
Admin UI
JWT-authenticated mailbox management on e11-web. Calls mail-platform-api from the browser via NEXT_PUBLIC_MAIL_API_URL. Migrating to its own subdomain under the human-auth Phase 5 cutover.
/mailbox
End-user surface
The mailbox workspace on e11-web for account holders — connection settings, webmail launch, account help. Reads only public mailserver hostnames; never touches the control plane.
/webmail
Webmail
Browser client for reading and sending against your mailbox. The same IMAP/SMTP credentials work in Apple Mail, Outlook, or Thunderbird — no proprietary protocol, no client lock-in.
POST /mailboxes
Provisioning API
Programmatic mailbox creation. Idempotent against the mailserver’s own state; the API is a thin coordinator over setup email add, not a parallel store.
GET /health
Health
Liveness for the control plane. Pairs with mailserver’s own status checks — the API tells you it can talk to docker-mailserver, the mailserver tells you DKIM keys and queues are sane.
Senior engineering, visible
The proofs are in the substrate.
Five decisions visible in the compose file, the DNS records, the identity catalogue, and the migration plan — not adjectives, design choices.
Single source of truth.
docker-mailserver owns mailbox state. The API mirrors metadata and issues setup commands; it never shadows account data. No “the DB says active, the server says deleted” divergence.
Inbound-only port 25.
Port 25 listens for incoming mail and refuses to relay. Outbound is exclusively docker exec mailserver sendmail — one transport, one auth boundary, no accidental open relay if a credential leaks.
Identity catalogued, not scattered.
Every email address used across architect, cal, operator, outreach, and alerts is enumerated in EMAIL-IDENTITIES.md with file : line references. Env-driven where it matters; hardcoded never. Re-grep is one shell line.
Phase-gated migration.
The mail-admin UI is being moved onto its own subdomain behind CF Access plus origin sessions, as part of the wider human-auth migration. Phase 3 (additive schema) and Phase 4 (recover-api) ship before Phase 5 flips the cutover — nothing visible breaks for callers in the meantime.
Reputation is a per-tenant asset.
On the partner-deployed shape, the connecting IP is yours — not shared with a thousand other tenants of an SMTP service. Your DKIM signature, your DMARC alignment, your sender reputation. Deliverability stops being a roulette wheel.
Who this is for
Teams whose From: line is load-bearing.
Mailbox earns its keep when the cost of a deliverability incident, a vendor pricing turn, or a shared-pool reputation hit starts to exceed the cost of administering an MX.
Founders who already lost mail to a vendor pricing change and want their own MX before the next one.
Teams whose outbound mail is sales-load-bearing — one botched warmup at a shared SMTP and a quarter slips.
Operators publishing under a brand who want BIMI rendering next to their name once DMARC clears p=reject.
Organisations whose compliance posture cannot accept a third-party SMTP holding the From: line for their domain.
Consultancies running multiple client domains who want one programmable control plane provisioning real mailboxes per tenant.
FAQ
Final friction, reduced.
Is this just Postfix in a box?
Postfix is part of it — docker-mailserver bundles Postfix, Dovecot, Rspamd, Fail2ban, and the DKIM tooling. What we add on top is a small FastAPI control plane (mail-platform-api), the per-fleet identity catalogue, and the operator-side rotator. The mail engine is boring on purpose; the integration shape is where the work lives.
What about deliverability to Gmail?
DKIM, SPF, and DMARC are configured per domain. DMARC moves to p=reject on a deliberate timeline — monitor first, quarantine, then reject — and BIMI rendering follows once Gmail sees the policy stick. Reputation lives on your IP, not in someone else’s shared pool.
How does this relate to /mailbox and /mail-admin on the site?
/mailbox is the end-user workspace — connection settings, webmail launch, account help. /mail-admin is the JWT-authenticated control UI for provisioning. Both surfaces sit on e11-web; the API they call (mail-platform-api at mail-api.eleven11.pro) is the product described on this page. The admin UI is being migrated to a stronger auth path under HUMAN-AUTH Phase 5.
Can we run this in our own infrastructure?
Yes — the control plane plus docker-mailserver are deployed on a box you administer, on an IP whose reputation belongs to you, with DKIM keys you hold. Bundled with the per-tenant box pattern Architect uses, or standalone. Talk to us about migration scope, DNS handover, and the warmup timeline.
Discuss Mailbox
Bring your domain home.
Mailbox is partner-deployed today — bundled with the per-tenant box pattern, or standalone for a single domain. Talk to us about migration scope, DNS handover, the DMARC and BIMI timeline, and what real outbound deliverability looks like on an IP that is yours.
Direct line
Consultation requests stay owned. We reply from e11 after reviewing fit and timing.