Temp Mail Not Receiving Emails: Diagnose an Empty Inbox in Four Layers

An empty temporary inbox can come from four layers: the address you submitted, the address’s remaining lifetime, the sending site’s handling of your mail, and the service behind the mailbox. An empty inbox cannot tell you which one failed. One observation does most of the separating: before you generate anything new, send an email from a personal account to the same temp address. If it arrives, the mailbox works and the sending site is the variable. If it doesn’t, the mailbox or its state is the variable. The sections below turn that observation into an ordered procedure.

What an empty inbox does and doesn’t prove

An empty inbox shows one thing: no mail has arrived in the mailbox you are watching, at this moment. It does not show whether the site sent anything, whether the service received it, or whether you are looking at the right tab.

Repeated silence is not evidence of a block. Two failed attempts at the same site are two observations without a control. The mail may never have been sent, may have gone to a slightly different address, may have arrived after your address expired, or may have been filtered, and the inbox cannot distinguish these cases. Treating “no code arrived twice” as proof of a blocking policy is a common reasoning error in this space.

A negative split test is weaker than it looks, because three different layers can produce it.

Some ground rules apply throughout. This guide does not describe undocumented spam-folder behavior, promise arrival times, claim that an expired mailbox can be recovered, or offer bypass methods. Every lifetime figure is attributed to the provider whose own page states it.

The decision tree

Rule 0: record first, regenerate second. A new address only helps if you keep the evidence from the old one. Note the exact address you submitted and the time you submitted it, because if the original address is discarded or expires, there is nothing left to test — and a retry on a fresh address tells you less than a controlled test on the one that failed.

Node 1: check address fidelity. Compare the address you gave the site, character by character, with the address your temp mail page currently shows. A trailing space, an autocomplete entry, a copy from a screenshot, or a paste into the wrong field can produce a submission that looks correct but went to an address that isn’t yours. If the strings differ, fix the copy and resubmit. A message such as “check your inbox” confirms the form was accepted, not that mail was delivered.

Node 2: run the split test. Send an email to the temp address from a personal account and wait a reasonable interval. If it arrives, the mailbox and service work, and the original sender becomes the variable. That result proves only that the mailbox functions. It says nothing about what the other site did. If the test mail does not arrive, go to Node 3.

Node 3: check the clock. Compare elapsed time with your provider’s documented lifetime (see Layer 2). If the window has passed, the address is gone and you need a fresh one. If you are still inside the window, go to Node 4.

Node 4: run one tagged retry. Generate a single new address with a descriptive tag, repeat the split test, and record the exact address and time. If a fresh, unexpired, correctly copied address still fails, you have reached the limit of what outside observation can distinguish. Go to the service-layer section below and read the provider’s own documentation instead of retrying blindly.

Observation	Layer the evidence points to	Next action	Residual uncertainty
Personal-account email to the same address arrives	Mailbox works; sender-site behavior is the variable	Use the mailbox elsewhere. Treat the original site as unknown unless it states a rule	Low. Arrival is a strong positive. Silence from the site is not a policy
Test mail doesn’t arrive; documented window has passed	Expiry	Generate a fresh address, then repeat the split test with the new address logged	Low when the lifetime is documented; unknown if the provider states none
Test mail doesn’t arrive; window not passed; submitted address matches exactly	Undetermined: reader-side or service-side	One fresh tagged address, then repeat the split test	Medium. A fresh address that passes implicates the old address or its state, not the sender
Generated address differs from what you typed (tag altered, character dropped)	The address itself	Submit the returned email value, not the pattern you intended	Sources describe tags differently; verify each generation
No split test has been run	Nothing is distinguishable yet	Run the split test first	High. Without a control observation, no layer can be named

Layer 1: the address itself

Diagnose this layer by reading, not regenerating. Because it is cheap to check and easy to destroy, it comes first.

Start with the simplest explanation: the string you submitted differs from the string you generated. Look for a trailing space, an autocomplete entry that substituted a saved address, or a paste into a field that already held text. Compare them character by character.

Next, confirm you are watching the right inbox. Several open tabs can each hold a different address. A tab showing one address while you wait for mail sent to another looks exactly like a broken service.

Tempmail’s documented address format is {namespace}.{tag}@inbox.testmail.app, generated in one click with no account or sign-up. The Tempmail docs recommend prefixing tags, such as signup.flow or otp.test, “so later tests are easy to filter.” The API reference lists the tag parameter’s valid characters as a–z, 0–9 and hyphens. The two documents describe tags a little differently — the docs show dotted examples, the API reference restricts the parameter to letters, digits and hyphens — so the practical rule is to read the address the service actually returns and submit that value.

Layer 2: expiry

Expiry rules belong to each provider, and the figures are not interchangeable. Identify whose rule applies before you interpret a timeout.

• temp-mail.io (its page): an address is valid for 10 minutes for non-premium users and 1 hour for premium users. Premium users can keep an address “for up to 30 days.” The page also says an address that “will not receive messages some time — it will be removed.” This applies to temp-mail.io only.
• Internxt (its temporary email page): the “Email address and inbox will expire after 3 hours of inactivity.” This applies to Internxt only.
• Tempmail: the sources checked document no lifetime. Where a lifetime matters, confirm it on the provider’s own page rather than borrowing another provider’s figure.

The two named providers use different triggers. temp-mail.io’s removal rule is tied to the address not receiving messages, while Internxt’s is tied to inactivity. Both produce an empty inbox, but they are not the same failure.

If your provider shows a countdown and it has reached zero, the address is gone. None of the sources document recovery of an expired inbox, so treat expiry as permanent and generate a fresh address before resubmitting.

Layer 3: sender-side rejection

