Temp Gmail: a real @gmail.com address you can throw away

Behind this page is a pool of ordinary Gmail accounts that Temp-MailX owns and operates. Each account has a fixed local part — the piece before the @ — and Google treats every dotted spelling of that local part as the same mailbox. A local part of twelve letters has over two thousand dotted spellings. When you generate with Gmail selected, the service picks the pool account with the fewest live addresses, draws a spelling that is not in use and has never been issued, and binds it to your browser session. That spelling is your temp Gmail address.

A worker reads the pool mailbox over IMAP, looks at the exact To address on each new message, and routes it to the one inbox that owns that spelling. Your page updates in real time, the verification code is offered as a one-click copy, and the message is rendered in a sandbox. You never see the Gmail account’s login, its settings, or any mail not addressed to your own variant. It is a variant of a Gmail mailbox we run, not a mailbox of your own — so it is receive-only, it is not a Google Account (no password, you cannot sign in to any Google service with it), and it is temporary: when the countdown ends the spelling is retired for good and never issued again.

The pool is finite, which is why the page is honest about availability. Addresses come from a pool of real Gmail inboxes when one is available. Every account carries a cap on simultaneous live variants (by default 200), accounts are re-checked over IMAP on a schedule, and the operator can pause Gmail issuance. If no account has room, the service falls back to a random-domain address instantly, posts a notice above the inbox explaining why, and offers a Try Gmail again button. A random-domain address is a complete, working inbox — the same tool the home page issues — so finish the signup and come back for Gmail next time.

Most pages that promise a disposable Gmail are vague about what is on offer. You get:

• A genuine @gmail.com address that accepts mail the moment it appears, with delivery handled by Google rather than by a throwaway domain.
• A live inbox on this page that refreshes itself; no reload, no app, no account.
• Verification codes and magic links extracted from each message, with a copy button.
• Messages Gmail filed into Spam as well as the Inbox, flagged so you know Gmail distrusted the sender.
• Sanitized HTML, remote images blocked until you load them, attachments within the usual limits.
• A one-time recovery code to reopen the inbox from another browser or device before it expires.
• Two countdowns: how long the address accepts mail, and how long the messages stay readable.

You do not get:

• A Google Account, a password, or a login. There is nothing to sign in to.
• The ability to send, reply or forward. The address is receive-only by design.
• Access to the underlying mailbox. You see mail addressed to your own dotted variant only; nobody else’s mail is shown to you, and yours is never shown to them.
• A permanent address. When the timer ends it is gone for good.
• A promise of availability. Gmail addresses depend on the pool; when it is full or paused you get a random-domain address instead.

For the temp Gmail with password searches that land here: no honest free service hands out Gmail passwords, because a shared-password Gmail account is not temporary, not private, and not yours. A temporary Gmail address can legitimately be exactly this — a receive-only alias on a mailbox someone else operates, scoped to you, for a short time.

The generator on this page is the one that powers the rest of Temp-MailX, with the source set to Gmail. Press Generate and a fresh dotted variant is drawn, bound to your session, and listed in your recent inboxes. Each address is independent, with its own countdowns, recovery code and messages.

Because every Gmail address consumes a slot on a real mailbox, the Gmail generator is rate-limited more tightly than the random-domain one. By default a connection can draw 5 Gmail addresses per day; when that is reached the page says so and keeps issuing random-domain addresses, which have a much looser hourly limit. There is also a cap on how many inboxes one browser session can hold open at once. These are operator settings and can change; the message on screen is the authority.

Three habits make the temporary Gmail generator work better. Generate the address before you start the signup. Copy it with the button rather than retyping it — a missed dot sends the code to a variant that is not yours. And if a site says the address is already registered, do not draw another Gmail variant: that site compares addresses without their dots and will reject every variant of that mailbox. Switch to a random-domain address instead.

Looking for a Gmail generator that creates real Google Accounts in bulk? That is not what this is, and not something we offer.

Searches for 10 minute Gmail or email 10 min Gmail mean “work for the next few minutes, then disappear.” That is what this does, with one honest difference: the address does not vanish after exactly ten minutes. Two countdowns run above the inbox, and they end at different times.

The first is the address lifetime: how long the dotted variant keeps accepting mail. By default it is 24 hours — deliberately longer than ten minutes so that a code that arrives late still lands. When it ends the address is retired and the spelling never reissued.

