DOM Mail
Compose
Inbox
Nothing here. That is the good state.
Outbox
Nothing sent yet.
Drafts
No drafts.
Settings
Appearance
Privacy
Off by default. Addresses are masked in lists and message headers, and message bodies stay collapsed until you open them, so a screenshot or a shoulder-surfer cannot capture readable content. Turning this on also disables the PII masking that guards against screen theft.Identity
Editor
Signature
Mail Server
Encryption
Storage: unencrypted
Anti-Surveillance
PII obfuscation on screen is controlled in Account → Privacy → "Show full addresses".
Network
Access via Tor: http://domail.onion (configure onion service separately)
Access via I2P: http://domail.i2p (configure I2P tunnel separately)
Optional networked features
Both features below are off by default. DOM Mail is designed to be purely local, and turning either of these on deliberately gives up part of that privacy. Read the warning on each before enabling it.
Install Own Mail Server (MX Node)
Run a full mail server directly from this browser tab using WebAssembly. Handles SMTP (port 25), IMAP, and submission (587/465) with TLS. Receives and sends mail with any email provider worldwide (Gmail, Outlook, Proton, etc.).
Running an MX node makes your server directly reachable on the public internet:
- Your public IP and online times are visible to anyone connecting to your MX.
- Port 25 must be open on your router/firewall for inbound mail delivery.
- Metadata (From, To, Subject, Date) is visible to upstream/downstream MTAs even with PGP.
- TLS certificates are tied to your domain — use Let's Encrypt for automation.
Recommended transport for public internet. When active, this MX node becomes the preferred path for Direct/80/443 TLS delivery, with military-grade hardening: TLS 1.3 only, certificate pinning, DANE/TLSA, MTA-STS, and rate limiting. Can also route through Tor, I2P, Nostr, Yggdrasil, Reticulum, WebRTC, BLE, DNS, Sneakernet, and Federation as additional transport layers.
Armored encryption (PGP)
This is an OpenPGP-compatible armor envelope (RFC 4880 §6, with CRC-24 checksums) carrying DOM Mail's own packet format. GnuPG's armor tools will parse it and validate the checksum, but it will not decrypt in GnuPG and is not a conformant RFC 4880 message. Use GnuPG when you need real OpenPGP interoperability.
Metadata is still exposed. Encrypting the body does not hide the
envelope. Whoever handles the message still sees From, To,
Subject, Date and the size of the ciphertext. Timing analysis
is possible regardless.
Two modes. Key mode seals to recipient X25519 keys and only reaches DOM Mail peers. Passphrase mode needs nothing but a shared secret, so any recipient who has DOM Mail can open it. Both are read by DOM Mail clients only — GnuPG still cannot decrypt them.
Recipients must be DOM Mail peers whose X25519 public keys you have already obtained. The keyring is stored locally and is never transmitted anywhere on its own.
WebSocket relay
Enabling a relay gives up DOM Mail's core privacy property. Before you do, understand exactly what changes:
- Your IP address and online times become visible to the relay operator. On Tor this defeats the purpose entirely.
- Traffic analysis stays possible even with an encrypted body: an observer can still see who talks to whom, when, and how much data moves.
- If PGP is off, the envelope is readable in plaintext by the relay.
- A malicious relay can drop, replay, reorder or censor anything it carries. There is no authentication of the relay and no delivery guarantee.
- DOM Mail stops being purely local and stops working offline.
Leave this off unless you specifically need to relay mail between two devices you control.
GnuPG integration
Enabling GnuPG integration requires a local GnuPG installation. DOM Mail will invoke the gpg binary for encryption/decryption operations.
- GnuPG must be installed separately and available in your system PATH.
- Keys are managed by GnuPG, not DOM Mail. Your existing keyring is used.
- Metadata is still exposed — the envelope (From, To, Subject, Date) remains visible to intermediaries.
- No passphrase storage — you will be prompted for your GnuPG passphrase when needed.
This is for users who already use GnuPG and want DOM Mail to interoperate with their existing keyring.
Multi-Network & Advanced Transports (13 Vectors)
Multi-RouteToggle individual network transports, anonymity routes, and air-gapped vectors. All, some, or none can be active (default uses Direct HTTPS 80/443 TLS, which can also be disabled). Cache this page offline via Service Worker for full untethered multi-network operation. Expand any vector for its cybersecurity & anonymity risk disclosure.
Strength: Universal reach and speed. Anonymity risk: Your real IP is exposed to the server and every intermediary; ISPs, CDNs and mail gateways can log the envelope. Mitigation: Combine with the VPN gateway or Tor; keep PGP on so contents stay sealed even when transport metadata leaks.
Strength: Strong cryptographic anonymity, hidden service location. Anonymity risk: Latency and traffic correlation attacks if you also use clearnet in the same session; guard relays may be hostile. Mitigation: Use the Tor Browser circuit discipline, avoid logging in to identifying accounts, and never mix clearnet and onion identities.
Strength: Garlic-routed peer-to-peer darknet, no central directory. Anonymity risk: Slow bootstrap; tunnels are shorter-lived so availability can drop; a misconfigured router can leak your real IP. Mitigation: Keep the i2pd container firewalled, verify tunnel leases, and do not enable inbound clearnet on the same host.
Strength: Censorship-resistant static publishing with immutable content addressing. Anonymity risk: IPFS gateway operators and ENS RPC providers see your IP and query patterns; pins can expire. Mitigation: Run your own IPFS node on kernel, use a local ENS resolver, and pin critical content to multiple nodes.
Strength: Sovereign peer-to-peer collaboration, no central forge. Anonymity risk: Peer gossip exposes your node's network identity unless wrapped in Tor/Yggdrasil; seeds are public. Mitigation: Run the Radicle node on kernel behind Tor, and never commit personal keys to a public seed.
Strength: End-to-end encrypted mesh routing with no DNS or central authority. Anonymity risk: Peers see the overlay routing path; a compromised peer can observe coarse traffic patterns. Mitigation: Combine with an anonymizing layer, rotate peering keys, and keep the mesh overlay off completely separate interfaces from clearnet.
Strength: Decentralized store-and-forward E2EE direct messages (NIP-04 / NIP-17). Anonymity risk: Relays are untrusted buffers that see your IP, timing and message sizes; a relay can drop or correlate events. Mitigation: Self-host the strfry relay on kernel, publish over Tor or VPN, and treat relay metadata as public.
Strength: Zero-infrastructure store-and-forward over packet radio — works with no internet at all. Anonymity risk: Very low bandwidth; radio direction-finding can physically locate a transmitter. Mitigation: Encrypt with LXMF/PGP, keep transmissions short, and use directional or reduced-power antennas.
Strength: Direct encrypted browser-to-browser transfer, no relay server for payload. Anonymity risk: ICE candidates can leak local and public IP addresses; signalling must be exchanged out-of-band. Mitigation: Force relay-only (TURN) ICE, exchange SDP over an already-anonymized channel, and disable non-proxied UDP.
Strength: Air-gapped local proximity exchange with no internet. Anonymity risk: Advertising addresses can be tracked over time; short radio range; pairing/relay nodes can observe adjacency. Mitigation: Rotate BLE addresses, keep payloads PGP-sealed, and treat any nearby observer as hostile.
Strength: Bypasses restrictive firewalls and captive portals that only permit DNS. Anonymity risk: Recursive resolvers log every query; throughput is tiny; unusual query volumes are trivially fingerprinted by deep-packet inspection. Mitigation: Use a trusted DoH/DoT resolver, keep payloads encrypted, and rate-limit to blend with normal DNS.
Strength: Absolute air-gap security — nothing ever touches a network. Anonymity risk: Purely physical: device loss/theft and QR shoulder-surfing. Mitigation: Encrypt volumes, verify fingerprints out-of-band, and destroy media after transfer.
Strength: Bridges to open federated social/chat networks for broad reach. Anonymity risk: Federation servers retain metadata, and bridges may link a pseudonymous DOM Mail identity to a real federated account. Mitigation: Self-host the gateway on kernel, compartmentalize identities, and never reuse a speaking alias across networks.
VPN Gateway & Clearnet Masking
Route public clearnet requests and web email gateways (e.g. Gmail/Outlook SMTP bridges) through a custom VPN or SOCKS5/HTTP proxy IP address.
Enabling a VPN proxy routes your public web/clearnet traffic through the configured gateway. However, the VPN provider sees your connection endpoint (though not message contents if E2EE/PGP is active). For maximum anonymity, prefer Tor, I2P, or air-gapped mesh vectors over commercial VPNs.
SMTP Relay — Send to External Email
Connect to a DOM Mail relay server that bridges WebSocket to SMTP, enabling delivery to any email address (Gmail, Outlook, Proton, etc.). The relay handles SMTP authentication and delivery; this client only sends encrypted WebSocket frames.
wss:// required. The relay must speak the DOMP/1 protocol with SMTP bridge support.
Enabling an SMTP relay gives up part of DOM Mail's privacy. Understand the trade-offs:
- Your IP address and online times become visible to the relay operator. Use Tor/VPN if this matters.
- The relay operator can see all envelope metadata: From, To, Cc, Subject, Date, message size — even if PGP encrypts the body.
- SMTP credentials (username/password) are sent to the relay for authentication. Only use a relay you trust, and prefer app-specific passwords.
- A malicious relay can drop, replay, reorder or censor messages. No delivery guarantee.
- DOM Mail stops being purely local when this is on.
This feature requires a DOM Mail relay server with SMTP bridge enabled. Run your own relay or use one you trust.
Contacts
No contacts learned yet.
This tab holds a mail identity.
Wiping destroys the identity, every message, every draft and every contact. It then deletes the storage itself. There is no recovery, no backup taken first, and no copy left in this browser.
Everything else in the tab keeps working. Only mail is destroyed.