Your account number

You did not give us an email address or pick a password. Instead you got a 16-digit number, and that number is your account.

Write it down. Now.

We cannot recover it for you. Not if you ask nicely, not if you can describe your aliases, not if you can prove you paid us. There is no reset link because there is nowhere to send one.

This is not laziness. What we store is HMAC(secret, your number), a one-way transformation. Given what is in our database, nobody can work out your number, including us, including someone who steals the whole database, including someone who arrives with a court order.

That property is the point. It is also exactly why losing the number is final.

Put it in a password manager. Write it on paper and put the paper somewhere sensible. Both.

The recovery email, if you want one

You can attach an email address for recovery. It is encrypted at rest and it is the only route back into a lost account.

It is also, unavoidably, an email address we now hold. If your reason for being here is that we should hold nothing about you, skip it and rely on the paper. Most people should add one.

Two-factor

Worth turning on. When you do, save the backup codes somewhere separate from your account number, because losing both leaves you in the same place as losing the number.

If it leaks

A number you have written somewhere you no longer trust, sent to somebody, or typed into a page that turned out to be phishing can be replaced. Settings → account number, enter the current one, and you get a new one. It is shown once and then it is gone, same as the first time.

Everything survives the change: your aliases, their addresses, stored mail, your domains, whatever paid time is left. What ends is the old number, every other signed-in session, and any recovery link already sitting in an inbox. Your API key and app passwords are separate credentials and are untouched, so rotate those too if they were exposed by the same accident.

One case where we refuse: if the private inbox is on, the key that seals it is derived from your account number, so a new number could never open it and the mail already stored there would be unreadable forever. We stop rather than do that quietly. Turning the private inbox off first is a real choice, but it is a different one.

If somebody already has it

The same page has a lockdown button. One action turns off every alias, deletes every API key and app password, and signs out every session including the one you are using. Nothing is deleted, because this is meant for someone who is frightened and may well turn out to be wrong: a deleted alias reserves its address forever, a disabled one is a switch you can flip back.

Log in again with your number, turn back on what you still want, and rotate the number if you think it is the thing that leaked. Mail sent while an alias was off is refused at the door rather than queued, so senders get a bounce and nothing arrives silently later.

If you have already lost it

Then, honestly, you are probably stuck. If a recovery email was set, use it. If not, the aliases keep forwarding exactly as they did, so nothing breaks immediately, but you cannot log in to change anything.

The one thing that saves you here is your own domain. Aliases on a domain you control can be pointed somewhere else by you, without us. Aliases on our shared domains cannot.

Why not just use a password

Because a password needs an account to attach to, and an account with a password wants an email address for the reset flow, and now we know who you are. The number sidesteps all of it. You are anonymous to us in a way that is structural rather than promised.

The tradeoff is this page.

Something here wrong or missing? Tell us. These pages live in the same repository as the code, so a correction is a one-line change.