This layer is easy to over-claim, so the evidence bar is high. The only sender-side evidence worth acting on is an explicit message from the site that names the refusal.

A Reddit user reports that LALAL.AI rejected a disposable address with the on-screen message “Please enter your permanent email address, not a disposable one.” Commenters in the same thread describe services detecting disposable domains through blocklists, citing an example labeled “Blocked by Greip” (thread). This is one user’s account of one site. It is not a documented sender policy, and it gives no block rate.

Silence after submitting, two failed attempts, and one site’s behavior generalized to another are not evidence of a sender policy. A third-party troubleshooting article, iLoveTempMail, supplies the split-test framing used here: “Have you received emails from other senders to this same mailbox? If yes, the problem is sender-side. If no, the problem may be with the mailbox itself.” It also calls generating a new mailbox on a different domain “the single most effective fix.” Adopt the test. Treat the ranking as one writer’s advice, since the article reports no measured results.

If the split test arrives and the site’s mail doesn’t, the defensible conclusion is that the mailbox works and the site’s handling is unknown unless the site says otherwise. “I was blocked” is not a conclusion the evidence supports. If a site explicitly states that it does not accept disposable addresses, this guide offers no workaround. Use a permanent address or an alias you control.

Layer 4: the service

If the split test fails on a fresh, unexpired, correctly copied address, the remaining causes lie beyond what you can observe from the browser: service availability, filtering, or something similar. Nothing in the sources lets you distinguish these from the outside, so a fifth retry adds no information. Go to the provider’s own documents instead. For Tempmail, that is the docs (setup, configuration, deployment) and the API reference (endpoints and response contracts). If you run your own deployment, the self-host branch below lists the checks that are actually within your control.

Worked example: tag each attempt

After three attempts with one reused address, a message that finally arrives can’t be attributed to a specific attempt. You end up reading stale state and calling it progress. Tagging each attempt prevents this.

Tempmail generates {namespace}.{tag}@inbox.testmail.app in one click. Its docs recommend prefixed tags, illustrating them as signup.flow and otp.test, while the API reference restricts the tag parameter to a–z, 0–9 and hyphens. Use the hyphenated form for anything you generate through the API, and always submit the email value the call returns.

Attempt 1 (signup): tag signup-flow. The address takes the pattern {namespace}.signup-flow@inbox.testmail.app; in the API example the namespace is demo, but read your own namespace from the returned address, and treat any specific address here as an illustration rather than a verified output. Submit it and log the address and time.

Attempt 2 (OTP retest): tag otp-test. Any message arriving at the otp-test address belongs to this attempt; a message at the signup-flow address belongs to the earlier one. You don’t need to infer this from timestamps.

Verify each attempt. A tag input in the web UI is a different surface from the API’s tag parameter. If a dot is rejected there or generation fails, the hyphenated tag is the documented-safe option. Either way, submit the returned email value rather than the pattern you intended.

Keep discipline. Change one thing per attempt and keep a one-line log of attempt, tag and time. This applies to Tempmail specifically. Don’t assume other providers accept tags.

Self-host branch

This section applies only to people running their own deployment. It draws on the Tempmail docs and API reference.

Check that the frontend reaches the backend. Local development runs the FastAPI backend with python run.py on http://localhost:8000, with swagger at /docs. The Vite frontend runs with pnpm dev on http://localhost:5173, and VITE_API_URL=http://localhost:8000 points it at a local backend. A frontend pointed at the wrong URL will likely show an empty inbox that has nothing to do with mail flow.

Test generation directly. POST /api/emails/generate returns 201 with email, tag and namespace. The documented example is demo.qa-trial@inbox.testmail.app. The tag query parameter is optional and defaults to a random 6-character tag. A 201 confirms only that your backend provisions addresses; it says nothing about whether inbound mail reaches the address, and the docs do not state that this call validates API_KEY or NAMESPACE. If generation succeeds but the UI stays empty, check those two values against testmail.app before concluding anything about delivery.

Check the configuration. The documented Heroku setup uses API_KEY and NAMESPACE (both from testmail.app) and sets CORS_ORIGINS to the frontend origin. Confirm that CORS_ORIGINS matches the frontend’s actual origin, since that variable governs browser requests generally. The docs define each variable’s role but do not describe the exact browser symptom a mismatch produces.

Rule out a sleeping dyno. The docs warn that the Eco tier “sleeps after 30 minutes idle,” that all Eco dynos share one pool of hours, and that Basic is the smallest always-on tier. Eliminate an idle, unresponsive deployment before you debug mail.

Watch for mock mail. The docs state that without API keys, the backend serves mock emails when demo mode is enabled. Setting DEBUG=true and ALLOW_DEMO_MODE=true, either as environment variables or in backend/.env, yields “sample emails with no external account.” With demo mode on, whatever the inbox displays may be sample output rather than mail delivered from outside, so it is evidence about deliverability in neither direction. The docs do not say how this mode treats real inbound mail. Describe what you see as “sample mail,” not “real mail is blocked.”

Limits of this section. The excerpt reviewed does not document a health endpoint or delivery logs, and while the API reference’s introduction advertises OTP extraction and live event streams, it does not detail them in the portion reviewed. Verification therefore stops at swagger availability, a 201 from /generate, the API_KEY/NAMESPACE/CORS_ORIGINS check, and eliminating a sleeping dyno.

Recovery accounts

Accounts you may need to recover, such as banking, government, or anything that might send a password reset next year, are the wrong use for a disposable address, whatever today’s diagnosis shows. Since nothing in the sources documents recovering mail from an expired inbox, a missed message in an expired address should be treated as permanent loss. Use a permanent address or an alias you control for those accounts. Keep disposable mail for throwaway verification and repeated testing, where each tagged attempt stays attributable.