Product

For a recipient with a PGP key, darkmailer encrypts the message in a before-queue milter — sealed to the recipient's public key before Postfix accepts it. Only ciphertext is ever written to the mail spool, so a crash, reboot, or a compromised queue cannot expose the body. Services that encrypt at send time queue the message first and encrypt on the way out, leaving a brief plaintext window between receipt and forwarding.

We mean recipients who have supplied a PGP key: the message is encrypted during the SMTP transaction, so the on-disk queue holds only ciphertext. Two limits we state plainly — the worker sees the content transiently (it has to, in order to encrypt), and a recipient without a key receives an ordinary forwarded copy unless you turn on require_encryption.

Once the server has answered 250, the message is on persistent, encrypted disk rather than in a memory buffer or a RAM-backed queue, so a crash or reboot cannot lose mail that was already accepted. Delivery then retries with backoff until the destination accepts it.

Content-handling servers run on UpCloud in Finland (primary) and Hetzner in Germany (standby), both EU-owned, and Finland sits outside the Five/Nine/Fourteen Eyes sharing arrangements. AWS is also in the path for delivery and account data: it sees who a message goes to, never what it says — the claim is 'who, not what', not 'nothing'.

We record operations, not correspondence: alias hashes instead of addresses, recipients masked, and never subjects or bodies, with journald retention capped at three days. Hashes are pseudonymous rather than anonymous — not reversible, but stable.

An account is a username and a password — no email address, real name, phone number or payment details. Minimal data in means minimal data to lose.

You upload each recipient's public key; private keys never leave your device. The server keeps only the public key and encrypts one copy per recipient, so a single message can be sealed separately for several people.

By default the Subject travels as plaintext metadata — it is not part of the encrypted body and is visible to every mail system in the path. Hiding or replacing it is on the roadmap, which is why this row reads 'Roadmap' while addy.io offers it today.

darkmailer forwards; it does not host a mailbox, so there is no stored mail to be zero-knowledge about. This row is 'No' because the feature does not exist here, not because mail is stored in a readable form. Forward Email's paid tier does offer it.

There has not been an independent audit yet, so this row says 'Roadmap' instead of implying otherwise. Until one lands, the argument rests on published source, EU jurisdiction, and encrypting content before it reaches the outbound provider for recipients with a key.

Use a domain you own for aliases, so addresses read as your brand rather than a shared relay domain. Designed but not shipped — hence 'Roadmap'.

Accept mail for any address at a domain rather than only aliases you created in advance, so a new address works the moment you hand it out. Planned, not shipped yet.

Without this, an alias protects you when people write to you, but replying would expose your real address. Send-from-alias lets replies leave as the alias too; it is planned, and it is the largest functional gap on this page.

The volume forwarded through your aliases counts against your plan's monthly allowance. It is a fair-use control, so one account cannot quietly become bulk mailing infrastructure.

darkmailer forwards to the inbox you already use instead of hosting a mailbox, so there is nothing to fetch over IMAP or POP3. That is deliberate: no stored mail means no mail store to breach. Forward Email sells mailboxes as its paid tier.

Mail is relayed, not kept, so there is no mailbox of ours to encrypt at rest. Encrypted storage matters when a service holds your mail for you — which is what Forward Email's paid tier does.

What the server replies when mail arrives for a disabled alias. darkmailer answers 550, so the sender learns immediately that the address is closed. The alternatives on this row are worse for senders: accepting with 250 and dropping the message looks like success, and a 421 tempfail makes them retry for days.

A browser extension would create an alias right in the signup field you are looking at, without opening the app. Planned; addy.io ships one today.

Native apps for creating and managing aliases from a phone. Planned — until then the web app works in a mobile browser.

Bitwarden generates a new alias from inside the vault when a service speaks the SimpleLogin API, so compatibility with that API is the integration path. Planned.

1Password ships third-party integrations through its Marketplace, so the route here is a listed darkmailer app rather than a service API like Bitwarden's. Planned, not shipped yet.

A Raycast extension would create and look up aliases from the launcher. Planned, and it would use the same REST API the web app and CLI already speak.

MCP is the standard way to give an AI assistant tools, so an MCP server would let your assistant create and manage aliases on your behalf. Planned; Forward Email already exposes one.