A limited testing window
3 → 24 hours
Addresses last 3 hours by default and can be extended up to 24 hours per inbox. After that, the address and emails are deleted—not kept as a long-term backup.
See temporary email data boundariesPrivacy Policy · Data Boundaries
Test Addresses, Email Content &
Access Token Data Boundaries
No sign-up means one less step: creating an account. Receiving verification codes, previewing templates, and forwarding email still involves processing the data needed for those tasks. This page explains why we use it, how long we retain it, and how you can end a testing session.
Accounts and records are managed separately
30 days of archived records
Your login email verifies your identity and receives forwarded messages. Disabling an alias, deleting archived records, and logging out each have different effects.
See forwarding data boundariesAccess tokens grant access
token Do not share
Local credentials let you restore your inbox and login status. Clearing browser data may remove your access, but does not delete data on our servers.
See what’s stored locally01 · Start with the purpose
One website, three distinct data uses
This policy covers Tempcase’s disposable verification email, email template previews, long-term forwarding, and related website access. Temporary inboxes don’t require sign-up, but the service still needs to process your address, access token, and incoming emails to show them to you. No sign-up doesn’t mean no data processing or complete anonymity.
Long-term forwarding requires a real login email to verify your identity and link your aliases to your inbox. Website visits also involve network request data. To provide the service, protect it, and troubleshoot issues, we may process your IP address, request time, browser information, and pages visited.
| Use case | Information involved | Main purpose and limits |
|---|---|---|
| Temporary verification email | Random address, access token, expiry time, sender, subject, and email content. | Receive emails, verify access, display messages and time remaining. No login email is required upfront. |
| Email template preview | HTML or plain-text content delivered to a temporary address, including references to resources in the message. | Preview an actual incoming email—not a separate permanent template library. The inbox’s expiry time still applies. |
| Long-term forwarding account | Login email, verification details, alias mappings, forwarding status, and archived records. | Verify your identity, forward alias emails to your real inbox, and let you view and manage records from the last 30 days. |
| Website access | Connection and request data, browser-stored credentials, and essential service status information. | Keep the service running, protect it, and restore your session. Browser-stored data and server records are separate. |
The Netflix and Uber emails marked “Demo” on the homepage are examples created by Tempcase. They aren’t messages from your real accounts, and don’t imply any affiliation with those brands. For actual testing, send only content you’re authorised to handle. For instructions, see the email template preview workspace.
02 · Disposable inbox
Temporary addresses, email content, and retention limits
When you create a temporary inbox, the service generates a random address, access token, and expiry time. Sender details, subject, received time, HTML content, and plain-text content are used to populate the message list and reader. The token identifies who can access the inbox, so protect it like an access key.
Temporary addresses last 3 hours by default. Each extension adds 3 hours, up to a maximum of 24 hours per inbox. The expiry time shown in the interface and returned by the server applies. Previewing an email template doesn’t keep its content beyond the inbox’s lifetime, and closing the page doesn’t pause the timer.
| Data or action | Retention or effect | What to know |
|---|---|---|
| Temporary address and email content | 3 hours by default; extendable up to 24 hours per inbox. Deleted at expiry. | Expired content can’t be recovered. Don’t use it for accounts that need password recovery over time. |
| Delete one email manually | Deletes the selected email without ending the inbox’s remaining lifetime. | The address can still receive new emails. Deleting a message doesn’t recall it from the sender. |
| Get a new address / destroy the current one | Getting a new address creates a fresh inbox with a default 3-hour lifetime and destroys the old one. Destroying it manually ends access to the old inbox. | The old address and emails aren’t moved to the new inbox. Getting a new address does not extend the old one. |
| Temporary email attachments | Delivery and processing may involve attachment information, but temporary inboxes don’t store attachment file contents. | Attachment downloads aren’t supported. Embedded images in email attachments may not display. |
| Forwarding email archive | Records from the last 30 days are kept. You can delete individual records or clear the archive. | This doesn’t mean aliases last only 30 days, and it doesn’t delete copies already received in your real inbox. |
| Access and security information | Processed as needed to connect to the service, prevent abuse, and troubleshoot issues. | The 3- and 24-hour limits apply to temporary inboxes; they aren’t a universal deletion schedule for all service logs. |
Expiry and manual destruction are different triggers
Expiry cleanup happens when the inbox lifetime ends; you don’t need to leave the page open. Manual destruction ends the current session before expiry. Once testing is done, the homepage’s “Get a new address” option destroys the old inbox after creating a new one—it doesn’t keep the old inbox as a history.
Once deleted, emails can’t be recovered by reopening the page. Server-side cleanup can’t remove verification codes you copied, screenshots you saved separately, sender-held records, or copies stored by your browser or other services.
Preview templates without sending real secrets
Check the layout with test verification codes, fictional orders, and anonymised data. Don’t send production API keys, real customer lists, or full payment details to a disposable inbox just to test HTML rendering.
03 · Long-term inbox
Real inboxes, alias mappings, and a 30-day archive
Long-term forwarding uses email verification to sign in. We use your login email to verify your identity and link the aliases you create to that inbox. To process forwarded messages, we need to read the recipient alias, sender details, email content, and forwarding status to route messages, show the results, and troubleshoot issues.
The archive keeps records from the last 30 days so you can review forwarding activity and available email content. It isn’t a permanent email store. This retention period applies to the archive, not to your login email or alias mappings. Mappings need to remain while an alias is in use so forwarding can work.
Three actions that are often confused
- Disable or delete an alias: When disabled, the alias stops forwarding new messages; deleting it removes the alias. Neither action deletes past archived records or recalls emails already delivered to your real inbox.
- Delete archived records: Delete selected records or clear the current account’s archive. This doesn’t delete aliases. If an alias is still active, it can continue forwarding new messages and creating new records.
- Log out: Clears the login token and login email stored in your current browser, ending your session on this device. It doesn’t delete your account, alias mappings, or server-side archive.
If you use two-step verification, the service also needs to process your authenticator setup and the data required for verification. Treat the setup key as an account secret and don’t send it by email to support. For account-level deletion or data requests that can’t be handled in the dashboard, please use our contact and data request instructions.
You can sign in through the email forwarding portal to manage aliases and archived records. Your real email provider’s policies and settings separately govern how forwarded copies are stored, marked as spam, and deleted.
04 · Reading in your browser
Local credentials and external resources in HTML emails
Your browser stores the token and login email needed to sign in, as well as the access credential needed to restore a temporary inbox. Reading status may also include the ID of the last email you opened, so the page can restore it after a refresh or when you return. This data helps with access and session recovery; it doesn’t mean the entire email is permanently backed up in your browser.
Long-term forwarding login credentials are stored locally and may remain after you close the tab. On a shared computer, log out when you’re done. Clearing website data may remove the access credential for your temporary inbox, but won’t send the service a request to delete emails, destroy the inbox, or delete your account.
HTML formatting also means checking where resources come from
Email content is displayed in an isolated reading environment and may be sanitised for security. It’s not a web page that lets arbitrary sender code run. If your browser loads external images, fonts, or other remote resources from an email, their providers may receive your IP address, access time, browser information, and unique identifiers in resource URLs—and may infer that you opened the email.
Security sanitisation and isolation don’t replace checking who sent the email, and they don’t guarantee that every email client will display it the same way. For untrusted messages, start with plain text or view the HTML source, and avoid clicking links. Remote images and embedded attachment images are different: the latter may not display because temporary inboxes don’t store attachment contents.
Turn off tracking in templates before previewing
Use static resources you control in test emails, and remove real user identifiers and tracking pixels. To check email client compatibility, use the template preview workspace to test across multiple clients. A single web-based reader isn’t enough to confirm full compatibility.
05 · End this session
What you can control, and what happens next
First decide what you want to end: one email, a temporary address, or a forwarding relationship. Choosing the right action helps you avoid logging out and assuming your history was deleted, or deleting an email while leaving the address active to receive more.
Use the controls available in the product to take these actions. This policy doesn’t initiate deletion, and you shouldn’t submit an email token here. If there’s no self-service option for what you need, contact support without including sensitive credentials in your message.
- Remove one test email
- Open the email in your temporary inbox and select Delete. The address remains active, and other emails aren’t affected.
- Start a separate test
- Select “Get a new address.” Update the recipient address in your test form before sending the next message. Once the old inbox is destroyed, don’t send more messages to it.
- End access to a temporary inbox
- Destroying an inbox ends access to it; you can’t use a recovered token to restore deleted content. The homepage’s new-address flow destroys the old inbox. If you take no action, the inbox expires on schedule.
- Pause or end a forwarding relationship
- In the forwarding dashboard disable or delete the alias. Delete archived records separately; copies in your real inbox must also be deleted there.
- Clear forwarding history and local session
- Delete the archived records you want removed, then log out if needed. Logging out protects access on this device; it doesn’t replace server-side data cleanup.
What not to send here
Don’t use a temporary address for important accounts that need long-term recovery, and don’t send production keys, customer data, identity documents, or payment secrets. Use fictional data for template tests. Long-term forwarding can receive ongoing notifications, but it isn’t a secure vault for highly sensitive data.
Don’t share request links containing tokens, developer tool screenshots, or full request headers. If you report “I didn’t receive a verification code,” first follow our verification code delivery troubleshooting steps to check the recipient address, timing, and sending records. Share only the minimum information needed to diagnose the issue.
06 · Contact and updates
For privacy questions and data requests, contact support
If you have questions about this notice or want to request access to, correction of, or deletion of your data, contact us at support@tempcase.com. Tell us whether you use a temporary inbox or long-term forwarding, and include the time and time zone of the issue, the relevant address or alias, and the steps you’ve already tried—only what’s needed to locate the issue.
For account data requests, we recommend writing from the account’s login email. We may need to confirm that you’re authorised to act on the data. Don’t send login verification codes, authenticator keys, email tokens, production passwords, or unrelated full email messages. Expired and deleted temporary inbox content can’t be restored to fulfil a request.
Include these three things in your request
- Which feature: temporary inbox, template preview, or long-term forwarding.
- What you want: information about how data is used, a correction, record deletion, or confirmation of an action.
- How to locate it: time and time zone, relevant address, and any necessary redacted details.
This policy was last updated on . We’ll update this page and its date when data use, retention, or user controls change. For important changes, we’ll provide an appropriate notice rather than silently leaving the old policy date in place.
This notice and the Terms of Service together describe the boundaries for using the product and handling data. If you’re unsure whether a test is suitable for a disposable address, don’t send sensitive content and contact support first.
Know the limits before your next test.