Testing signup and verification flows
Use the temporary address as the test user's email. Submit your registration form, then watch this tab for the confirmation or verification message. You see the same content a real user would receive, which is enough to check that the mail fires, the link resolves, and the code is correct.
Because each address is fresh, you can run the flow repeatedly without an inbox filling up or old messages confusing the result. When you are done, the mailbox expires on its own — no cleanup step.
What it is good for, and what it is not
It is well suited to quick manual checks: does the welcome email send, does the reset link work, does the OTP arrive. It receives real SMTP mail, so it reflects true delivery for that message.
It is not built for automated test suites or programmatic assertions — there is no API here, no long retention, and the five-minute lifetime is short for slow pipelines. For CI, a testing-focused mailbox service with an API is the right tool. For a fast manual check, this inbox is quicker.
Practical tips
Trigger the email only after the address appears on this page, so it is not sent before the mailbox exists. If your app queues mail, keep the send window under five minutes or generate a fresh address right before triggering.
Remember the inbox is public and short-lived. Use throwaway test data, not real customer records, and never point production password resets at a disposable address.