Deletion as the product
Most services treat deletion as a burden - something regulators make them do, eventually, to data they would rather keep. Mail Vanish is built the other way around: the entire value of a temporary inbox is that it stops existing. So we designed the burn to be the most reliable part of the system, and this post describes exactly what it does.
The lifecycle of a temporary inbox
When you land on Mail Vanish, you get a disposable email address tied to a random token in a cookie on your device - no account, no personal details. The address has no countdown: it keeps working for as long as its domain is active and mail keeps arriving. While it is live, mail delivered to the address is parsed, sanitized, and stored so you can read it, and each message is deleted automatically once it passes a short retention window. Hitting delete ends the address immediately, an address you replace stays in your history until you delete it, and a free address that gets no new mail for a set number of days, or that nobody opens for a while, is retired on its own. If you want the classic countdown, 10 minute mail runs a separate inbox on a timer you can extend.
A burned address closes at once; when a 10 minute mail timer hits zero, a scheduled job expires that mailbox within a minute. Either way the inbox stops accepting mail and stops being readable - by you or anyone else - immediately.
What gets destroyed, and when
Burning or expiry starts a short grace window (minutes, not days - it exists so an accidental burn right as you load a verification code is not instantly catastrophic on our side). After that window, a purge job hard-deletes the mailbox and everything attached to it: message rows, message bodies, attachments, and the raw source of each email held in object storage. This is deletion of the stored objects themselves, not a hidden flag on rows we quietly keep. Messages that age out of their retention window on a live address go the same way: an hourly job hard-deletes each one, with its body, attachments and raw source.
We do not archive deleted message content, we do not mine it first, and there is no "restore" path - which is also why we say plainly: never use a temporary address for anything you may need to recover.
What survives, briefly, and why
Running an email service that spammers constantly probe requires a little operational memory. Short-lived operational records - counters, delivery deduplication guards, and standard server logs - persist briefly for rate limiting and abuse prevention, then age out. Blocklist entries (sender domains and addresses that abuse the service) persist, because they contain the abuser's data, not yours.
Private Emails works on a different clock by design: those addresses do not expire, and messages are retained for your plan's retention window, then pruned on the same kind of schedule.
Why this design is worth trusting more than a promise
Every claim above is behavior, not policy: deletion jobs run on a schedule, purges delete storage objects, and remote content in messages never loads unless you press the button. A promise can be quietly rewritten; behavior has to actually run. The Privacy Policy remains the authoritative legal reference - but the system is built so that, most of the time, there is simply nothing left to have a policy about.