Confirm email

Problem Context

• The service has already captured an email address and must decide whether syntactic validity is enough or mailbox access must be proven.
• Confirmation may be needed for account activation, email change, invitation acceptance, recovery eligibility, sensitive notifications, legal notices, or high-impact communication.
• The user may not receive the email immediately, may have entered the wrong address, may be using a shared mailbox, or may open a link after it expires.
• Confirmation links and codes are short-lived artifacts that must not leak through logs, analytics, referrers, screenshots, or support transcripts.
• Some services can continue in a pending or limited state while confirmation is outstanding; others must block until access is proven.

Selection Rules

• Choose confirm email when the service must prove that the user can access the mailbox for account activation, recovery, sensitive notifications, invitation acceptance, or a verified contact route.
• Use email address entry when the task is collecting, formatting, validating, warning about, or reviewing the address before mailbox access is proven.
• Use account creation when the broader task is establishing a persistent account and confirm email is only one verification state inside that flow.
• Use password reset when the email message is a recovery artifact for replacing a forgotten password rather than confirming a normal contact address.
• Use two-factor authentication when an enrolled factor is needed for authentication or authorization; do not present email confirmation as equivalent to MFA.
• Decide whether the loop is blocking, non-blocking, or limited-access before designing the confirmation page.
• Show the exact email address that received the message and provide a direct way to change it when policy allows.
• Explain link or code expiry, resend timing, spam or delivery delay guidance, and what will happen after confirmation.
• Make confirmation links and codes time-limited, bound to the address and pending record, single-use where appropriate, and invalid after address change or successful confirmation.
• Use neutral activation and resend copy where account enumeration matters.
• After confirmation, update verified-email state, clear pending warnings, continue the blocked task, and notify or log according to security policy.

Required States

• Pending sent state with target email address, purpose, next step, expiry, resend, and change-address action.
• Blocking pending state where the task cannot continue until confirmation succeeds.
• Non-blocking pending state where users can continue with limited access while confirmation remains outstanding.
• Code entry state with paste support, autocomplete one-time-code when a short code is used, expiry hint, and submit control.
• Resend-limited state with server-backed wait time.
• Change-address state that invalidates previous confirmation artifacts.
• Expired link or code state with request-new-message action.
• Already-used or revoked link state with safe explanation and restart route.
• Verified state that confirms mailbox access and returns to the original task.
• Delivery trouble or support-needed state for inaccessible mailbox, delayed email, or repeated failed confirmations.

Interaction Contract

• The confirmation page states which email address is pending and why access to that mailbox is required.
• Resend, change-address, and support actions preserve the originating task or account context.
• Changing the address invalidates previous confirmation links or codes and sends a fresh confirmation to the new address.
• Expired, already-used, malformed, or revoked artifacts never show raw token values and always offer a safe next step.
• Code entry supports paste, correction, mobile keyboards, and one-time-code autocomplete when the code is short-lived.
• Confirmed state is stored separately from address syntax validity, deliverability, and account authentication.
• The loop does not expose whether another account owns the address unless the user is already in a safer authenticated route.

Implementation Checklist

• Define why email access is required, whether the loop blocks the task, the pending-state permissions, link or code expiry, resend limits, change-address behavior, and support route.
• Design sent, pending, resend-limited, changed-address, expired, already-used, malformed, verified, and delivery-trouble states.
• Bind confirmation artifacts to the email address, pending account or record, purpose, and expiry window; invalidate them after change, use, or account deletion.
• Protect links, codes, address status, and token failure reasons from logs, analytics, referrers, screenshots, support tools, and URLs.
• Use neutral copy for account activation and duplicate-account cases where account enumeration matters.
• Test delayed delivery, wrong address, resend, multiple messages, expired link, already-used link, code paste, mobile email app handoff, browser Back, deep-link return, screen readers, and high zoom.

Common Generated-UI Mistakes

• Forcing email confirmation when the service only needs a low-risk contact or receipt address.
• Hiding the email address that received the confirmation message.
• Providing no resend, change-address, expiry, or support route.
• Treating email syntax validation as verified mailbox access.
• Treating email confirmation as a second authentication factor for future sign-in.
• Letting old confirmation links remain valid after the address changes or confirmation succeeds.
• Showing raw token errors for expired or malformed links.
• Revealing account existence through activation, resend, or duplicate-address messages.

Critique Questions

• Why does this flow need proof of mailbox access rather than only a valid email address?
• Is the loop blocking, non-blocking, or limited-access, and is that visible to the user?
• Can users see and change the email address before waiting for another message?
• What happens when the email is delayed, expired, already used, opened on another device, or sent to a mistyped address?
• How are confirmation artifacts bound, expired, invalidated, and protected from leakage?
• Does any activation or resend path reveal whether an account already exists?