How to test registration emails with a temporary inbox

Prepare a safe test and an expected result

Use this guide for a product you own or are authorized to test, preferably in a staging environment with disposable test accounts. TmpMails is a receiving inbox for manual checks; it does not provide an external email-testing API or a delivery-time guarantee.

Write down the expected sender, subject, destination, link hostname and account state after verification. Use synthetic names and data. For example: a pending test account should become verified after opening its latest valid verification link.

Generate an address and trigger one registration email

Open the TmpMails homepage and wait until an address appears. Keep that browser profile and its site data throughout the test.

1. Copy the displayed temporary address into your own product’s sign-up form. Check that the submitted address exactly matches the one in TmpMails.
2. Submit once. Record the submission time and time zone, the test environment and the result shown by the form. A “message sent” notice is not proof of inbox delivery.
3. Keep the inbox tab visible while waiting. It checks for messages every 10 seconds while visible, and you can refresh manually. Do not generate another address or clear the inbox during this test.
4. When the message appears, note the arrival time and open it. The observed time includes the sender’s queue, delivery and inbox polling; it is not a precise SMTP delivery measurement.

Inspect the message and complete verification

Check the actual email against the expected result before clicking. Only open links for the test environment you control.

1. Confirm the visible sender and subject identify your product and the intended action. Check that the greeting and content belong to the correct test account.
2. Read the content in the inbox. Check for missing text, raw HTML, broken formatting and unreadable buttons. This checks the TmpMails viewer only; use separate clients to test Gmail, Outlook and mobile email rendering.
3. Inspect the verification link’s destination. Confirm it uses the expected HTTPS hostname and test environment, and does not accidentally point to localhost or production.
4. Open the link and confirm the expected account state in your application. Refresh the application to check that verification persisted. If your product uses a code instead, enter it and verify the resulting state.

Test resend, duplicate and expired links deliberately

Use a separate test case for each behavior so you can distinguish old and new messages. Respect your application’s resend cooldown.

1. Request one resend after the cooldown. Check whether a second message arrives and whether its content is correct. Do not request codes continuously.
2. Check old versus new links or codes against your product’s documented policy: for example, whether issuing a new token invalidates the previous one.
3. Try using an already consumed link, then an expired link in an environment where you can safely control token expiry. Confirm your application shows a useful result and does not change the wrong account.

Record failures without exposing verification tokens

A useful result looks like: “Staging, 2026-10-13 14:30 UTC+8; expected verification message; form accepted; no inbox message after the observation period; no bounce found.” For a content issue, record expected versus actual wording and a redacted screenshot.

If no message arrives, first use the separate missing-email troubleshooting guide. A blocked disposable domain, sender queue or rejected delivery can occur before anything reaches the inbox. If you control the sender, inspect its delivery logs. Do not include passwords, full verification URLs or codes in public issue reports.

TmpMails does not currently offer attachment downloads, an external testing API or guaranteed mailbox retention. Keep important QA records outside the temporary inbox. Use a permanent mailbox for accounts you need to retain.