Email Verification Email Template for Signups and Address Changes

Verification email is a security and activation step. It should answer three questions immediately: why did I receive this, what do I click, and what should I do if I did not request it?

Use separate purposes

Do not reuse one token or one template for every verification event.

The copy should name the product and event. A user who did not request the action should not be encouraged to click.

Template

Subject: Confirm your {{product_name}} email address

Preheader: Click once to finish setting up your account.

Hello {{customer_name}},

Please confirm that {{email_address}} belongs to you so we can finish setting up your {{product_name}} account.

[Confirm email address]

This link expires in {{expiration_minutes}} minutes. If the button does not work, copy this address into your browser:

{{verification_url}}

If you did not request this, you can ignore this email. Contact {{support_email}} if you think someone is trying to use your address.

{{company_name}}

Token and link rules

• Use a random, single-use token bound to the intended account and purpose.
• Expire it after the product’s documented interval.
• Invalidate the previous token when issuing a replacement, or explicitly support a safe token family.
• Do not put sensitive profile data in the URL.
• Return a generic response when a token is invalid so attackers cannot enumerate accounts.
• Record successful verification and the source event.

Resend behavior

Resend is a product action, not a new signup. Rate-limit it, show when another email was sent, and keep the newest valid link clear. If several messages arrive, explain that only the latest link may work.

Suppress the message after verification, account deletion, or a confirmed address change. Do not send marketing content in the verification template.

Accessibility and fallback

The button should have an action label such as “Confirm email address,” not “Click here.” Include a plain-text link, sufficient contrast, readable type, and a visible support path. Do not rely on color or images to communicate the action.

QA checklist

• Expired token shows a safe recovery page.
• Used token cannot be replayed.
• Wrong account cannot consume the token.
• Resend is rate-limited and idempotent.
• The link works on mobile and in common mail clients.
• The email is sent only after the intended event.
• A user who did not request it can ignore it without losing an account.

See the verification code template for numeric one-time passwords and the magic link template for passwordless sign-in.

Variants by product moment

New account

Explain what becomes available after verification: access to the workspace, a trial, or a requested download. Do not add a promotional upsell before the person can complete the promised action.

Address change

Tell the user that the new address will replace the old one after confirmation. If the old address remains a recovery channel, explain the security consequence in the product UI rather than burying it in the email.

Double opt-in

Name the subscription topic and consent purpose. A subscriber should know whether the action confirms a newsletter, product updates, or a specific alert. Store the source, timestamp, and address that was confirmed.

Deliverability and abuse controls

Use a stable transactional sender, a recognizable From identity, and a plain-text part. Rate-limit repeated requests by account, address, IP, and device. If someone requests many tokens, keep the security response generic and route suspicious activity to abuse monitoring.

Measure completion from request to verified state, resend rate, expired-token rate, and support contacts. Do not optimize only for clicks; a click that leads to an expired token is a broken activation path.