Temp mail APIs in 2026, compared honestly

How to read this page

Comparisons written by a vendor are usually a table with a column of green ticks under the vendor’s name. This one tries not to be, in three specific ways:

• Every row is a published fact, with a date. Free-tier limits, prices and retention windows are what each service’s own pricing or documentation page said on 1 September 2026. When a page was ambiguous the cell says so rather than guessing.
• The features are the ones that separate services, not the ones everyone has. Every service here can list a mailbox and read a message; that row would be all ticks and tell you nothing.
• There is a section on where this service loses. It is not short.

The six questions that actually separate them

The site’s method page lists these without naming anyone. Here they are with names attached.

1. Do you need a key or an account to read a mailbox? Keyless means a test suite has no secret to store and an agent has no sign-up to get through. Most developer platforms need both; most public-inbox services need neither.
2. What is free, and where does free stop? A monthly cap on inboxes or messages, a retention window, or a feature wall. The cap is the number that matters for CI, which creates a mailbox per run.
3. Can you point your own domain at it, and what does that cost? The answer to “the form refuses my address”. Free at a few services, a paid tier at most, absent at some.
4. How long does mail stay? Ten minutes suits a code; a week suits a trial that emails on day three; thirty days suits an audit trail. Longer is not better if you never wanted the mail kept.
5. Can an AI agent use it without a human? An MCP server, or a wait-for-message endpoint, or at least a tool description a model can read. New in 2026, and very unevenly covered.
6. Can it send, and does it have webhooks? Two things GrabMail does not do at all. If your workflow replies to mail, or cannot poll, you need a service in the developer-platform family.

Everything else — SDK count, uptime badges, dashboard polish — is real but secondary. A service that answers the six questions the way your job needs will do; one that does not will not, however many SDKs it ships.

The table

Nine services, six columns. “Own domain” means a domain you control receives mail into the service; “MCP” means a Model Context Protocol server the service itself runs. Prices are the cheapest paid tier as published, monthly, in the currency shown.

Checked 1 September 2026. “Plan-dependent” means the service publishes different windows per tier; “not stated” means the public pages did not give a number. A dash in your own reading of a vendor’s page beats any cell here.

Notes on each

A row cannot say why a service is the way it is. A paragraph can:

GrabMail

Public inboxes, keyless REST, a free MCP server with a blocking wait, your own domain free, 5-day retention, OpenAPI and llms.txt. The only paid thing is a pool of .com domains kept off the disposable-mail blocklists. Receive only, no webhooks, no SDKs, mailboxes readable by anyone who knows the address. Reference, limits, pricing.

mail.tm

The service behind an unusually large ecosystem of unofficial client libraries. Free, no paid tier, with an API that creates an address and returns a token for it. No own-domain feature and no MCP of its own, though third-party MCP wrappers exist. A good fit for a script that needs an inbox and nothing else.

Guerrilla Mail

The oldest of the public services, with a keyless JSON API and — unusually — the ability to send from the temporary address. Retention is short, around an hour, and the API’s rate limits are not published. The open-source mail server behind it is a project in its own right.

Mailinator

Public inboxes on the web since 2003, and a developer platform on top: API, private domains, webhooks and official SDKs on the paid business plans. The public domain is on nearly every blocklist, which the paid private domains exist to answer. The most established option for a QA team with a budget.

MailSlurp

The most complete developer platform in the list: SDKs in a dozen languages, webhooks, sending, phone numbers, SOC 2. A capped free tier and paid plans from about fifty dollars a month, with own domains on a higher tier. The right choice when email testing is a budgeted line item and you want everything in one account.

Mailsac

A long-running email testing platform with a free tier measured in API operations, webhooks from the first paid plan, POP3, and own domains as an inexpensive add-on. Good documentation and a public forum. Sits between the public services and MailSlurp on price and scope.

testmail.app

Built around namespaces and tags on its own domain rather than your domain, with JSON and GraphQL APIs and a small free tier with one-day retention. Clean and inexpensive; no own-domain option is the trade.

temp-mail.io and Catchmail

Two ends of the consumer-to-developer range. temp-mail.io is a large consumer temp-mail site — apps, extensions, dozens of languages — with a paid API and an MCP server reserved for subscribers. Catchmail is a small keyless API with a free own-domain feature and seven-day retention: the closest twin to this service, without an MCP server or a paid tier.

Which one, for which job

The families matter more than the rows. Pick the family, then the service:

Where GrabMail loses

A comparison from a contestant is worth exactly as much as this section. These are real requirements that this service does not meet, stated so that you do not discover them after building:

• No webhooks and no push. You poll at one read a second, or you let the MCP wait hold the call open for up to 25 seconds. A workflow that cannot poll needs MailSlurp or Mailsac.
• No sending. Receive only, by design. Replying from the address, or testing an outbound flow that expects a reply, needs Guerrilla Mail or a developer platform.
• No official SDKs. There is an OpenAPI document and three endpoints, which is enough for a generator or forty lines of code, but there is no npm install. MailSlurp and Mailinator ship libraries.
• Retention is 5 days and not adjustable. Not a tier, not a setting. Anything that needs mail kept for a month needs a paid platform.
• Mailboxes are public. Anyone who knows an address can read it, on public domains and on your own. There is no per-mailbox authentication; the alias is the only privacy mechanism. A test that sends real customer data needs a private inbox elsewhere.
• The paid plan is crypto-only and has no SLA. A team that needs an invoice on a card, or an uptime commitment in a contract, will not get either here.

What it wins on is the mirror image: nothing to sign up for, nothing to store in CI, your own domain free, an MCP server anyone can point an agent at, and a price of zero for everything but the off-blocklist pool. If the six bullets above are not your first requirements, that is the trade.

Verify the keyless claim in one line

The table says a mailbox here is readable with nothing. Rather than take that on trust, run it — there is no sign-up between you and the answer:

$ curl -sG https://grabmail.io/api/v1/mailbox --data-urlencode "address=anything@grabmail.io" | jq '{count, alias}'

A 200 with count: 0 and an alias is the whole proof. The equivalent check for any other service on this page is the first step of its own quickstart; how many steps come before the first message is a fair summary of the table.

Questions