What is two-factor authentication for email?

Email two-factor authentication (2FA) requires a second proof of identity, beyond a password, before someone can sign in to a mailbox. The National Institute of Standards and Technology defines three factor types: something you know, something you have, and something you are. Email 2FA combines two of them, usually a password with a possession-based code from an authenticator app, a hardware key, or a phone. It protects account login. It is a separate control from SPF, DKIM, and DMARC, which authenticate outbound mail rather than mailbox access.

How email account 2FA works

NIST's authentication guidance describes three kinds of factor:

• "Something you know (e.g., a password)"
• "Something you have (e.g., an ID badge or a cryptographic key)"
• "Something you are (e.g., a fingerprint or other biometric data)"

NIST SP 800-63B, Section 4.2.1 sets the pairing rule at Authenticator Assurance Level 2 (AAL2), the level most personal and business email accounts target: authentication "SHALL use either one multi-factor authenticator or a combination of two single-factor authenticators." When two single-factor authenticators are combined, one "SHALL be a Memorized Secret authenticator" (the password) and the other "SHALL be a possession-based authenticator."

Authenticator apps satisfy the possession requirement directly. NIST describes them as "software-based OTP generators installed on devices such as mobile phones," where typing the displayed code proves "possession and control of the device" (SP 800-63B, Section 5.1.4). A hardware security key or a passkey works the same way, through a cryptographic proof instead of a typed code.

When the second factor matters more than others

Not every second factor carries equal security. NIST's guidance ranks channels by how well they prove someone actually possesses a specific device, and it treats phone-network and email delivery differently:

NIST SP 800-63B, Section 5.1.3.3: "Methods that do not prove possession of a specific device, such as voice-over-IP (VOIP) or email, SHALL NOT be used for out-of-band authentication."

SMS and voice codes get a lighter restriction, not a ban: "Use of the PSTN for out-of-band verification is RESTRICTED," and verifiers "SHOULD consider risk indicators such as device swap, SIM change, number porting, or other abnormal behavior." Under NIST's terminology, RESTRICTED means the method carries extra conditions, not that it is prohibited.

That distinction matters because provider practice does not always match the guidance. Microsoft's own two-step verification setup lists an email address as a valid security-info method for personal Microsoft accounts, even though NIST advises against email for out-of-band authentication. The decision rule for a reader choosing a second factor: prefer an authenticator app, passkey, or hardware security key over SMS, voice, or email whenever the provider offers one, because those are the factors NIST and CISA both treat as stronger.

CISA's own framing supports that ordering: "Users who enable MFA are significantly less likely to get hacked," and "phishing-resistant MFA is the standard all industry leaders should strive for, but any MFA is better than no MFA." CISA adds that "the only widely available phishing-resistant authentication is FIDO/WebAuthn authentication," which covers passkeys and hardware security keys (CISA, Multi-factor Authentication).

Comparing second-factor options

The AAL2 pairing rule is the quotable version of the mechanism above:

NIST SP 800-63B, Section 4.2.1 (AAL2 pairing rule)
Authentication SHALL use either:
  - one multi-factor authenticator, or
  - a combination of two single-factor authenticators
When two single-factor authenticators are combined, one SHALL be
a Memorized Secret (password), and the other SHALL be a
possession-based authenticator (for example, an authenticator app
or a hardware security key).

The ranking follows directly from the sources above: an emailed code is the option NIST says SHALL NOT be used for out-of-band authentication; an SMS or voice code is RESTRICTED and needs extra fraud monitoring; an authenticator app code is a recognized possession-based factor; and a passkey or hardware security key is CISA's only widely available phishing-resistant choice. A provider offering an option does not mean it meets NIST's or CISA's stronger recommendation, and readers choosing between the options Google or Microsoft present should default to the strongest one available on their account.

Where to turn on 2FA for your email account

The exact menu label and path vary by provider, so check the account's own security settings rather than a generic menu name.

Google accounts

In a Google Account, open Security & sign-in, then under "How you sign in to Google" select "Turn on 2-Step Verification" and follow the on-screen steps. Google's second-step options include Google prompts, passkeys, hardware security keys, Google Authenticator or another code app, text or voice call codes, and 8-digit backup codes. After setup, sign-in uses a password plus a second step, or a passkey alone. A phone number added for 2-Step Verification "may take up to 7 days" for Google to trust it fully (Google Account Help).

Microsoft accounts

For a personal Microsoft account, go to account.microsoft.com/security, select "Manage how I sign in," then under "Additional security" turn on "Two-step verification." Microsoft describes the control as using "two different forms of identity: your password, and a contact method," so that even if someone finds the password "they'll be stopped if they don't have access to your security info." Microsoft's documentation also lists two real costs: apps and devices that cannot process a security code, such as some mail apps and older consoles, need a generated app password, and resetting a lost password requires two working contact methods on file (Microsoft Support). This guidance covers personal Microsoft accounts, not Microsoft 365 work or school tenants managed by an organization's IT department.

Any other provider

CISA's generic path applies when a provider is not covered above: open the account's settings, then its security settings, then turn on the option, which "may be called two-factor authentication, two-step authentication or similar." CISA recommends turning it on for every account that offers it, and lists email accounts specifically among the accounts worth protecting this way (CISA, Turn on MFA).

For a closer look at one provider's specific settings, see 2-factor authentication on Yahoo email or the broader walkthrough on multi-factor authentication for email.

Check the email authentication controls a password can't fix

Account 2FA stops someone from signing in to a mailbox without the second factor. It does nothing for the messages that mailbox sends. Whether a message from that domain is authenticated in transit is a separate question, answered by SPF, DKIM, and DMARC, not by the account's sign-in settings. DKIM is one of those controls: it lets a receiving mail system check that a message was authorized by the sending domain and unaltered in transit, which is a domain-level property, not a mailbox-login property.

Readers who came here looking for that domain-level protection, rather than account sign-in security, want email authentication instead. To check a domain's own authentication posture, run it through the email security score checker. That check inspects published DNS records for the domain; it does not check whether any mailbox on that domain has 2FA turned on, which is an account setting, not a DNS record.