Codes sent to an alias arrive normally — it's ordinary email, routed the same way as anything else. The real question isn't whether 2FA works through an alias; it's what happens if you lose control of that alias while it's still the second factor on a live account. Two rules cover it: never disable an alias that's carrying 2FA, and prefer an authenticator app over email codes wherever the option exists.
Why it just works
A 2FA code delivered by email is an email. The sending service addresses it to whatever's on your account, the mail server routes it, your alias forwards it, and it lands in your inbox. Nothing in that chain inspects whether the address is an alias — the concept doesn't exist at the protocol level.
So there's no compatibility problem to solve. The considerations are all about control.
The failure mode
If bank@yourdomain.com receives your login codes and you disable it, you haven't just stopped their marketing — you've removed your second factor. You now can't complete a login, and the account-recovery route probably goes to the same dead address.
The rule is the same one that applies to password resets, just with sharper consequences: disable aliases for senders you're finished with, never for accounts you still use. The general version
Email codes are the weakest 2FA anyway
Worth saying independently of aliases. Email-delivered codes are the least robust common second factor, because they inherit every weakness of your email account — if someone controls your inbox, they control the second factor too, which rather defeats the point.
Where you get the choice, prefer in roughly this order:
- Hardware security key — strongest, phishing-resistant.
- Authenticator app (TOTP) — strong, no dependency on mail delivery at all.
- SMS — weak to SIM-swap, but not dependent on email.
- Email codes — convenient, and the one to move off first.
Moving an account to an authenticator app removes the alias question entirely for that account, which is the cleanest resolution.
Practical setup
- Secure your actual inbox first. Whatever your aliases forward to is the single point everything routes through. Put a hardware key or authenticator app on it, not email codes — it can't email itself.
- Give security-sensitive accounts their own alias and mark it, mentally or in your password manager, as never-disable.
- Don't use an alias on your alias domain for the registrar or the alias service itself. If the domain breaks, you can't receive the code that would fix it. The circular dependency
- Store backup codes somewhere offline. This is the answer to every "what if the delivery route fails" scenario, alias or not.
Does an alias add security?
Marginally, in one specific way. If your login address is an alias only that service knows, an attacker who learns your primary address doesn't automatically know your username there — and credential-stuffing lists keyed to your main address won't match.
That's a modest benefit and shouldn't be oversold. It's not a substitute for unique passwords, which remains the thing that actually determines whether a breach elsewhere becomes a compromise here.