Privacy Policy

1. Data we process

When you create or use a temporary inbox, the service may process:

• the generated email address, inbox identifier, receiving domain, status, and expiry time;
• incoming message headers, sender and recipient details, subject, text or HTML bodies, and attachments;
• the IP address and browser user-agent associated with inbox creation;
• request, rate-limit, security, and diagnostic metadata; and
• API credential identifiers, abilities, expiry, and recent-use metadata when the API is used.

A public temporary inbox does not ask you to register a name, password, phone number, or recovery email. However, senders can include personal information in message content, so do not use the service for sensitive communication.

2. How inbox access works

A public inbox is reached through an unlisted capability URL rather than a login. Anyone who obtains that URL can read its messages until the inbox expires. Inbox pages are marked to discourage search indexing, but that is not an access-control guarantee.

API-created inboxes are restricted to the credential that created them. Administrator-created permanent inboxes are available only through the administrator area and do not use the public capability-link flow.

3. Retention and deletion

Standard public inboxes expire after approximately 60 minutes. Expired inboxes, messages, and stored attachments are then scheduled for cleanup. Deletion may not occur at the exact expiry second because cleanup runs as an operational process.

Detailed first-party public-page analytics events are retained for approximately 90 days and then scheduled for deletion. Aggregate operational counts can remain in backups until the backup-retention window ends.

Operational backups may contain copies until the deployment's configured backup-retention window ends. Backups are intended for disaster recovery and are not offered as a way to restore an expired inbox. We do not claim that every deployment encrypts backup files; storage and transport protections depend on the configured backup destination.

Security logs, abuse records, API credentials, and administrator-managed permanent inboxes can follow different retention periods because they serve different operational purposes.

4. Cookies, local storage, and analytics

The site may use technically necessary session or security cookies. Theme and analytics-consent choices are stored in your browser's local storage.

We use limited first-party server-side measurement on successful public content pages to understand service demand and reliability. It records the event time, normalized page path without its query string, coarse browser and device categories, a validated country code when supplied by our network provider, and the referring hostname without its path or query. A keyed one-way hash derived from a shortened IP network and browser user-agent estimates unique visitors. The analytics event store does not retain the raw IP address, raw user-agent, full referring URL, or public inbox identifiers. Public inbox pages, admin and API routes, known bots, prefetches, and requests that send Do Not Track or Global Privacy Control are excluded.

On public marketing pages, optional analytics scripts load only after you choose “Allow analytics” and only when the relevant service is configured. These can include Google Analytics, Cloudflare Web Analytics, Ahrefs Analytics, and SiteWit. Analytics scripts are not loaded on public inbox routes.

If you allow analytics, those providers may receive device, request, and usage information under their own privacy terms. You can withdraw consent by clearing the site's local storage and cookies, then choosing not to allow analytics when prompted again.

5. How we use data

We process service data to:

• create inboxes and receive, store, display, and delete messages;
• provide credential-scoped API access;
• enforce rate limits, filter abusive traffic, and protect the mail pipeline;
• diagnose failures, maintain reliability, and investigate reported abuse; and
• measure public-site usage through limited first-party operational metrics and, when consent has been given, optional third-party analytics.

Message handling is primarily automated. Authorized operators may access data when reasonably necessary to operate the service, investigate abuse or security incidents, respond to support requests, or comply with legal obligations. We do not use inbox message content to build advertising profiles.

6. Service providers and disclosure

Running the service requires infrastructure providers. Depending on configuration, Cloudflare may process network and request metadata for DNS, delivery, and attack protection; hosting, database, cache, and object-storage providers may process application data or attachments; and consented analytics providers may process public-site usage data.

We may also disclose information when required by law, to protect the service or others from abuse, or during a change in service ownership subject to appropriate safeguards. We do not sell inbox contents.

7. Message privacy and security

Connections to the website use HTTPS. HTTPS images inside messages load automatically so email layouts render correctly. Fetching them can reveal your IP address, browser details, and message-open timing to the sender; insecure HTTP images remain blocked. HTML messages are displayed in a restricted frame.

No internet service can guarantee complete security or delivery. Keep inbox URLs private, treat message links and attachments as untrusted, and never use temporary email for financial, healthcare, identity, recovery, or other confidential workflows.

8. Questions and requests

For privacy questions or data requests, email [email protected]. Include enough detail for us to understand the request, but do not email passwords, API tokens, inbox capability URLs, or sensitive message content.