Test signup emails with a temporary inbox

Set up a small, repeatable test

A disposable inbox is useful for a manual smoke test of an application you control. Each new address separates a test from your personal inbox. It is not a replacement for an email provider’s delivery logs, a staging mail catcher, or testing across real email clients.

1. Open InboxForNow, wait for the inbox to connect, and copy the generated address. Do not invent an address on the receiving domain: only created, unexpired inboxes can receive messages.
2. Use your application’s staging environment and a synthetic test user. Send from a provider and domain you control. Remove real personal information, production credentials, and payment details from the fixture.
3. Give the message a unique subject, for example signup-smoke-01. Record the recipient and send time so you can match the provider event with the inbox message.
4. Keep this tab open. Extend the initial 10-minute timer before expiry if your queue takes longer. Reloading this tab reconnects to the same active inbox when browser session storage is available; it does not reset the timer. New address deliberately selects a different mailbox.

Begin with a plain, readable fixture

Send both a plain-text body and a small HTML body through your own application’s normal mail path. A text code and one link are enough to distinguish a delivery problem from a template problem.

<p>Verification code: 418229</p>
<p><a href="https://example.com/verify?token=TEST_ONLY">Verify your test account</a></p>

Replace the example link with a staging verification URL that you control. The code and token above are sample data, not credentials. Check that the code displayed in the message matches the code your application expects; automatic code detection is a convenience and can choose the wrong number in a complex message.

Download three tested email examples

These small .eml files contain synthetic messages in standard email format. Use them to compare plain text, HTML alternatives and content this inbox removes. Each includes the sample code 418229 and a distinct subject so you can identify the case.

Before sending: replace [email protected] with the exact live inbox address. Use your own verified sender and replace example links with your staging URL. Your sending tool must also set the envelope recipient; editing the To header alone does not route an email. Send through your own application's mail path, or import the files into a local mail catcher. InboxForNow has no file-upload or outbound-send feature.

<p>Verification code: 418229
Synthetic user: &lt;test-user&gt;
</p>

<p>Verification code: 418229</p>
<p><a href="/r?u=https%3A%2F%2Fexample.com%2Fverify%3Ftoken%3DTEST_ONLY" rel="noopener noreferrer nofollow">Verify your test account</a></p>

<p>Verification code: <strong>418229</strong></p>



<p>Read this without images.</p>

What we verified

On October 13, 2026, each exact download was processed by InboxForNow's receiving handler using its MIME parser and a local test database, then retrieved through the message API. All three matched the code, subject, processed HTML and message preview documented in the expected results. The rendering case includes a real MIME attachment with synthetic text; that text was absent from both the stored message and API response.

You can reproduce the checks from the fixture test source:

npm ci --prefix workers/inboxfornow-api
npm run test:mail-fixtures

These are local processing results. They do not test SMTP delivery, sender authentication, inbox placement, latency, or how Gmail, Outlook and other clients render the message. The example link and sample code do not verify a real account.

Go beyond receiving the message

A message arriving does not prove that signup or password reset works. Our original local teaching application and journey tests connect a loopback HTTP account flow to InboxForNow’s actual receiving handler and message-retrieval API, using a local test database. All accounts and messages are synthetic.

From a checkout of this repository, run the same npm run test:mail-fixtures command above. On October 16, 2026, the three journey cases passed alongside the three MIME fixture cases:

Each response gives the test a request identifier; the email subject carries that identifier. Retrieval matches the exact subject in the correct inbox, then checks the processed link’s destination origin and action path before using its token. The final assertion checks account identity, not just a successful message fetch.

The local application calls the receiving handler directly. These tests do not send SMTP mail, exercise the production website’s browser UI, measure delivery speed or establish a public automation API contract. The teaching application is not a production authentication service. When testing your own application, use its staging flow and normal sending provider, and assert its actual resend, expiry and one-time-use rules.

A manual signup email QA checklist

Tick each item as you test. These checkboxes are local to this page and reset when it reloads.

• Recipient: the email goes to the exact live address copied from this session.
• Identity: the sender name, subject, and message purpose are understandable without images.
• Code: the visible code matches the expected test value and can be entered in your app.
• Link: the expected link reaches your staging domain and completes the intended action.
• Resend: a second request produces the expected message, and your application handles old and new tokens according to its own policy.
• Repeat click: using a consumed verification token produces a clear result instead of silently creating an inconsistent account state.
• Expiry: an expired verification token receives a clear message and a path to request another one.
• Failure: a rejected or suppressed recipient produces an actionable result in your app and an identifiable provider event.

Token expiry and inbox expiry are different. Your application controls its verification token; InboxForNow controls access to the temporary mailbox. Use a fresh inbox for each independent run.

Know what this inbox intentionally removes

This is a functional receiving test, not a full email-design preview. Test responsive layouts, accessibility, dark mode, attachment support, and client-specific CSS in the mail clients your users actually use.

Keep a small test record

Record the application version, environment, recipient, subject, request time, provider event, inbox arrival observation, and pass/fail result. Save only synthetic test evidence before expiry, then delete the test inbox when finished. Do not use a temporary inbox as a log archive.

If a message does not arrive, use the delivery troubleshooting guide to separate address rejection, sender queues, expired sessions, and browser retrieval errors.

The service behavior in this guide was reviewed against the receiving code and automated tests on October 11, 2026; the downloadable examples were added and tested on October 13. Those tests cover mailbox lifetime, sanitization, code extraction, link rewriting, and cleanup in a controlled test environment. They do not establish real-world delivery latency, inbox placement, or third-party signup compatibility.