Choose the question your test should answer
“Test email” can mean three different things. Can your account send a message to your mailbox? Can an InboxIt address receive mail? Or does your application’s signup or password-reset flow send the correct message and complete the intended action?
InboxIt’s Testing page separates these into Send an email, Receive an email and Test my app. Start with the question you need to answer. A successful delivery test does not prove that your reset link works, and an incoming message does not prove that your own app sent it correctly.
Check basic sending and receiving first
Use Send an email to send a test to a mailbox you control. If sending is blocked, follow the setup guidance and check your account and sending domain before retrying. Review Logs and the actual recipient mailbox; a successful request alone is insufficient.
Use Receive an email to choose an existing inbox. If you do not have one, follow the Create an inbox link first. Wait until its address is active, then send a message from another mailbox to that address. This checks reception independently of your application. You do not need to connect your application just to receive this test message.
Test a signup in the dashboard
- Open Testing → Test my app and create a temporary inbox for this test.
- Wait for the address to become active, then copy it.
- Use that address in your application’s signup form and submit the signup.
- Return to InboxIt. The dashboard checks for incoming messages while the page is visible; resume checking if it has been paused.
- Open the received email, confirm its sender and subject, and inspect the code or link.
- Complete the action in your test application and verify the resulting account state.
The temporary address is the connection between the two products. Your application sends its normal email to that address. You do not need to replace your application’s sending provider to run a receiving test.
Check more than “an email arrived”
For a signup test, verify the intended recipient, expected sender, subject and environment. A staging signup must not send users to your production confirmation page. For a reset test, verify that the link changes only the intended test account.
InboxIt can extract code and link candidates from received messages. A candidate is not a guarantee of correctness: a message can contain several links, order numbers or other numeric strings. Inspect ambiguous results instead of selecting the first item automatically.
Use accounts and addresses you control. Avoid placing live customer reset links in screenshots, logs or bug reports. Redact tokens when reporting a failure while preserving non-secret identifiers needed to investigate.
Automate without matching an old email
In an API-driven test, create the temporary inbox and wait until it is active. Start a wait before triggering your application’s email. That boundary excludes older messages. Poll the returned run until it matches, times out or is cancelled. This explicit wait is different from the dashboard’s automatic checking.
Use a unique inbox per parallel test where practical. If you use filters, check the exact sender address and the expected subject text. A shared inbox with a broad filter such as “Welcome” can allow one test to read another test’s email.
Keep waits bounded and clean up test inboxes when finished. Expiry removes stored test data, and incoming messages count toward your plan allowance. The testing documentation and temporary-inbox API reference cover the available parameters.
Include failures in your test plan
- No arrival: report a timeout and inspect application logs, sender status and recipient address.
- Expired link: confirm the app explains how to request a new one.
- Used link: confirm the same reset token cannot be used again.
- Repeated request: verify the intended resend policy instead of assuming every email is a duplicate.
- Wrong environment: check the hostname before opening a generated link.
Token lifetime and single use are properties of your application’s authentication flow. OWASP recommends both; receiving the email is only one part of verifying them. For duplicate-send behavior, read how idempotency works.
