Sealed sender. Zero metadata.

Email reimagined for a world
that stopped trusting email.

AfterMail encrypts every message end-to-end, hides the sender from the relay using sealed sender architecture, and delivers through a protocol that has never heard your name. Familiar interface. Zero trace.

Join the Waitlist How It Works
0 User identifiers stored
0 Sender identity exposed to relay
2 Independent protocol layers
Metadata ceiling. None.

The architecture was
the promise.
Until it wasn't.

End-to-end encryption was supposed to be enough. It isn't. The message content is protected. Everything else (who sent it, when, from where, to whom, how often) is logged, analyzed, and in many jurisdictions, legally compelled.

The encryption got stronger. The gap didn't close.

  • ERR
    Metadata is the surveillance surface Your provider knows every person you communicate with, every timestamp, every device, every location. That record exists even when the message doesn't.
  • ERR
    Compliance means cooperation Encrypted providers comply with lawful requests and log exactly what's needed to respond. Proton disclosed 3,572 accounts in 2024. The encryption held. The institution didn't.
  • ERR
    The interface lies about the architecture Email looks like a private conversation. It behaves like a permanent, addressable, server-side record. The familiarity obscures the exposure.
  • ERR
    Privacy tools require abandoning email entirely Signal, SimpleX, Briar solve the problem but demand a new paradigm from the recipient. Friction is where security dies at adoption.

Two layers.
One surface.

AfterMail is not a privacy feature bolted onto an email client. It is a layered architecture: identifierless messaging with sealed sender, and a familiar interface, designed from the protocol layer up. Each layer independently defeats a class of surveillance. The relay never knows who is sending. The protocol never records who you are.

01 / PROTOCOL
Sealed Sender + SimpleX

Identifierless delivery

The sender wraps the message in an inner encrypted envelope before transmission. The relay receives only a recipient identifier, ciphertext, and nonce — it never sees who is sending. On receipt, the recipient's client authenticates the sender locally using shared keys. No auth header is transmitted. The relay cannot log or correlate sender identity even from HTTP metadata.

Sealed sender: relay has zero knowledge of message origin
X25519 key exchange, ChaCha20-Poly1305 encryption
No accounts, no phone numbers, no usernames
QR code-only connection pairing — one time, no reuse
Messages deleted from relay immediately on delivery
02 / MESSAGING
SimpleX Protocol

No identifiers. Ever.

SimpleX has no user IDs, no phone numbers, no email addresses. Connections are established via one-time QR codes. Messages are delivered through single-direction queues with no persistent global identifier linking conversations to a person. The relay sees a recipient queue. Nothing else. Combined with sealed sender, the relay knows neither who sent nor who receives in any meaningful sense.

No persistent user identifiers of any kind
One-time QR code connection — context disappears after pairing
Single-direction per-connection queues
End-to-end encryption on every queue
03 / PRODUCT
AfterMail Interface

Familiar by design

An email-familiar interface over the sealed sender and SimpleX stack. Compose, send, receive. Inbox, sent, archived. The cognitive model you already have — without the surveillance architecture beneath it. Built in Rust. At-rest encryption via passphrase-derived keys with biometric surface and remote wipe.

Email-familiar UX with zero legacy architecture
Passphrase-derived at-rest encryption, never transmitted
Biometric surface: Face ID / Touch ID
No server-side content storage
Free
$0
No credit card. No trial period.

Full access to the AfterMail architecture. The security model does not degrade by tier. Every user gets sealed sender and identifierless delivery.

  • Sealed sender — relay never knows who sent
  • SimpleX identifierless delivery
  • Passphrase-derived at-rest encryption
  • Message storage limits apply
  • Single device
Join Waitlist
Sovereign
Contract
Private deployment. Air-gap capable.

