A Mailinator Alternative

Token-protected inboxes and a free API, with an honest account of the trade-offs.

your address

-

OTP codessignup confirmationspassword resetsmagic linksverification emailsnewsletter testswebhook receipts
OTP codessignup confirmationspassword resetsmagic linksverification emailsnewsletter testswebhook receipts

Live inbox

Auto-refreshing every 10 seconds.

Nothing here yet

Send a test mail or use the address on a signup form. New messages land here automatically.

What Mailinator gets right

Mailinator has been the default answer for QA email testing for well over a decade, and it earned that position. The core idea is genuinely elegant: every address at the domain already exists. You do not create anything. You invent qa-test-123@mailinator.com in the moment, use it, and read the result in the web interface.

That means no provisioning step, no token to carry, and no cleanup. For manual testing it is still one of the fastest workflows available, and any comparison that pretends otherwise is selling something.

Where it stops fitting

Public inboxes

The property that makes Mailinator's free tier fast is the same one that limits it: every inbox is public. There is no access control, because there is no account. Anyone who types the same address into the search box reads the same mail.

For a signup confirmation on a throwaway staging app, that is fine. It stops being fine when test messages contain a password reset token for a shared environment, a link to an unprotected staging URL, or real customer data that reached staging through a database copy. Teams usually discover this during a security review rather than by choosing it deliberately.

Automation is a paid feature

Reading mail programmatically requires a paid plan. That is a reasonable business model and the paid product is capable. But it means a small team that wants a CI suite to poll an inbox has to buy a subscription before it can write the test, and for many projects that is where the evaluation ends.

What this service does differently

  • Inboxes are not publicly readable. Reading a mailbox requires the access token issued when it was created. Knowing the address alone is not enough, so a guessed address does not expose the mail.
  • The API is free and needs no key. One HTTP POST provisions a mailbox and returns a token. There is no signup, no billing, and no plan to upgrade to.
  • Rotating domains. Addresses are issued across a pool of domains rather than one fixed domain, which helps with sites that blocklist a well-known one.

Where Mailinator is still the better choice

This is the part most comparison pages leave out. If any of the following describes your situation, the paid product is the right call and we would rather say so.

  • You need a private domain. Mailinator's paid tier lets you route your own domain into it. There is no equivalent here.
  • You need retention guarantees. Our messages live on an upstream provider and we make no promise about how long they last. If your compliance process needs a defined retention window, you need a vendor who will contract for one.
  • You need webhooks or team features. There is no push delivery here, no shared team account, and no role management. You poll, and that is all.
  • You need an SLA or support. This is a free service with no uptime guarantee. Anything business-critical deserves a contract.
  • You want to choose the address. Inventing an address on demand is genuinely convenient, and the token model gives that up in exchange for access control.

Side by side

Mailinator (free)Mailinator (paid)Test Emails
Inbox privacyPublicPrivateToken required
API accessNoYesYes, free
Pick your own addressYesYesNo
Custom domainNoYesNo
WebhooksNoYesNo
Retention guaranteeNoYesNo
Support / SLANoYesNo
CostFreeSubscriptionFree

Migrating a test suite

The structural change is that you provision before you use, instead of inventing an address inline. A Mailinator-style test hard-codes the address; here you create one and keep the token.

// Before: address invented inline, inbox is public
const address = 'qa-test-' + runId + '@mailinator.com';

// After: provision, then keep the token for reads
const res = await fetch('https://test-emails.com/hcgi/api/mailbox', { method: 'POST' });
const { address, token } = await res.json();

Reads then carry the token, and because delivery is asynchronous you should poll against a deadline rather than reading once.

const res = await fetch('https://test-emails.com/hcgi/api/mailbox/messages', {
  headers: { 'x-mail-token': token }
});
const { messages } = await res.json();

Two things to fix while you are in there. Match on subject or sender rather than taking messages[0], and do not assert on the domain, since it comes from a rotating pool. The email testing guide has a polling helper worth copying, in both Playwright and Cypress form.

Choosing between them

If you are testing manually and the mail is not sensitive, Mailinator's free tier is hard to beat on speed. If you need automation without a subscription, or publicly readable test mail is not acceptable, this is a reasonable swap. If you need custom domains, retention, webhooks, or a support contract, buy the paid product. Those are different problems, and a free service is the wrong tool for the last one.