How InboxDome compares

This page compares approaches, not vendors. We do not publish other companies' prices, quotas or feature lists, because those change without notice and a stale table on our site would be worse than no table at all. What follows is a comparison of the four broad ways to test the email your application sends, including ours, and it is candid about where ours is the wrong tool.

The four ways to test email

Approach	What it proves	What it cannot prove
Local or self-hosted SMTP captureA fake SMTP server your app points at instead of a real one. MailHog and Mailpit are self-hosted catchers of this kind; Ethereal is a hosted fake SMTP service.	That your code built a message and tried to send it. Subject, body, headers, recipients, template rendering. It is fast, it costs nothing, and it works with no network at all.	That any mail leaves your infrastructure. That a receiving server would accept it. SPF, DKIM or DMARC results. Anything about your real sending domain, your provider, or the delivery path, because none of them are involved.
A real mailbox you own, polled over IMAPA mailbox on a provider, with credentials in your test runner.	Almost everything. The message really crossed the internet, a real server accepted it, and you can read the authentication results the provider recorded. This is the most faithful option available.	Little, in principle. The cost is operational rather than logical: credentials in CI, polling loops, provider throttling, no isolation between parallel runs, no automatic cleanup, and one shared address that tests collide on.
A shared disposable inboxA public throwaway address you open in a browser. Our own free consumer inbox belongs in this category.	That mail genuinely arrived at a real mail server over the public internet, and that a person can read it. Good for a quick manual check.	Anything a test suite needs to assert on, unless the service also exposes an API. The category itself promises no isolation, no stable address, and no retention long enough to debug a failure the next morning.
InboxDomeAddresses created on demand from an API, receiving on a real MX.	That the mail your app sent was actually delivered over the public internet to a server you did not have to run. SPF, DKIM and DMARC as the receiving server evaluated them. The exact code or link a recipient would get, and whether that link resolves.	Anything about mail you never sent, because we only receive. Anything at all if your build machine has no outbound network. Anything about a mailbox we do not host.

Why a local catcher cannot tell you the mail arrives

This is the distinction the whole page turns on, so it is worth being precise about it.

A local SMTP catcher sits between your application and the internet. Your app opens a connection to localhost, hands over a message, and the catcher stores it. That is genuinely useful. It is fast, it works offline, and it proves your code assembled the right message and attempted to send it.

But consider what never happens. No DNS is resolved. No MX record is consulted. No message crosses a network you do not control. No receiving server ever decides whether to accept it. And because SPF, DKIM and DMARC are evaluated by the receiver, against DNS records for your sending domain, using the envelope and headers exactly as they arrived, a component that never receives anything cannot evaluate them. A catcher can prove your app tried. It can never prove the mail worked.

Failures a catcher will happily report as green:

A DKIM key that was rotated out of DNS and never replaced.
An SPF record that was never updated to include the provider you migrated to.
A DMARC policy of reject that is quietly binning your mail at the recipient.
A sending subdomain that has no MX or no reverse DNS.
A provider that accepted your API call and then suppressed the send.

InboxDome receives on a real MX over the public internet. Your mail takes the same path it takes to a customer: DNS, TLS, an SMTP conversation with a server you do not own. What the API hands back is what actually arrived. That is why we can offer an authassertion for spf, dkim and dmarc: we are the receiving server, so we have the results first-hand rather than inferring them.

When InboxDome is the wrong choice

There are four situations where you should not use us, and one where you should think twice. We would rather say so here than have you find out during an integration.

Your CI is offline or air-gapped. If the build machine cannot reach the public internet, we are unreachable by definition. Self-host a catcher on the same network and accept what it can and cannot prove.
You need to send email. InboxDome is receive-only. That is deliberate and permanent: a service that could send on your behalf is an open relay and a spam problem. Sending is the job of an email provider or your own SMTP, and it always will be.
Compliance requires mail to stay on your own infrastructure. If policy says test data cannot leave your estate, then no hosted receiver qualifies, ours included. Self-host, and do not let anyone tell you otherwise.
You want to inspect mail already sitting in a production mailbox. We host inboxes; we cannot read someone else's. Point an IMAP client at that mailbox instead.
You need messages to persist for weeks. Retention here is short on purpose. See the limitations below and the retention policy before you build a workflow that assumes otherwise.

What InboxDome is genuinely for

One thing: proving that the email your application sends actually arrives, and that its contents are correct, without you running a mail server. Concretely, that means:

Real inbound delivery. A passing test means the message reached a real receiving server, not that a mock accepted it.
Disposable, isolated addresses. Create one per test from the API. No shared mailbox for parallel runs to fight over, and no cleanup to write.
OTP and link extraction. Read the verification code or the reset link out of the message, rather than maintaining a regular expression against your own template. Seetesting a password-reset email.
Assertions on the message as received:otpPresent,containsText, auth (spf, dkim ordmarc), and linkResponds.
Webhooks. A message.received event, signed with a hex HMAC-SHA256 in the X-InboxDome-Signature header, so you verify it before you trust it. See testing email webhooks.
CI and test runners.Playwright,Cypress, Node,Python, PHP, andGitHub Actions.
AI agents. An MCP server, so an agent can create an inbox and read the mail it caused to be sent.
WordPress and WooCommerce. A plugin for checking thatsite mail andorder emails actually leave the site.
Bring your own domain. Verify a domain you own with a TXT record and receive on it, so test addresses read as your brand rather than ours. Seebring-your-own-domain testing.

The free tier is 30 requests per minute, 50 inboxes per day and 1 webhook endpoint, with no card. That is enough to run a real suite. Register a key and find out in ten minutes whether this fits.

Honest limitations

All of the following are true today. If any of them is a dealbreaker, better that you know now.

Limitation	What it means in practice
Receive-only	We cannot send email, and we do not intend to. InboxDome is not an SMTP relay and not an email provider.
Short retention	Consumer inboxes delete themselves after 24 hours, extendable to at most 7 days. This is a feature for a temporary inbox and a limitation for an archive. Full detail on theretention page.
Your own domain needs us in the loop	Ownership verification is automatic through a TXT record, but activating mail routing still requires a human on our side. Usually within one business day. Plan the first setup accordingly.
Attachments are not scanned	Risky and mismatched file types are quarantined by policy, but there is no virus or malware scanning today. Treat every attachment as untrusted. Seesecurity.
Paid plans are not purchasable	Pro and Scale exist in the API as rate-limit tiers, but billing is not live. Only the free tier is self-serve. See pricing.

The honest recommendation

Most teams should use two of these, not one. Keep a local catcher for the fast, offline, unit-level pass that runs on every save: it is the right tool for checking that a template renders and that the send was attempted. Then use InboxDome for the test a catcher structurally cannot perform, which is the one that asks whether the mail actually arrives and whether it authenticates. Those two questions are different, and only one of them can be answered without a real delivery path.

If your situation does not fit any of this, tell us. We would rather point you at the right tool than sell you the wrong one. More on the approach in theblog.