Private deployment for defense, government, and organizations where the infrastructure itself must be owned. FedRAMP-aligned. No shared infrastructure.

  • Private infrastructure deployment
  • Air-gap capable configuration
  • DoD / FedRAMP-aligned architecture
  • Admin Active/Inactive control only. No message access.
  • Custom SLA and dedicated support
Contact Us

Be among the first to communicate without a record.

AfterMail is in development. Join the waitlist to be notified at launch, receive early access, and help shape the product.

Your email is used once: to notify you. Then discarded.

The architecture is built.
The team isn't.

AfterMail is looking for a technical co-founder with a background in distributed systems, cryptography, or defense/FedRAMP. The stack is defined. The thesis is published. What's needed is someone who has solved hard infrastructure problems at scale and wants to build something that matters.

hello@aftermail.co →

Read the thesis: "The Architecture Held. The Promise Didn't."
Published May 5, 2026. reports.vordan.co

"The promise of private communication has always lived one layer above where the actual exposure occurs."
AfterMail was built on a specific observation: privacy tools kept improving their encryption while the surveillance surface, the metadata layer, went unaddressed. We built the architecture to address it.

Built by Vordan.
Grounded in the reporting.

Vordan is a practitioner-focused governance and accountability publication. Since April 2026, it has tracked the accountability gap across cybersecurity, AI governance, post-quantum cryptography, and digital sovereignty, written for the people building and defending systems.

AfterMail is Vordan's first product. It emerged directly from the reporting: months of documenting how privacy providers comply, how metadata becomes the exposure surface, and how architectural gaps survive policy fixes. The doctrine is Accountable by Design: governance built in before deployment, not retrofitted after failure. Applied to communication infrastructure, that doctrine produces AfterMail.

Founded by Dominick Costa, a New York-based GRC practitioner and operations leader with 20 years running systems at scale.

Read the Accountability Report →
Threat 01

Network traffic analysis

An adversary observing traffic correlates senders and recipients by timing and packet volume. The relay sees recipient IPs when inboxes are fetched. Network-level correlation is not defeated.

Partial: sender hidden, recipient IP visible to relay
Threat 02

Server-side metadata logging

A provider logs who communicated with whom, when, from which IP, how often. Disclosed under legal compulsion.

Mitigated: sealed sender + no identifiers
Threat 03

Account-based identity linkage

User accounts tie communications to a real-world identity. A single legal request retrieves an entire history.

Mitigated: no accounts exist
Threat 04

Device seizure and recovery

Physical or remote access to a device allows recovery of messages, keys, and contact graphs.

Mitigated: passphrase keys + remote wipe
Threat 05

Global passive adversary

A state-level adversary observing all internet traffic simultaneously attempts correlation attacks at scale. AfterMail uses HTTPS. Network-level timing attacks are not defeated at the transport layer.

Not mitigated at network level
Out of scope

Endpoint OS compromise

If the device running AfterMail is fully compromised at OS level, no communication layer can protect message content.

Out of scope: by design
Exposure surface Gmail / Outlook Proton Mail Signal AfterMail
Message content Exposed Protected Protected Protected
Sender / recipient identifiers Exposed Exposed Phone number None exist
Communication graph Exposed Exposed Phone numbers Not constructible
Timestamps and frequency Exposed Exposed Registration date Sender hidden; fetch timing visible
IP address / location Exposed VPN mitigates Sealed sender Sender IP hidden; recipient IP visible to relay
Network traffic analysis Vulnerable Vulnerable Vulnerable Sender hidden; network layer not anonymized
Legal compulsion disclosure Full metadata Account + IP metadata Registration + last seen Queue ID only

Get in touch.

For co-founder inquiries, early access, Sovereign tier discussions, or press. Reach out directly.

The Sovereign tier is
for organizations that
need to own the stack.

Private infrastructure deployment. Air-gap capable. DoD and FedRAMP-aligned architecture. Admin controls limited to Active/Inactive. No message access at any level.

Sovereign tier discussions are handled directly and confidentially.

Start a conversation