The second is the message retention: how long what already arrived stays readable after the address closes. By default messages are kept a further 24 hours and then deleted permanently, together with attachments and raw source. If you need the address alive longer, Keep longer above the inbox extends it to the pinned lifetime (seven days by default). Nothing can be recovered after deletion.

If you want a classic ten-minute mailbox that does not need to be @gmail.com, the 10 minute mail page runs the same inbox on a random domain; the timing rules are identical.

One toggle, two kinds of address: a random-domain address on a domain we own and rotate, or a temp Gmail address on gmail.com. The question is which the site in front of you will accept, and which protects you more.

Why do some sites reject disposable domains? Signup forms often check the domain against blocklists of temporary-mail providers, look up its mail records and age, or accept only a handful of consumer webmail providers. A domain that is weeks old and has issued thousands of inboxes lands on those lists quickly. gmail.com never does — blocking it would turn away most genuine users — so a Gmail address passes domain-level checks that a disposable domain fails. That is the one reason to pick Gmail: the destination’s policy, not the inbox itself.

Why would a site reject a temp Gmail address anyway? Mostly because it normalizes Gmail addresses before storing them, stripping the dots. To such a site every dotted variant of one mailbox is the same user, so if an earlier visitor registered on that mailbox, your variant is “already taken.” The fix: switch to a random-domain address, which the site has never seen in any form.

Why prefer random for privacy? Because the dotted variant is a thin disguise, not a wall. Anyone who knows the trick can collapse your variant back to the canonical mailbox and link it with every other variant used there. Your messages are never exposed by that, but the address is correlatable in a way a random string on a rotating domain is not. A random-domain address also does not depend on the pool and is rate-limited less tightly. Our recommendation: start with a random-domain address and use Gmail when the form rejects the domain. We have not measured which sites accept which and will not invent a percentage.

This address is deliberately short-lived: it stops accepting mail, and its messages are destroyed, on the timers shown above the inbox, and it is never reissued. That is a feature for a coupon gate and a disaster for a bank.

So keep your own account for anything that has to last — your bank, government services, work or school, two-factor codes for accounts you intend to keep, password resets, receipts you may need for a return, and anything tied to your identity. For two-factor codes on accounts you own, use a proper authenticator such as 2FaGen, which generates TOTP codes in the browser without involving email. Use a temp Gmail for the moments you would rather forget about: newsletters, forum registrations, one-off downloads, trials you will abandon, Wi-Fi portals.

Treat the address as shared knowledge. Any website you give it to has it, and a spelling is not a secret. What is private is the inbox behind it: messages are delivered only to the browser session that generated the address, or to one that presents the address together with its recovery code. Knowing the address alone shows nothing. The recovery code is displayed once; save it if you expect to come back from another device, because it cannot be shown again.

Every message is rendered in a sandboxed frame under a strict content security policy. Scripts are stripped, remote images and tracking pixels are blocked until you load them, links show their real destination before you follow them, and attachments outside the allowed types are dropped. None of this makes a malicious sender trustworthy; it makes reading their message safe.

Retention is short and automatic: addresses close on the first countdown, messages are deleted on the second, and raw message source is kept no longer than the message. We keep the operational minimum — a hashed tombstone so a retired variant is never reissued, and hashed rate-limit counters — and we do not sell, share or analyze the content of mail. Copies in the pool mailboxes are routed by our worker and cleared on their own short schedule; no person browses them. This is not a tool for impersonation, fraud or evading a ban; abuse signals are logged, and the abuse page explains how a site operator can report a problem.

Not at present. The Temp-MailX API issues inboxes from a separate pool of rotating random domains that belongs to the API alone; no parameter mints a Gmail address and no key-authenticated endpoint touches the Gmail pool. That is deliberate: a client issuing addresses in a loop would drain a finite set of real mailboxes and leave this page with nothing to hand out.

For a flow you control, the API gives you what you need — create an inbox, wait for a matching message, read the extracted code, delete the inbox — with an OpenAPI contract, per-key quotas and inbox-scoped read tokens, and you can allow-list its domains in your own application. Should Gmail issuance through the API ever change, it will appear in the OpenAPI spec first; nothing here is a promise of it.