grabmail.io

About

A disposable inbox is a small idea. Most of the work is in refusing to make it bigger.

What this is

An address you can use once and forget. Type a name, use it to sign up somewhere, read the code that arrives, walk away. Nothing is created in advance, nothing is registered, and everything is gone after 5 days.

The same thing is available as three HTTP endpoints, because half the people who need a throwaway address are a test suite rather than a person.

What it deliberately is not

Every one of these is a decision, not a gap in the roadmap:

Not a mail sender
There is no endpoint that sends. A free, unauthenticated service that could send mail would be a spam relay within a day, and the abuse desk would become the whole company.
Not an archive
5 days is a property of the service, not a tier. Mail we no longer hold is mail nobody can demand, lose or leak.
Not an account system
Public addresses need no signup, so there is no password to breach, no email list to leak and no profile to sell. The absence is the feature.
Not a privacy tool for serious secrets
On a shared domain the address is the only secret. Anyone who guesses it reads the mailbox. We say so on the homepage, in the FAQ, in the inbox and in the docs, because a service that buries this is setting its users up.

How a message actually reaches you

Worth knowing, because it explains most of the behaviour you will meet:

  1. A sender looks up your domain's MX and finds smtp.grabmail.io.
  2. Our mail server answers. It accepts messages for domains hosted here and refuses everything else, which is why it cannot be used as a relay.
  3. The message is handed to the storage layer over an encrypted connection, then dropped from the mail server.
  4. It appears in the mailbox — on the web page and through the API at the same moment, because they read the same thing.
  5. It is deleted 5 days later, read or not.

If the storage layer is ever unreachable, step 3 fails temporarily and the message waits in the mail queue rather than bouncing. Senders do not retry a permanent rejection, so a permanent rejection for our own outage would lose your mail. That distinction is the single most important design decision in the whole system.

How it is built

No tracking, and nothing to opt out of
No analytics, no third-party scripts, no cookie banner, because there are no cookies to consent to. Nothing on this site talks to anyone but this site.
The limits are published
Every ceiling has a page. A limit you discover by hitting it is a documentation bug.
The docs are the contract
The reference and the homepage read from the same source, so the marketing page and the API cannot describe two different products.
Boring where it matters
The mail path is a standard, well-understood mail server rather than something clever written for this. Its queue is what makes an outage invisible to senders.

Who runs it

A small independent team. There is no investor to grow for, which is why the service has no expiry date on it and why nothing here is funded by watching you.

There is no support desk and no ticket queue, which is the honest shape of a free service run by a few people: what exists is a system simple enough to need very little support.