MailSlurp is a full email platform: sending and receiving, SMTP and IMAP access, permanent mailboxes, and phone numbers in multiple regions. If your suite creates an inbox, waits for an OTP or a link, and asserts — you're pricing a platform to do a fixture's job. Here's the honest breakdown.
Several rows up there favor MailSlurp, and we left them in. It is genuinely the bigger product: sending as well as receiving, SMTP and IMAP endpoints your existing mail client code can talk to, mailboxes that live until you delete them, virus scanning, rendering previews and placement tests, SDKs in ten languages, a first-party MCP server, and phone numbers in thirteen countries to our one. Its free plan is also larger than ours. If your suite needs to reply to a message, drive a real SMTP client, or keep a mailbox alive for months, we are disqualified by design, not by omission.
The rows that favor us are about pricing shape and what happens without asking. Inbox-per-test is the pattern that makes email tests reliable — and under a monthly inbox-creation allowance (100 on their free plan, 5,000 on Growth), every test spends from a counted budget. On MailFixture, inbox creation isn't metered on any plan (only the number active at once is capped), because short-lived inboxes are the product, not an add-on. Same with people: whoever is debugging the flaky login spec at 6pm has their own sign-in, on every plan, because we count messages, not seats. And extraction runs on every message automatically — the ranked OTP and links classified as verify, reset, or unsubscribe are already on the message when the wait returns, and our MCP server exposes that same wait as a tool, so an agent gets "wait for the code" in one call.
And the last two rows are one philosophy seen from two sides. We never send mail — no reply, no forward, no SMTP client anywhere in the codebase — so our IPs can't land on a sending blocklist and no bug of ours can ever send email with your domain on it. And your test mail deletes itself on a schedule (3–30 days by plan) instead of filling a storage cap, because a fixture's job is to exist for the duration of the test, then get out of the way.
For receiving suites the concepts map one-to-one: an inbox is an inbox, and your waitForLatestEmail + parse becomes a single long-poll that returns the OTP or classified link directly. Same test, fewer moving parts:
const mail = new MailFixture(); // reads MAILFIXTURE_API_KEY const inbox = await mail.createInbox({ ttlSeconds: 900 }); await page.fill('#email', inbox.address); await page.click('text=Send code'); const otp = await inbox.waitForOtp({ timeout: 30_000 }); // server-side long-poll await page.fill('#otp', otp);
waitForOtp, keep your assertions. If your suite uses MailSlurp's sending features, we're not a replacement at all — MailFixture cannot send email, by design.