Email flows fail in quiet ways. The app says "check your inbox," but the message goes to spam, the link is malformed, the template is unreadable on mobile, or the token expires before a real user can act. Testing needs to cover more than "did our mail API return 200?"
Test at three layers
- Application logic: token creation, expiry, one-time use and rate limits.
- Delivery: provider response, bounce handling, SPF/DKIM/DMARC alignment and spam placement.
- Message experience: subject, preview text, plain-text fallback, HTML rendering, links and accessibility.
Manual external inbox test
- Generate a fresh address.
- Run the signup or reset flow as a new user.
- Confirm the message arrives without refreshing.
- Open links in a clean session.
- Repeat with an expired token and a reused token.
A temporary inbox is helpful for this because every run starts clean and external. For automated CI, use a dedicated mail catcher or testing provider with an API.
Release checklist
- Links use HTTPS and the expected host.
- Tokens are not logged in analytics URLs.
- Plain-text content works without images.
- Expiration copy matches server behavior.
- Support instructions do not ask users to forward secrets.
Useful adjacent tools
Use the JWT decoder for development tokens, the URL encoder for callback parameters and the JSON formatter for webhook payloads.
Questions
Should automated tests rely on a public temporary inbox?
No. Use a mail testing service or local mail catcher for CI. Public temporary inboxes are better for manual checks.
What is the most common missed check?
Teams often test delivery but forget token reuse, mobile readability and plain-text fallback.