Comparing disposable email APIs

1. Does reading a mailbox need a key or an account?

This is the one that decides whether the service can be used at all from a place that cannot hold a secret: a CI job on a fork, a shared script, a browser, an AI agent working on somebody else's machine. A key is not a small friction — it is an account, a dashboard, a rotation policy and a secret store.

How to answer it yourself

Ask for a mailbox with no headers at all. If it answers 200, no key is needed. If it answers 401 or 403, one is.

curl -s -o /dev/null -w "%{http_code}\n" \
  "https://SERVICE/api/v1/mailbox?address=someone@THEIR-DOMAIN"

Our answer

No key and no account, for the public domains and for a domain of your own. A key exists only for the premium pool, because a pool whose names are published stops being worth paying for.

2. Can you point your own domain at it, and what does that cost?

A domain of your own is the difference between an address a signup form recognises as disposable and one it does not. It is also the only way to get an inbox nobody else can guess into. Most services either do not offer it or sell it as the paid tier — which is the whole business model, and worth knowing before you build on the free one.

How to answer it yourself

Read the MX host they publish, then check whether the docs ask you to register the domain with them afterwards. A service that needs a registration step has an account somewhere in your future.

dig +short MX their-example-domain.com

Our answer

One MX record at smtp.grabmail.io, free and unlimited, on every plan including the free one. There is no registration step: the first message that arrives connects the domain, because publishing the record IS the proof you control it.

3. How long is a message kept — and is that enforced or promised?

Two services can both say "seven days" and mean different things. One deletes on a schedule; the other deletes when storage gets tight. For a test suite the number barely matters. For anything you would rather not leave lying around, the difference between an enforced window and an advertised one is the whole point.

How to answer it yourself

Send yourself a message, note the date the API returns, and come back after the window. The word to look for in their copy is "up to" — it means the number is a ceiling, not a schedule.

curl -s "https://SERVICE/api/v1/mailbox?address=…" | grep -o '"date":"[^"]*"'

Our answer

5 days exactly, enforced by a job that runs every ten minutes, not by a sentence on a policy page. It is not a tier: no plan, parameter or request extends it. Catchmail — the service most people arrive here from — keeps mail up to seven days, which is longer than ours.

4. Can a program wait for a message, or must it poll?

A test that polls has to choose a sleep interval, and both choices are wrong: too short and it burns the rate limit, too long and the suite takes minutes longer than it needs to. An AI agent has the same problem and cannot solve it at all — it has no public endpoint for a webhook and no patience for a loop.

How to answer it yourself

Look for either a webhook in the reference, or a call that blocks. If the documentation only shows a list endpoint, polling is the answer whether it says so or not.

curl -s https://SERVICE/openapi.json | grep -o '"/[a-z/{}._-]*"'

Our answer

Both, and neither needs a public endpoint on your side. The REST API is polled — 1 read a second per address is the intended rhythm. The MCP server has a tool that holds the call open until the message actually lands, up to 25 seconds, which is what an agent needs and what a webhook cannot give it.

5. What happens when a signup form rejects the address?

It will happen, on every service with shared public domains, and it is the moment most people give up and conclude that disposable mail "does not work". What separates services here is not whether it happens but whether they told you in advance and what they leave you with.

How to answer it yourself

Look the public domain up in a blocklist that signup forms actually use. If it is listed, expect refusals — and check what the service offers next.

grep -x their-domain.com <(curl -s https://raw.githubusercontent.com/disposable/disposable-email-domains/master/domains.txt)

Our answer

Said on the homepage, in the FAQ and in llms.txt rather than discovered. Two ways out, and the free one comes first: point a domain of your own here, which costs nothing and has no limit; or, if you would rather not own or expose one, a paid pool of 92 .com domains that are kept off those lists. The public domains stay free either way.

6. Can it send mail — and do you want it to?

A receive-only service cannot be turned into a spam relay, which is why its inbound server can afford to accept mail for any domain that points at it. A service that can send is a service that will eventually be abused, and abuse is what ends free tiers. If you need to send, this whole category is the wrong tool.

How to answer it yourself

Look for a POST that takes a recipient. If the reference has one, the service can send; if it has none, it cannot, and that is usually deliberate.

curl -s https://SERVICE/openapi.json | grep -c '"post"'

Our answer

No. There is no endpoint that sends and no outbound mail of any kind — not even the password-reset kind. That absence is what lets the inbound edge accept mail for any domain whose MX points here without becoming a relay.

Our answers, in one place

Every figure here is read from the same constants the service enforces, so this table cannot disagree with the API.

Moving an existing integration

This category has settled on three calls, and most services expose them at the same three paths. The migration is usually the base URL and the paging loop.

GET    /api/v1/mailbox?address=<address>
GET    /api/v1/message/<id>?mailbox=<address>
DELETE /api/v1/message/<id>?mailbox=<address>

Catchmail, the service people most often arrive here from, uses those same three paths. Two things differ, and both are in the paging: their list answers with page / page_size and a total, ours answers with a next cursor you pass back to walk the rest. Their base URL is a subdomain; ours is the site itself. Everything else — the field names, the status codes, the shape of a message — lines up.

One thing you gain and one you lose, so you can weigh them: every mailbox here also carries an alias — a second address that delivers to it and cannot be used to read it, which is what you hand to the form you are signing up to. And retention here is 5 days rather than seven.

Third-party details on this page were checked against each service's own published documentation on 2026-08-31.

The full API reference · Quickstart · Pricing

Questions people actually ask

Which disposable email API is the best one?

There is no single answer, and a page that gave you one would be selling something. The six questions above are the ones that actually differ between services; three of them are answered by a single command, and the answers decide it for your case rather than in general.

I am moving from another disposable-mail API. How much has to change?

Usually the base URL and the paging loop. The three paths this category settled on are the same nearly everywhere — list a mailbox, read a message, delete it — and what differs is how the list is paged and what the fields are called.

Do you keep messages longer than the service I am on?

Probably not. 5 days is short on purpose and it is a hard limit, not a tier. If your test suite needs a message an hour after it arrived, that is fine; if you need one next week, fetch it and store it on your side.

Is there an uptime guarantee?

No, and none is sold. What exists instead is a status page that refuses to call a component healthy unless a monitor confirmed it recently — a stale check is shown as no check rather than as good news.