Somewhere in your test suite there is a sign-up flow that has never been tested with a real inbox. The confirmation email is sent, the test passes because the API returned 200, and nobody checks whether the link works, whether the message renders, or whether it lands in spam.
Test accounts should not live in your personal inbox. But the obvious fix — point everything at a disposable address — is only half right. Here is when a temp inbox helps, when a local mail sink is better, and how not to trip your own blocklist.
Start with what you are testing
The right tool follows from the question:
| Question | Best tool |
|---|---|
| Does the confirmation email render and link correctly? | Local mail sink (Mailpit, MailHog) |
| Does delivery work through a real provider and real DNS? | Disposable inbox |
| Does the flow work on a phone, with a real user's timing? | Disposable inbox |
| Can I inspect raw headers and attachments? | Local mail sink |
| Will a disposable domain be accepted by my sign-up form? | Depends on your own blocklist |
When a disposable inbox is the right call
- End-to-end checks. You want to see what actually arrives over the internet, not what your local SMTP server received.
- Deliverability smoke tests. Send from your production provider to a disposable address and confirm it does not land in spam or get dropped.
- Mobile testing. A temp inbox is one tap on a phone; a local sink requires a tunnel and a config change.
- Manual QA. A tester can generate an address, complete the flow, and read the mail without touching a shared test account.
When a local sink is better
If you are asserting on message content, a local sink is faster and more reliable. Mailpit or MailHog gives you an API, raw MIME, attachment inspection, and no rate limits. You can run a hundred sign-ups in a loop without worrying about a provider throttling you or a domain being blocked.
The trade-off is that a local sink bypasses the real delivery path. It will not tell you that your SPF record is wrong, that your sending domain is on a blocklist, or that Gmail is filing your confirmation email under Promotions.
Use both, in this order
- Local sink for logic. Assert the link, the token, the expiry, and the rendered HTML. This is the fast loop you run on every commit.
- Disposable inbox for delivery. Run the same flow against staging with a real provider and a temp address. Check inbox placement, link rewriting, and mobile rendering.
- Real mailbox for the final check. Once per release, use an address on Gmail, Outlook, and one corporate domain. That is where the weird client-specific bugs live.
Do not block your own tests
If your product blocks disposable domains — and many do — your own QA will fail before it starts. Two options:
- Allowlist your test domains in staging. Keep the production blocklist intact, but let your test environment accept the addresses your testers use.
- Use a dedicated test domain. A subdomain you control, routed to a sink, is cleaner than weakening the production rule.
Never disable the blocklist globally to make a test pass. That is how a temporary QA shortcut becomes a permanent hole.
Things that break in real inboxes
These are the failures a local sink will never show you:
- Link rewriting. Email security gateways rewrite every URL. Your magic link may arrive wrapped and broken.
- Image blocking. The logo disappears, and the layout collapses around it.
- Dark mode. A white card on a white background becomes a white rectangle.
- Long codes. A six-digit code is fine; a 64-character token wraps and looks like a broken link.
- Expiry timing. A code that expires in ten minutes is unusable if delivery takes four.
- Spam placement. Authentication failures, a new sending domain, or a trigger word can send a transactional email to spam.
A small checklist for the next release
- Confirmation link opens the right environment and logs the user in once.
- Code expires exactly when the UI says it does.
- Resend works, and is rate-limited.
- Message renders at 320px wide with images blocked.
- Plain-text alternative exists and contains the same link.
- Unsubscribe and preferences links work for marketing mail, not just transactional.
- The address can be changed after sign-up.
Testing email is unglamorous and almost always skipped. The teams that do it catch the failures users never report — they just leave. If you need a real inbox for the delivery pass, generate one here; for the logic pass, keep the local sink. And if you are wondering whether your own use of disposable addresses is fair, this piece on trials draws the line.