Test a Wi-Fi verification email,
not just the code

Break success into three outcomes

Testing email verification for a public Wi-Fi portal doesn’t end when the code arrives. The email appearing in the inbox, the portal accepting the code or link, and the original device getting online are three separate outcomes. The first can succeed while the others fail because a token expired, a session was lost, or the gateway policy blocked access.

Agree on acceptance criteria with the development and operations teams first: how quickly the email should appear, which service event confirms verification, and which controlled HTTPS test page should load after access is granted. Don’t assume you’re online just because the portal says “success”—the page may be cached while the gateway has yet to update access.

Use a separate address and session for each test

Test in a staging environment or on a network you’re authorized to use. Use a fresh address for each independent test case, and record the case ID and device session. Reuse the same address only for related tests such as resending or clicking a link more than once. Never use real guest email addresses, room numbers, booking details, or identity documents as test data.

Open the Tmpkey temporary inbox and confirm it shows an actual address and countdown, not two demo emails. Keep the inbox credentials in the same browser; opening another browser won’t restore the original inbox. If the portal blocks access to the inbox page, first make sure you have a working mobile data connection. See How to open an anonymous inbox before getting online to tell a network block from a delivery issue.

Build a matrix, then test combinations

Establish a baseline with one normal flow, then change one variable at a time. Record the device OS and version, browser, network access status, and verification method. If you change the address, device, and browser all at once after a failure, you won’t be able to isolate the cause.

Build on this baseline with the iOS, Android, and desktop versions commonly used by your audience. Private browsing, disabled storage, and language changes can be added as optional cases. Define the supported scope with the product team instead of testing every possible combination.

Record three timestamps for delivery

Record T0: code request submitted; T1: portal service accepts the request; T2: email first appears in the inbox. T1−T0 covers frontend and request processing; T2−T1 covers queuing, transmission, and inbox display. Don’t lump both together as “the mail server is slow.” An API success response doesn’t mean the email has been delivered.

Synchronize client and server time zones and clocks, and use request IDs to correlate logs where possible. Inbox polling can make the first visible time later than the actual arrival time, so label T2 as an “observed in UI” time. If you have access, check delivery logs for the actual arrival time; don’t use the email’s Date field as a substitute.

Repeat the test over multiple runs and record the median, slow deliveries, and failure rate. Set thresholds based on the portal’s commitments and code lifetime, rather than using one fixed time limit for every network.

Check the message, not just the six digits

The subject should match the purpose of the email, and the sender address should use an expected domain. A matching display name doesn’t prove the message is from the expected source. Checking SPF, DKIM, and DMARC requires the full email headers or delivery logs—not just a sender badge.

• HTML: After remote images are disabled, the code, expiry time, and security guidance should still be readable. The layout should fit narrow screens without horizontal scrolling, with sufficient contrast in both light and dark modes.
• Plain text: Codes and links should be intact, with no leftover tags. Line breaks must not split codes, and copying should not introduce invisible characters.
• Consistent content: Both versions should have the same purpose, codes, and expiry details. Translated messages must not contain instructions in another language.

A temporary inbox can help you check how a message displays, but it may not expose the original MIME or let you switch between message formats. To confirm both versions were sent, check your own sending logs, the original email, or a controlled test client. Don’t assume a plain-text version exists just because the page looks right.

Follow the verification link back to the original session

Check the actual destination URL, not just the button text. The link should use the expected HTTPS domain, redirect only to authorized sites, and avoid unnecessary personal data in its parameters. Test the full redirect chain with a synthetic account, and keep only redacted paths and status codes in logs.

Test the same-device and cross-device flows separately

A link opened in a full browser after being requested in the system sign-in pop-up may land in a different cookie session. Opening a verification link on a phone after requesting it on a computer also raises device-binding questions. First clarify what the link verifies: the email address, the current browser, or the original gateway session. Rejecting a different device may be the correct behavior, but users should be told how to return to the original device to enter the code or request another.

Test opening the link more than once, too. Make sure it can’t authorize unrelated devices again and that a consumed token returns a clear status. Don’t disable device binding or weaken redirect checks just to make the test pass.

Resend the code, then test out-of-order delivery

Submit two requests in a row, label them A and B by request ID, then try both the old and new codes. Don’t assume the order in the inbox shows which code is newer: queue delays can make A arrive after B. If only the latest code should work, make sure the interface, server-side validation, and email instructions all say so. Document any other policy just as clearly.

In a controlled environment, test duplicate submissions, rate limits, and recovery after the cooldown ends. Rate limits must be enforced server-side; disabling a button isn’t enough. A network timeout also doesn’t prove that no request was sent—the backend may have accepted it. Record what actually happened, and avoid repeated retries that could trigger abuse protections on a real network.

Test email expiry and portal token expiry separately

Tmpkey temporary email addresses are valid for 3 hours by default. The portal sets the lifetime of its verification code or link separately. An email address can have two hours left while a token sent minutes ago has already expired; extending the inbox does not renew the portal token.

At minimum, create two test cases: the email address is still valid but the token has expired, so verification should be rejected and a new token can be requested; the email address has expired but the portal token is still within its stated lifetime, so check the portal’s own policy rather than assuming an expired address revokes an issued token. Also test the token’s expiry boundary, reuse, and server-side time checks.

Use shortened TTL settings only in an isolated test environment, and document how they differ from production. Observe the actual expiry and deletion behavior of temporary inboxes separately; changing a phone’s clock does not make the server expire an address.

Extend an inbox to keep its address; replace it to close it

Each extension adds 3 hours. An inbox can remain active for up to 24 hours from creation; the expiry time returned by the service is authoritative. Check that the address stays the same, existing messages remain available, and the countdown updates. Near the maximum lifetime, don’t expect another full 3-hour extension.

Replacing an address creates a new inbox with the default 3-hour lifetime and destroys the old one. Finish the current test and save any necessary redacted evidence before replacing it. Don’t switch addresses while waiting for an email and then report the old inbox’s silence as a delivery failure. The new address won’t automatically update the recipient address already saved in the portal.

Keep evidence reproducible—but unusable for sign-in

For each record, include the test case ID, environment and build, device and browser versions, network status, verification method, redacted address, request ID, three timestamps, and expected and actual results. Mark “email received,” “verified,” and “access granted” separately instead of recording only pass or fail.

If you need to correlate the same address, use a test-case alias or controlled hash instead of keeping full credentials. Deleting a test inbox won’t remove screenshots in tickets, downloaded files, or copies in external systems; clean those up separately.

A temporary inbox is not a delivery coverage report

One successful delivery proves only what happened at that time, on that route, and for that receiving domain. It says nothing about spam filtering, reputation policies, or inbox display in Gmail, Outlook, or business email providers. Before launch, test with real email accounts you’re authorized to use, check results across providers, and monitor production delivery, bounces, and verification conversions.

If the portal explicitly rejects disposable addresses, record that as an address acceptance policy instead of bypassing it. Don’t use an address that will be deleted for identity checks, payment notices, accommodation changes, account recovery, or ongoing support. An anonymous inbox also doesn’t hide your network origin or replace security auditing.

Next: receive the email, then decide whether to keep the address

For short-term testing, use a dedicated address to run the full flow. For regression tests across multiple days, consider a stable forwarding alias that sends incoming mail to your own inbox, with its settings and recent 30-day archive managed separately. Forwarding adds another link in the chain, so don’t compare its latency directly with temporary inbox results.

For step-by-step instructions on using a portal, see our Wi-Fi email guide for hotels, airports, and cafés; for details on how data is handled, see our Privacy Policy.