Mail.td: The Temp Mail API Built for Testing Signup Flows at Scale

Mail.td — Thu, 22 Oct 2026 06:42:34 +0000

By the Mail.td team — we build the API this article is about. The comparison at the end is deliberately unflattering where it should be; check our claims against each tool's docs.

Every test suite hits the same wall: the signup flow sends a verification email, and the test has to read it. The standard workarounds are a shared Gmail inbox, a catch-all domain somebody babysits, or — the classic — skipping verification in tests and shipping the bug.

Temp mail APIs fix this properly. This is the one we built, what it does well, where it stops, and how the alternatives compare.

Mail.td for developers

Website: https://mail.td/?utm_source=devto&utm_medium=article&utm_campaign=best-temp-mail-api-2026

Mail.td has run a consumer temp mail service since 2021 — password-protected inboxes, no ads, 1,000+ members. The API sits on the same receiving infrastructure, which is the part that matters when CI starts creating inboxes by the hundred.

What you get

Programmatic inboxes — create addresses and read messages through a full API, designed for high-volume email receiving rather than a human clicking refresh.
Webhooks — mail arrival pushes an event to your system. No polling loops, no sleep(30) in your test suite hoping the email landed.
Password-protected inboxes — every inbox, API-created ones included, sits behind a password. Your test accounts aren't readable by anyone who guesses an address (the default state of most public temp inboxes).
Custom and premium domains — run test addresses on your own domain. Sites that blocklist the famous disposable domains rarely block yours.
Retention that outlives the test run — 1 hour on Free, 7 days on Pro. Multi-step onboarding, delayed approval emails, and "click the link we sent Tuesday" flows all fit inside that window.
Accounts that persist — an address stays active if opened once every 3 months; active Pro subscriptions are exempt from inactivity deletion. Long-lived staging accounts survive.

Where it stops

Receive-only. Mail.td will never send your app's outbound mail. Testing what your app sends is a different job (that's what sandboxes like Mailtrap are for).
A lost Free inbox password is unrecoverable — the server stores only a derived key, by design. Pro accounts can reset mailbox passwords from the console.

The pattern that works

Create a fresh inbox per test run — never share inboxes between tests.
Sign up with that address.
Wait on the webhook; if you must poll, poll with backoff and a hard 60–120s timeout, then fail loudly.
Extract the code/link, complete the flow, abandon the inbox.

Skip step 1 and you get the classic flaky suite: shared inboxes accumulate other runs' mail until one day your regex matches the wrong code at 3 a.m.

The alternatives, briefly

Mailinator — the enterprise incumbent: solid API, team features, private domains on paid plans. Free public inboxes are public, and pricing is enterprise-shaped.
Mailtrap Email Sandbox — captures what your app sends into a fake inbox. The outbound half of the problem; complementary, not a competitor.
Maildrop — instant public inboxes for humans (10 messages max, gone after 24h idle). No real API story for pipelines.

Need	Pick
Webhooks instead of polling	Mail.td
High-volume inbox creation	Mail.td
Test addresses on your own domain	Mail.td / Mailinator (paid)
Private (passworded) test inboxes	Mail.td
Testing outbound mail	Mailtrap
Enterprise procurement	Mailinator

If your suite is small, almost any tool here will do for a while. When it grows up — volume, webhooks, your own domains, inboxes that aren't public — that's the workload Mail.td was built for.