PRACTICAL GUIDES ·
Temporary email not receiving messages: a troubleshooting guide
An empty temporary inbox does not tell you why a message is missing. A mistyped address, expired inbox, sender rejection and code extraction failure require different checks. Start with the symptom you can actually observe.
Compare these four facts first
- Exact address: Compare the address shown in the inbox with the address submitted to the form, including its domain. Check that you did not copy an address from an older tab.
- Remaining lifetime: The default gecici.email inbox lifetime is 60 minutes. Once it expires, do not assume that recreating the same custom name restores the old inbox or messages.
- Sender result: Did the application confirm sending, or reject the address? Repeatedly changing the local part may not help when a service does not accept disposable email.
- Message list: A message may have arrived even when the extracted-code field is empty. Inspect the message itself; automatic extraction cannot recognize every format.
Choose the next step from the symptom
| Observed symptom | Next check |
|---|---|
| The form rejects the address | Check the service's address policy. Use an address you can retain for a permanent account. |
| The form says sent, but the inbox is empty | Confirm the exact address and active inbox. Respect the sender's resend interval. |
| A message exists, but no code was extracted | Read the message. This may be an extraction-format issue rather than missing delivery. |
| A code arrives but is rejected | Check that it belongs to the correct application and latest challenge. Application-code expiry and inbox expiry are separate. |
| The inbox expired | Create a new inbox and update the application's destination address. Changing inboxes does not forward messages sent to the old address. |
For developers: distinguish HTTP outcomes
An OTP/link read returning 408 means no extracted result is available yet; retry within a deadline. For 403, check the inbox token and expiry. For 404, check the inbox and route. A 5xx response is not a successful verification.
Use a fresh inbox for each test run to avoid retrieving a code from another challenge. Assert the application's verified state after entering the code. The runnable Playwright example covers wrong codes, verification and replay rejection as separate outcomes.
When is a resend useful?
If the address is correct, the inbox remains active and the sender permits another attempt, request a new verification message. Avoid issuing several challenges at once: receiving a code does not establish which challenge it belongs to.
This guide does not establish acceptance or delivery timing for any third-party platform. Use a persistent address for accounts you intend to keep, payments and future account recovery.
API status and token reference · Inbox lifetime and management