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:
- Sending mail
- No. There is no endpoint that sends, and no outbound mail of any kind. A free service with no authentication that could send mail would be a spam relay within a day, and the abuse desk would become the whole company. It is also what makes the inbound server impossible to use as a relay.
- IMAP or POP3
- No. HTTPS only — a REST API and an MCP server. There is no mail client protocol to connect, and no password to give one. Reading is a GET.
- Webhooks or push notifications
- No. You poll, or you let the MCP server hold the call open until the message lands. A webhook needs a public endpoint on your side, which is exactly what a test runner and an agent do not have. Waiting inside one call solves the same problem without one.
- Keeping mail longer than 5 days
- No. Not a tier, not a setting, not a parameter. Mail we no longer hold is mail nobody can demand, lose or leak. There is no plan that extends it, and asking will not extend it either.
- Attachments over 5 MB
- No. The message is refused at SMTP time. Refused rather than silently truncated, so the sender is told instead of believing it arrived.
- Privacy on a shared domain
- No. Anyone who knows the address can read the mailbox. On a public domain the address is the only secret there is. Point your own domain here if you need an inbox nobody can guess into.
- Paying by card
- No. Crypto only, credited to a balance the subscription draws on. There is no card processor in the stack, so there is no card number to store or to lose.
- An uptime guarantee
- No. There is no SLA, on any plan. None is sold and none is implied. What exists instead is a status page that refuses to call a component healthy unless a monitor confirmed it in the last ten minutes.
- Tracking, analytics or advertising
- No. No third-party script, and no cookie banner because there are no cookies to consent to. Nothing on this site talks to anyone but this site. That is checkable from the Content-Security-Policy header rather than from this sentence.
How a message actually reaches you
Worth knowing, because it explains most of the behaviour you will meet:
- A sender looks up your domain's MX and finds
smtp.grabmail.io. - Our mail server answers. It accepts messages for domains hosted here — and for any domain whose MX points at us, which is how a new one connects itself on its first message. Everything else is refused, which is why it cannot be used as a relay.
- The message is handed to the storage layer over an encrypted connection, then dropped from the mail server.
- It appears in the mailbox — on the web page and through the API at the same moment, because they read the same thing.
- 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.