Security
How the service is built, what it protects against, and — just as importantly — what it does not protect against. Report a vulnerability at the address at the bottom of this page.
Your Temporary Email Address
Waiting for mail...
- No signup
- 24-hour inbox
- OTP auto-detect
- Zero tracking
- Android · Chrome · Firefox
- Developer API
Security summary
| Control | What it does |
|---|---|
| TLS and HSTS | Encrypts browser traffic and prevents downgrade to plain HTTP after the first visit. |
| Private session ownership | Keeps generated inboxes tied to the browser that created them. |
| Receive-only addresses | Prevents the service from becoming a spam relay or impersonation sender. |
| Automatic deletion | Removes expired inboxes, messages, and attachment binaries instead of keeping an archive. |
| Disclosure channel | Security reports go through security.txt or the contact page. |
In transit
Every connection is TLS-only. The site sends HTTP Strict Transport Security with a one-year max-age including subdomains, so a browser that has seen the site once will refuse to connect over plain HTTP afterwards. The real-time inbox runs over an encrypted WebSocket on the same origin.
Mail arriving from a sending server is a different matter and outside anyone's control here: whether that hop was encrypted depends on the sender supporting TLS. This is true of all email, not of this service in particular.
At rest, and how little of it there is
The strongest control here is not encryption, it is time. An inbox lasts 24 hours, extendable once to 48. A scheduled job deletes expired inboxes along with their messages and attachment binaries. Data that no longer exists cannot be breached, and that is the design.
What this does not give you is end-to-end encryption. Mail passes through the server in a readable form, as it must for the inbox to display it. A disposable inbox is the wrong tool for anything genuinely sensitive, and the privacy page is explicit about where that line sits.
Abuse
Inboxes are receive-only. Nothing can be sent from a TempMailGrab address, which removes the entire category of abuse where a disposable service becomes a spam relay or an impersonation tool. It also protects the domain's deliverability, which is why the feature is absent rather than merely discouraged.
Inbox creation is rate limited per IP. Addresses are randomly generated rather than name-addressable, so one visitor's inbox cannot be reached by another visitor guessing a name — a difference from services built on public named inboxes.
Reporting a vulnerability
Security reports are welcome and will not be met with legal threats for good-faith research. Use the address in /.well-known/security.txt, or the contact page marking the message as a security report.
Please include enough detail to reproduce the issue, and give a reasonable window to fix it before publishing. Please do not run automated scanners against production, degrade the service for other users, or access data belonging to anyone else while testing.
API keys
An API key is a bearer credential: anyone holding it can act as you. Keep it in an environment variable or your CI provider's secret store, never in committed source, and never in client-side code where a browser would expose it.
Keys can be rotated from the dashboard. If one has been exposed, rotate immediately rather than waiting to confirm misuse. The API is served over TLS only and accepts the key by Authorization: Bearer or X-API-Key; details are in the API docs.
Browser extensions
The Chrome extension and Firefox add-on are distributed through their official stores, which is what makes their permissions auditable: the exact permission list is shown on the store listing before you install, and both stores review submissions.
The plain-language explanation of what each permission is for, and what the extensions deliberately do not do, is on the Chrome extension page and the Firefox add-on page.
Android app
The Android app is distributed through Google Play, and its Data Safety declaration is visible on the store listing. The same retention applies as on the web: inboxes expire and are deleted on the server, so uninstalling the app does not leave mail behind somewhere.
The Android app page covers what it collects and why.
Status and policy
Live availability is at status.tempmailgrab.com. The formal data-handling document is the privacy policy, and the plain-language version is privacy explained.
Last verified: . Reviewed against the running configuration.
Automate inboxes with the API
Prefer to script it? Generate disposable inboxes and read auto-parsed OTPs & verification links programmatically — built for QA, test automation, and bots. The same private inboxes, over a clean REST API.
# 1. Create a private inbox
curl -X POST https://tempmailgrab.com/api/v1/inbox \
-H "Authorization: Bearer $TMG_API_KEY"
# → { "id": "inb_…", "address": "a1b2c3d4e5f6@tempmailgrab.com" }
# 2. Poll for mail — the OTP + verification links are auto-extracted
curl https://tempmailgrab.com/api/v1/inbox/$ID/messages \
-H "Authorization: Bearer $TMG_API_KEY"
# → { "messages": [{ "extracted_otp": "123456", "extracted_links": [ … ] }] }Related guides
Frequently Asked Questions
Is TempMailGrab end-to-end encrypted?
No, and no service that displays your mail in a browser can be. Connections are TLS-only with HSTS, but messages pass through the server in readable form because the inbox has to render them. The protection here is retention rather than encryption: the data is deleted within 24 to 48 hours.
How do I report a security vulnerability?
Use the address in /.well-known/security.txt, or the contact page marked as a security report. Good-faith research will not be met with legal threats. Please allow a reasonable window before publishing, and do not access other users\u2019 data or degrade the service while testing.
Can someone else read my inbox?
Addresses are randomly generated and scoped to your session rather than reachable by typing a name, so another visitor cannot open your inbox by guessing it. This differs from services built on public named inboxes, where any address is readable by anyone who knows the name.
Can spam be sent from a TempMailGrab address?
No. Inboxes are receive-only by design. Nothing can be sent from the address, which removes the whole category of abuse where a disposable service becomes a spam relay or impersonation tool, and keeps the domain deliverable.
What should I do if my API key leaks?
Rotate it in the dashboard immediately rather than waiting to confirm misuse. A key is a bearer credential, so anyone holding it can act as you. Keep keys in environment variables or a CI secret store, never in committed source or client-side code.