A guide to email verification codes (OTP) — how they work and what to do if one is missing

A one-time passcode is a short number — usually four to eight digits — that proves you control an email address (or a phone number, an authenticator app, or a hardware key). For most internet users, OTPs are the second-most-common authentication event after passwords. They're also the most common pattern in disposable inboxes: every signup, every password reset, every "we noticed a sign-in from a new device" comes through as one.

This is everything you'd want to know about email OTPs.

How an email OTP works

Conceptually:

1. You initiate an action that needs verification (signup, login, password reset).
2. The service generates a random code (usually six digits) and stores it server-side, associated with your account and an expiry time (commonly 5–15 minutes).
3. The service sends the code to your email.
4. You read the code and type it into the form.
5. The service compares; if it matches and isn't expired, you're verified.

That's it. There's no cleverness in the code itself; it's just a random number. The security comes from the assumption that only the rightful owner of the email address can read incoming mail.

Why six digits is the standard

The math is roughly: an attacker has to guess the code before it expires. Six digits gives one million possibilities. With a five-minute expiry and a server that allows three attempts per code, the chance of a random guess working is about 3 in a million. Add rate limiting and the attacker is forced into bulk schemes (e.g. cracking many accounts in parallel rather than guessing one).

Four-digit codes are weaker (10,000 possibilities) and rare today. Eight-digit codes are sometimes used by banks and governments because the cost of a successful guess is so high.

OTP detection in PocketInbox

We surface verification codes prominently in the message reader. When a code is detected, you see a big "Code 123456" panel with a one-tap copy button. The detection is heuristic:

• Search the first ~800 characters of the message body and subject.
• Prefer codes adjacent to keywords like "code," "OTP," "PIN," "passcode," "verification," "confirm," "2FA."
• Skip strings that look like phone numbers or transaction IDs.

The detection misses occasionally — for example, when a localised email uses a non-English keyword we don't recognise yet. When that happens you can still copy the code manually. Tell us which keywords you'd like added.

Why OTPs sometimes don't arrive

In rough order of probability:

1. Provider rate limit upstream. Mail.tm's 8 QPS budget is shared across all users behind one IP. If we're proxying, the IP is ours, and a burst of signups from many users can briefly cap. We pop a "Too many requests" banner when we detect this and back off.
2. The sender's outbound queue is delayed. Some services run "trusted" and "untrusted" send queues; mail to disposable domains often lands in the slow queue. Wait two minutes before assuming it's lost.
3. The disposable domain is on the sender's blocklist. The OTP just isn't sent. Switch provider or domain and try again.
4. Spam-quarantine on the upstream provider. Rare, but some providers do soft filtering. The message exists; we just don't see it. Burning the inbox and generating a new one usually fixes it.
5. You typed the wrong address. Easy to do. Verify by hovering on the address shown in the inbox header.
6. The form sent to your real email instead. Some forms have multiple "email" fields and you filled the wrong one. Look at your real inbox if you have access.

What if the code expires before I get it?

Hit "Resend code" on the original form. A new code is generated; the old one (if you still have it) is invalidated.

What if I keep getting "code is invalid"?

Three possibilities:

• You're typing an old code. Use the most recent message in the inbox.
• You're typing the right code with a typo. Use the copy button rather than typing.
• The session on the form expired. Refresh the form and request a new code.

Should I trust an OTP that arrived without me asking?

No. This is the #1 phishing pattern in 2026. The flow goes:

1. Attacker initiates a "forgot password" or "transfer money" action on a real service, using your email or phone.
2. The real service sends you a real OTP.
3. Attacker calls or texts you, claiming to be from the service, asks you to "confirm" the code.
4. You read it out. Attacker types it in. They're now you.

The OTP itself is real. The attacker just needs you to relay it. Defence: never read out a code you didn't request. Codes are inputs, not currency. If the email says "If you didn't request this, ignore," ignore it — and consider it an early warning that someone is targeting your accounts.

OTP via email vs OTP via app

Email OTPs are weaker than app-generated TOTP codes (Authy, Aegis, Raivo, 1Password). Why?

• Phishability. An attacker who controls your email can request unlimited OTPs. An attacker with your password manager would already have the password.
• Delay. Email is asynchronous; TOTP is instantaneous.
• Blast radius. Compromise of your email account compromises everything that uses email OTP. Compromise of your authenticator app is much rarer and more contained.

Use email OTP only when you have to. For everything you actually care about, prefer hardware key > passkey > TOTP > email OTP > SMS OTP, in that order.

What's the future of OTP?

Passkeys (the FIDO2-based standard now broadly supported by Apple, Google, Microsoft, and most password managers) are gradually replacing OTPs for first-factor auth on consumer sites. They're stronger, faster, and unphishable. Email OTPs will stick around for low-stakes signup flows for a long time, mostly because they require no setup from the user. Expect them to slowly drift from "primary auth method" to "auxiliary method for new-device verification" over the next few years.

OTP UX patterns to recognise

• The 6-digit grid input. Six adjacent input boxes, each one digit. Modern, copy-friendly. iOS and Android keyboards both autofill from the latest OTP-shaped SMS or email.
• The "magic link" alternative. Some forms send a clickable link instead of a code. Same security model, less typing.
• The combined "code or link" email. Both options in the same message. Pick whichever's more convenient.

The takeaway

OTPs are simple, well-understood, and good enough for most low-stakes verification. They are a perfect fit for disposable inboxes — generate, paste, copy, click, forget. They're a poor fit for high-stakes accounts where you should be using a stronger factor in the first place.

If your code didn't arrive: switch domain, switch provider, wait two minutes, then accept the form may simply not want disposable users.

And if a code arrived and you didn't ask: ignore it, don't relay it, and consider whether your real accounts are being probed.

Need a code right now? Generate an inbox and we'll have it visible within seconds of arrival.