Privacy & data retention
What we store, why, and for how long: the whole list. This page is generated from the same configuration the running system enforces, so it can't drift from reality.
IP addresses & connection metadata
A VPN can say "we store nothing" because it's a dumb pipe. Email is not: to receive a message and forward it, our mail server has to accept a network connection and route the message, so an IP address does pass through memory for the instant that takes. We're precise about what that does and doesn't mean, because a vague "we log nothing" would be untrue for any email service that claims otherwise.
What that means in practice:
- Your connecting IP is used only in-memory to accept and route mail. It is never written to our database and is never linked to your account, your aliases, or a timestamp we keep.
- We strip the sender's originating IP (the
ReceivedandX-*headers) out of every message before forwarding it, so the people you correspond with can't see it, and they can't see yours. - Operational logs have IP addresses scrubbed, and we keep no per-request web access log. Where the mail server (Postfix) or the OS would otherwise log a connection, our deployment guide has operators discard it or keep it in RAM only, for at most an hour.
- Because none of this is stored, there is nothing tying "who connected, from where, and when" to your account for us to hand over.
- The one exception, stated plainly: rate limiting has to remember something, or it isn't rate limiting. Login attempts and signups are counted per client in memory only: a few minutes in most cases, up to six hours for the signup counter that makes each additional free account cost more CPU than the last. The key is an HMAC of the address under a secret we hold, not the address itself; it is never written to disk, never linked to an account or an alias, and is gone on restart. It records how many, never who.
This is the closest an email service can honestly get to a no-logs VPN: we can't refuse to process a routing IP, but we can (and do) refuse to keep it.
We warn you when a forwarded message fails its sender domain's DMARC, the clearest sign of a spoofed or phishing email. That check looks only at the authentication result (did the message legitimately come from the domain it claims?), which our own mail server derives from the sender's public SPF/DKIM/DMARC records. We do not, and technically need not, look at what the email says. It's on by default and you can turn it off account-wide or per alias.
Everything we store, and why
This list is exhaustive. Every piece of data alias holds is in this table, with the reason we hold it. We don't store anything that isn't listed here. Secrets are stored only as one-way hashes (shown as such), so a database dump can't be turned back into your login, keys, or passwords. Beyond that, the personal data below is encrypted at rest: your forwarding address, the senders who write to you, your notes, any recovery email or phone number, and stored inbox messages. A stolen copy of our database, without the key we keep outside it, yields unreadable blobs. We're precise about the limit, though: a running server must decrypt your forwarding address to deliver mail while you're offline, so this protects against a stolen backup or disk, not against us.
Or hand us no address at all. Sign up leaving the forwarding field blank and your aliases keep their mail here for you to read, so there is no address of yours in the table below to encrypt, leak or be compelled to produce: the row simply doesn't exist. Pair it with the private inbox and we can't read the stored mail either. The trade is real and stated up front: mail kept this way is deleted on the retention clock below, and you can't reply by emailing us back, because we'd have nothing to recognise you by.
| What | Why we store it | How long |
|---|---|---|
| Account: a hash of your account number, a public support reference, your plan and paid-until dates | To log you in (the number is the credential) and to know whether a paid plan (Unlimited or Everything) is active. We never store the number itself, only HMAC(secret, number). | Until you delete your account |
| Your preferences (sender format, alias style, spam policy, phishing-warning and PGP toggles) | To make the service behave the way you set it | Until changed or account deleted |
| 2FA secret & backup codes (only if you enable 2FA) | To check your second factor at login. Backup codes are stored hashed. | Until you disable 2FA |
| Recovery email (only if you choose to add one, encrypted at rest) | So you can get back in if you lose your number. Optional; blank by default and we hold nothing. One honest caveat: because recovery has to find your account from the address alone, its lookup index can't be salted per account, so if two accounts use the same recovery address, we can tell they're related (not what the address is). 2FA backup codes avoid this entirely. | Until you remove it |
| Referral code & a count of rewards earned | To run invites. We store your own random code and a number, and never a link between you and anyone you invited, so a referral can't be used to connect two accounts. | Until you delete your account |
| Mailboxes: the destination addresses you forward to (encrypted at rest), their verified status, any PGP public key you add, and any extra send-from addresses you authorise (encrypted at rest) | To know where to forward, to encrypt to your key if you set one, and to let addresses you control reply through a reverse alias. We find your mailbox by a keyed one-way index rather than by the address, and that index is salted per account. So two accounts forwarding to the same inbox produce different values and cannot be linked to each other. | Until you remove them |
| Aliases: the alias address, your note/name (encrypted at rest), tags, and burner expiry settings | They are the service: the addresses you hand out and how you organise them. The alias address itself must stay readable: it is what mail is routed on. Your notes are not, so they are encrypted. | Until you delete them (then reserved) |
| Contacts / reverse-aliases: the sender addresses that have written to an alias (encrypted at rest), and the masked reply address we mint for each | So you can reply without revealing your real address, and block a sender. The lookup index here is salted per alias, so the same person writing to several of your aliases produces unrelated values, so we cannot reconstruct who corresponds with you across them. Any PGP key a contact provides is stored to encrypt replies. | Until you delete the alias |
| Custom domains, subdomains, directories, auto-create rules, presets, forwarding rules, webhooks | Your own configuration and automation | Until you delete them |
| Delivery & bounce metadata (which alias, forward/reply, delivered/blocked/bounced; never sender, subject, or body) | Your activity feed, bounce auto-disable, and abuse rate limits | 3 days, then deleted |
| Sender / domain reputation counters | Spam handling and anti-blocklist domain rotation. Counts only, no message content | Rolling; pruned with metadata |
| Inbox-mode stored messages (opt-in per alias: subject & body) | Only for aliases you switch to inbox mode, which have no mailbox to forward to, and you asked us to hold this mail so you can read it | 30 days, or until deleted |
| Stored messages you mark keep | You asked us to hold a specific message past the clock: a receipt, a booking, something you need later. Per message and reversible; there is no account-wide setting for it, so the schedule above stays the default for everything you don't touch. Said plainly: what we still hold is what can be demanded of us, so a kept message is one you've chosen to leave on our disk. | Until you delete it |
| Copies of mail you send from an alias (recipient, subject & body) | Your Sent list. Kept only for aliases that already keep their mail; a plain forwarding alias never starts storing content because you sent something. Note that sending itself is not private from us: to reach a mail server the message must pass through us in the clear, even when your stored mail is sealed to your key. | 30 days, or until deleted |
| API keys & SMTP app passwords (stored hashed) | To authenticate your API and mail-client access. Plaintext is shown once at creation and never stored. | Until you revoke them |
| Payment records: amount, currency, method, and a processor reference (no card number, no name) | To credit your paid time and prevent double-spend. Monero/cash paths carry nothing that identifies you. While we hold the processor reference, a card payment is linkable to this account via your processor, so we drop it as soon as it's no longer needed for a refund. | Amount/date kept for accounting; reference erased after 90 days (immediately for cash) |
| Identities: the username for a masked identity (no password; those are generated in your browser and never sent to us) | To show the identity's login name alongside its masked email/phone | Until you delete the identity |
| Phone masks & SMS metadata (the masked number, where it forwards, and counterparty numbers; never message text) | To relay SMS for premium phone masks and route your replies | Until you release the number |
| Login sessions | To keep you logged in | 30 days, or until logout |
| A count of recent failed attempts against one credential: a second-factor code or an SMTP app password | So a brute-force ceiling actually holds. Our web app and mail service are separate processes, each with several workers, so a limit kept in memory is really that limit times however many copies are running. The count is all we keep: no IP address, no per-attempt times, no record of what was guessed. A successful login deletes the row immediately, so this can never become a standing list of accounts somebody has tried to break into. | Until you log in, or the window lapses |
| Team accounts (business edition): the team name, hashed invite codes, and a who-did-what audit trail (actor, action, time) | Only if you create or join a team, to share doors with colleagues and keep an accountability log (NIS2/ISO). Metadata only, never message content. | Until you leave or delete the team |
| Suspension reason & appeal text (only if your account is suspended) | To tell you plainly why, and to let you appeal without any ID | Until the appeal is resolved |
| Abuse reports filed against an alias: the address reported, the report text, an optional reply address, and what we did about it. Encrypted at rest. Written by someone outside, so this is the one place we hold text that is not yours and that you did not agree to. | Because our protection from liability for what users send depends on being able to show we acted on what we were told. A record of the report and the response is that evidence. We deliberately do not store a link from the report to the account behind the alias. | Kept as evidence that we acted |
| Reserved deleted-alias addresses (the address only, no content) | So a deleted alias can never be re-created and inherit stray mail | Kept, by design |
| "Sign in with alias" apps (only if you use it): the apps you register or connect, their hashed secrets, the dedicated alias shared with each, and short-lived hashed sign-in codes and tokens | To let you sign in to other sites with a private alias instead of your real address, and to let you disconnect any app in one click. Metadata only, never message content. | Until you disconnect the app; codes/tokens expire in minutes/hours |
Backups outlive the retention clock
One caveat we would rather state than let you assume: our database is backed up nightly and those backups are kept for 14 days. Mail deleted by this setting can therefore still exist in a backup for up to 14 days afterwards. Sealing your inbox means those copies are ciphertext too.
We mention it because a retention setting that felt like a guarantee while a nightly dump quietly held the same mail would be a lie by omission, and this page is the one place we cannot afford one. Everything in those dumps is encrypted with keys that are not stored alongside them.
If we ever change this
We treat this page as a promise, not marketing. If we ever want to store a new kind of data that isn't already listed above:
- We update this page first, so the list stays exhaustive and true.
- We show an unmissable alert on your account page describing exactly what would be stored and why, before we begin storing it, not after.
- Nothing new is collected until that notice has gone up. No silent changes, no burying it in a policy update you'd never see.
Because your account needs no identity, the honest floor stays the same: we can only ever store the operational data above, never who you are.