Two-Factor Authentication Email Template for Login Codes

A 2FA email is a one-time password (OTP) delivery message. It should optimize for fast, accurate entry while protecting the code from accidental sharing.

The code contract

• Generate the code with a cryptographically secure source.
• Set a short, server-enforced expiry.
• Bind it to the account, authentication attempt, and purpose.
• Rate-limit attempts and delivery.
• Invalidate it after successful use.
• Do not put the code in the subject line.

Template

Subject: Your {{product_name}} verification code

Preheader: This one-time code expires in {{expiration_minutes}} minutes.

Your {{product_name}} verification code is:

{{otp_code}}

Enter this code in the sign-in window. It expires in {{expiration_minutes}} minutes and can be used once.

If you did not request this code, do not share it. You can ignore this email or contact {{security_email}} if you are concerned.

{{company_name}}

Make it easy to use

Keep the code visually distinct but accessible to screen readers. Include the product name, purpose, and expiry in text. Do not rely on a screenshot or image. If the user requested a code on another device, avoid adding a link that could accidentally sign them in from the wrong context unless the product explicitly supports it.

Use a plain-text fallback with the same code and instructions. Avoid extra links that compete with the authentication task.

Retry and failure states

If a user requests a new code, decide whether only the newest code is valid. State that policy in the UI, not necessarily in every email. A wrong code should not reveal whether the account exists or which code is current.

If delivery is delayed, let the user request a new code with rate limits. Do not send an escalating stream of codes that makes the inbox unusable.

QA checklist

• The displayed code matches the server record.
• Expired and used codes fail safely.
• Rate limits work across IP, account, and device.
• The code is absent from the subject and URLs.
• The message works in plain text, dark mode, and mobile.
• Unexpected-request copy has a real security contact.

See the verification code template for signup and address-change flows.

Recovery and abuse handling

If the user cannot receive the code, provide the product’s approved recovery method rather than suggesting that support can bypass MFA by email. Rate-limit resend and verification attempts, and monitor unusual request volume without revealing whether an address has an account.

Keep the authentication email separate from product announcements. A security message should not contain cross-sells, unrelated links, or a footer that makes the code difficult to find.

Testing matrix

Test a normal login, a delayed delivery, several resends, an expired code, a wrong code, a successful code, and a request from an unfamiliar device. Verify that a successful verification invalidates older codes according to policy and that no code appears in logs or analytics URLs.

Keep authentication mail separate from marketing

The sender identity, template, and queue should make it obvious that this is a security message. Do not add recommendation modules, promotional footers, or tracking redirects that slow the code path or make a phishing message look more plausible. A plain-text version and a short, stable subject are more useful than brand-heavy design.

Use the same purpose binding in the email service and the verification endpoint. If a code was issued for sign-in, it must not authorize an email change or recovery action. If the product supports several devices, document whether a resend invalidates the previous code and expose that behavior in the sign-in UI.

Monitor abuse without account enumeration

Track unusual request volume, delivery failures, resend bursts, failed attempts, and successful verification by coarse operational dimensions. Do not put an account-existence result in the email or error page. A person who did not request a code should have a safe way to report the event without receiving instructions to share the code.

Test delayed delivery, multiple tabs, expired codes, wrong-device requests, localized code formatting, and a successful sign-in followed by an older-code attempt. The server, not the email copy, must enforce expiry, single use, and rate limits.