After a Mailbox Expires

"Deleted" is a word services use loosely. Here is precisely what happens when a temporary mailbox reaches the end of its life. For the deadlines themselves, see how long a mailbox lasts; this page is about what happens when one of them passes.

The mechanics

A background process runs continuously and looks for anything past its time. It removes expired messages first, then expired mailboxes. Removing a mailbox removes any messages still attached to it, and removing a message removes its stored files. All of it happens in the same pass.

The removals are actual deletions in the database, not a flag marking rows as hidden. Once the pass has run, a query for that address finds nothing, because there is nothing to find.

Stored attachments are deleted from object storage in the same operation, using keys collected before the database rows disappear. That ordering matters: after the rows are gone there would be no way to know which files to remove, and they would sit there indefinitely.

Inside a single pass

The details matter here, because "we delete it" is the sort of promise anyone can make.

The sweep runs every ten minutes inside the application itself, not as a separate service, because the whole job is a handful of statements and a second container would be complexity bought for nothing.

Only one copy of the application sweeps at a time. It takes a lock in the database first, and any other copy that finds the lock held skips that cycle rather than deleting the same rows twice.

Work happens in batches of five hundred records, so no single transaction runs long enough to slow down anything else. If more than that is due, the rest goes in the next pass ten minutes later.

The order inside the pass is fixed: collect the storage keys of doomed attachments, delete expired messages, delete expired mailboxes, and only then tell the file storage to remove the objects. Files go last on purpose. If storage happens to be unreachable at that moment, the database is already clean and the leftover files are removed later by the bucket's own expiry rule, rather than the reverse, where a file is gone but the row still points at it.

The same pass also removes abandoned registrations: accounts created but never confirmed, once the confirmation link is too old to work.

What survives

Server logs, briefly. They record that a request happened, not what a message contained. They are kept for a short period to keep the service running and to deal with abuse, then they age out.

Nothing else. There is no archive, no cold storage, no copy in a backup that somebody could restore from. This is intentional: a backup containing deleted mail would undo the entire point of deleting it.

Mail sent to an expired address

It is refused and discarded. The receiving side accepts messages for our domains in general, then looks for a mailbox matching the recipient. If none exists, the message is dropped without ever being written down.

The sender usually gets nothing back. We do not reply with an error saying the address is unknown, because that reply would confirm which addresses do exist, which is exactly the information somebody probing a domain wants.

So a message sent to an address that expired yesterday simply vanishes. Nobody is notified, including you.

Why there is no bounce

This differs from an ordinary provider in a way worth understanding, because it changes what the sender believes.

At a normal mail host, an unknown recipient is rejected during the delivery conversation itself. The receiving server answers with a permanent failure code, the sending server turns that into a delivery report, and a few seconds later the sender has a message in their inbox saying the address does not exist.

Here the domain accepts mail as a whole, and the decision about the recipient is made after the message has been taken in. There is no failure code to report and no report to send, so the sender learns nothing.

The consequence is quiet but real. A marketing platform decides an address is dead by counting hard bounces. Without them, the address you used stays on the list marked as delivering perfectly, and the campaigns keep going out for years into a mailbox that no longer exists. Nobody reads them and nobody pays any attention, which is exactly the outcome you wanted, but it is worth knowing that "the address expired" and "the company stopped mailing it" are two different events, and only the first one happened.

The address can be issued again

Once a mailbox is deleted, the address returns to the pool and can be handed to somebody else later. With random names on several domains this is unlikely, and with a name you chose yourself it is more likely, because chosen names are predictable.

The practical consequence: mail sent to an address long after you finished with it might one day land in a mailbox belonging to a stranger. That is another reason not to use a disposable address for anything lasting.

Avoiding this entirely would mean keeping a permanent list of every address ever used, and a permanent list is exactly what a service built on deletion should not have.

Recovery is not possible

Not by writing to support, not by explaining the circumstances, not for any amount of urgency. The data does not exist anywhere we can reach.

If that sounds unhelpful, consider the alternative. A service that could restore your deleted mail on request could also be compelled to produce somebody else's, or breached by someone who wanted it. The inability to recover is the same property that makes the service safe to use.

Why services keep mail and we do not

Most mail providers keep everything forever, and there are reasons: people want their history, search is valuable, and storage is cheap.

None of those reasons apply here. Nobody searches a temporary mailbox from last March. The history has no value to its owner five minutes after the code was used. What remains is the cost side of keeping data: it can leak, it can be demanded, and it grows without bound.

The service this one replaced kept everything and accumulated 7.6 gigabytes of attachments and 4.4 gigabytes of database, none of it ever read again. That is not a feature that was enjoyed, it is a liability that was accumulated.

Deleted here is not deleted everywhere

One honest limit, because it is the thing people most often assume wrongly.

Expiry removes our copy of the mail. It does not reach into the sender's systems. The company still has the record that somebody signed up, the message it sent you sits in its sending platform's history, and any link you followed was logged at the moment you followed it.

What expiry gives you is narrower and still worth having: the address stops resolving to anything, so the record on their side ages into a dead entry that cannot be matched against your other accounts or sold on as a working contact.

The mailbox disappearing is the end of your side of the exchange. Their side ends when their retention policy says so, and that is outside anybody's control here.

What this means practically

Nothing to export. There is no archive to download, because there is no archive.

Nothing to subpoena. A legal request for mail that no longer exists returns nothing, and that is true for everybody equally.

Nothing to lose in a breach. The interesting question about any breach is what the attacker gets. Here, at most, a day of mail belonging to people who already considered it disposable.

Nothing to remember to clean up. Most privacy advice fails because it requires ongoing discipline. This requires none: the deletion happens whether you think about it or not.

The one thing worth doing

Copy what you need while the message is in front of you. A verification code takes a second to use. A download link should be followed immediately. Anything you might want tomorrow belongs somewhere permanent, not in a mailbox designed to disappear.

If you find yourself repeatedly wishing a mailbox had lasted longer, that is a signal you are using a disposable address where an alias belongs. The fix is not a longer timer, it is a different tool.