Email 2FA beats no 2FA. Email codes are the weakest second factor on offer, because the code drops into the same inbox your password resets go to. Take that inbox over and both factors fall together.
So switch email codes on where a site offers them, then move off them the moment a stronger option turns up. CISA puts text and email codes last among MFA methods, calls them the weakest protection, and says to reach for them only when nothing stronger is available for that account. NIST SP 800-63B goes further and does not allow email as a channel for single- or multi-factor authentication at all, because email cannot prove you hold a specific device. Email codes stay everywhere because they cost almost nothing to send and ask nothing of the user.
In Google's 2019 study, run with researchers from New York University and the University of California, San Diego, an SMS code sent to a recovery phone number stopped 100 percent of automated bots, 96 percent of bulk phishing attacks, and 76 percent of targeted attacks. On-device prompts did better still: 100, 99, and 90. Zero users who relied only on security keys fell victim to targeted phishing during the investigation. SMS and prompts were what the study measured, not email codes, and email codes sit below SMS in every official ranking. The lesson holds anyway: a weak second factor beats a password on its own by a wide margin.
How email 2FA actually works
You type your password. The site emails a one-time code to the address on the account, usually six digits. You type that code back and you are in. Some sites send a link instead. Click it to confirm. Either way, the site is checking that you can read mail sent to that address.
That check is the whole security model. The code shows you can open a mailbox, nothing about the device in your hand or where you are. A password reset proves the same thing.
No app to install, no device to register, and no setup step at all. The user already has an inbox, so the site meets them there. That is why they are the default on forums, shops, newsletters, and smaller services that cannot afford anything fancier. That ease is the selling point. It is also the hole.
One inbox takeover defeats both factors
Walk through the attack, because nothing in it is exotic. An attacker picks up your password from a breach file or a phishing page, signs into your inbox, then opens a second tab and asks for a password reset on your bank account or a shop account. The reset link lands in the inbox they already control. They click it, pick a new password, and they are in.
Now put email 2FA into that picture. The attacker signs into your inbox, which email 2FA is supposed to guard, and the 2FA code arrives in that same inbox. There is no second channel left to break. Two factors, one mailbox, and that is all that is left.
A text code behaves differently: it travels over the phone network, a channel apart from the inbox, so taking over the inbox alone does not reveal it. The attacker has to go after the phone channel separately, say with a SIM swap that moves your number onto a SIM they control. That attack is real and it works. Email 2FA has no second channel. Password reset and second factor both sit in that one mailbox, behind the same password and the same recovery flow. I have no reliable SIM-swap figure to put next to that, so I will not invent one.
That is what makes the inbox the account that matters most. Almost every forgot-password flow ends there. Whoever controls the inbox can reset almost everything else. Email 2FA guards that master account with a key kept inside it. It helps against an attacker who holds your password but not your inbox, and it does nothing against an attacker who holds your inbox.
The inbox holds more than resets. Breach notifications and account alerts land there. An attacker inside can see which services you use and delete the new sign-in warnings. Then they work through your accounts at leisure. The second factor was meant to stop that. When it is email, it travels through the same compromised channel as everything else.
The AliasFleet fit: separate the channels, separate the addresses
The fix has two halves, and both come down to separation. Move the second factor onto a channel apart from the inbox: an authenticator app or a passkey, covered in the next two sections. And stop handing every site the address that receives your codes. Aliases are that second half.
AliasFleet is an email-alias service: one forwarding address per site, every one landing in your real inbox, each killable on its own. How email aliases actually work comes down to a forwarding rule plus a reply trick plus a kill switch, not a second inbox. When every site gets one alias per site, the address that receives a site's 2FA codes is not the address plastered across every signup form and every breach file. Your real inbox address stays private, and every alias serves exactly one purpose.
That changes two things. The code-receiving address gets harder to target, because it is not the address everyone already holds. And a leaked alias names its source: a phishing message arriving on one site's alias tells you which website leaked it, and killing that alias cuts the channel without touching anything else.
On their own, aliases do not fix the shared-channel problem. A code sent to an alias still ends up in your inbox. They shrink the attack surface around the inbox. Fewer places hold the real address, so fewer leaks expose it. Each site's mail stays attributable. The same concentration problem shows up elsewhere. Chaining every login to one provider creates a single point of failure in the same way, and the answer has the same shape: split the identity into pieces you control instead of stacking everything behind one door.
The authenticator app: a code your inbox never sees
An authenticator app works on a different mechanism from email codes. Setting it up means sharing a secret with the site, usually by scanning a QR code. The app mixes that secret with the current time and turns out a six-digit code, which changes every 30 seconds. The algorithm is TOTP, defined in RFC 6238, and the site works out the same code on its side and compares. At sign-in time, no message travels anywhere. The code comes from your device, from a secret your inbox never held.
Take over the inbox and you still learn nothing about the authenticator codes. A valid code needs your password and your device, or the secret itself, and the inbox takeover that beats email 2FA does not beat TOTP.
TOTP has limits of its own. A code is still digits on a screen, and a phishing page can ask you to type it in, then relay it to the real site within its short lifetime. Google's 2019 study shows a man-in-the-middle page prompting victims for their SMS codes after stealing the password. TOTP codes fall to the same relay. TOTP also needs a backup plan. Lose the phone and you need recovery codes or a second method, or you are locked out.
GitHub's 2FA docs treat TOTP apps as standard, with security keys and passkeys alongside, and GitHub warns that SMS is susceptible to interception and provides no resistance against phishing attacks. Google's Authenticator help page says the app generates codes without an internet connection or mobile service. A code that never travels cannot be intercepted in transit or read out of your inbox, because it was never in your inbox.
Setup takes minutes: install an authenticator app, scan the site's QR code, enter the code it shows, and save the recovery codes somewhere offline. Start with the email account itself. That is the one whose takeover defeats everything else.
Passkeys: the factor that cannot be relayed
Passkeys are the strongest option, and they rest on a different principle from codes. A passkey is a public-key credential. The private key stays on your device and never leaves it. The site holds the matching public key. At sign-in, the site sends a challenge. Your device signs it with the private key, and the site verifies the signature. There is no code to type and nothing to intercept.
Origin binding is the property that matters. The signature covers the site you are actually on. A phishing copy gets nothing it can replay against the real one, because the credential only answers for the domain it was registered with. The FIDO Alliance calls passkeys phishing-resistant by design, with no shared secrets. Microsoft's Entra documentation puts it plainly: passkeys replace phishable methods like passwords, SMS, and email codes, using origin-bound public-key cryptography so credentials cannot be replayed or shared.
Passkeys come in two shapes. Device-bound passkeys stay on one device. Synced passkeys move between your devices through your platform's credential manager, encrypted end to end. Either shape beats any code. The catch is support. Not every site offers passkeys yet, and account recovery when you lose all your devices is still the awkward part. Where a site offers a passkey, take it. Where it does not, the authenticator app is the fallback, and email codes sit after that.
When email 2FA is the only option
Some sites offer nothing else at all. A small forum or an old shop account: email code or nothing. In that case, use the email code. CISA's ranking says to use text or email codes only when stronger options are unavailable. They still have a job when nothing stronger exists. A weak second factor still blocks the attacker who only has your password. That attacker is the common one.
Then harden the inbox. Put the strongest factor the email account supports on the email account itself: a passkey or an authenticator app, not an email code. Keep a unique password on the email account, stored in a password manager, shared with nothing else. Review the recovery options. A stale recovery phone number or a forgotten recovery address is a back door carrying your name.
A 2FA code you did not request means someone holds your password and is trying the next step. Change the password, check recent sessions, then look for forwarding rules or recovery changes you did not make.
Treat unexpected codes as that signal. Never type a code into a page you arrived at from a link in an email. Go to the site directly and type the address yourself. Enter the code there. Never read a code out to anyone, over any channel, for any reason. No support agent will ever need it.
Microsoft's own guidance calls email password-reset-only for work and school accounts, not a two-factor method. That is the right way to think about email. Email is good at recovery. As a second factor it is poor, because recovery and authentication collapse into the same channel.
Where a site only offers email codes, give it a per-site alias as the address on the account. The code still lands in your inbox, but the address receiving it is not your real one, and a leak of that alias names the site. Damage control around the shared-channel problem, and it costs nothing.
What to do now
Work through this list in order, starting with the account everything else resets through.
- Turn on 2FA everywhere, email account first. Email codes count where nothing better is offered, and something beats nothing.
- Where you get a choice, pick in this order: passkey, authenticator app, text message, email code last.
- The email account itself gets a passkey or an authenticator app, because the inbox is the master key and deserves the strongest lock.
- Hand each site its own alias instead of your real address, because the address receiving a site's codes must not be the address in every breach file.
- Keep backup and recovery codes offline, on paper. A second factor you cannot recover turns a lost phone into a lockout.
- When a code arrives that you did not request, act on it. Change the password and check sessions. Then check forwarding rules and recovery settings.
Keep email codes where nothing better exists; everywhere else, move up the ladder, harden the inbox itself, and keep the address that receives your codes out of every signup form you can.
Top comments (0)