# Double Opt-In Email Workflow for Subscription Teams > Design and QA confirmation emails in Figma so consent requests stay clear, accessible, and connected to the subscription state. - Canonical page: https://www.hypermatic.com/articles/emailify-double-opt-in-email-workflow-for-subscription-teams/ - Published: 2026-08-14T00:00:00.000Z - Updated: 2026-08-14T00:00:00.000Z Someone enters an email address in a newsletter form. The next message is not a welcome email yet. It is a request to confirm that the address belongs to them and that they want the subscription. That small distinction should shape the entire email. A double opt-in message needs one unmistakable action, enough context to establish trust, and a safe path for someone who never requested it. [Emailify](/emailify/) helps teams design, preview, and export production-ready HTML from Figma. The consent model, legal requirements, token behavior, and subscriber-state logic still need approval from the people who own them. ## Map the state transition first Write the lifecycle as states before writing copy: `submitted → pending confirmation → confirmed → subscribed` Also define exceptions: - address already subscribed - link expired - link already used - request initiated by someone else - delivery delayed or bounced - preference changed after confirmation This prevents the design team from treating the email as a standalone campaign. Its copy and CTA must match what the backend will actually do. The [lifecycle email workflow](/articles/emailify-lifecycle-email-workflow-for-marketing-ops-teams/) covers broader programs, while the [HTML email compliance review workflow](/articles/emailify-html-email-compliance-review-workflow/) covers campaign-wide review. This article focuses on the single consent checkpoint between form submission and an active subscription. ## Keep the message narrowly transactional The recipient should understand three things immediately: 1. what request was made 2. what clicking the button will do 3. what to do if they did not make the request A useful structure is: - sender and list identity - “Confirm your subscription” heading - one sentence explaining where the request started - primary confirmation button - plain-language expiry or security note if applicable - ignore/help guidance - required sender and preference information Avoid competing promotional cards, secondary offers, or several equally prominent links. The confirmation action should not be disguised as a generic “Continue.” Use specific button copy such as “Confirm my subscription,” subject to the approved consent language. ## Design trust into the first screen Recipients are cautious around unexpected verification emails. Keep the recognizable sender, request context, and primary action visible without forcing them to scroll. Use a real text heading rather than placing the entire message in an image. Make the button large enough for touch, give it strong contrast, and include a meaningful linked-text fallback if the platform supports one. Do not expose long raw tokens in a way that makes the message hard to scan. Set the subject line and preheader as a pair. The subject can identify the action; the preheader can explain the list or request. Do not let template filler become the preheader in the inbox. ## Define dynamic content and link behavior Create a handoff table for every variable: - sender or brand name - list, publication, or preference name - confirmation URL - expiry window, if shown - support URL - subscriber address, if shown For each variable, define an example, maximum expected length, escaping rules, and fallback. Test a long brand name and localized copy rather than only the shortest happy path. The confirmation URL needs its own QA plan. Confirm whether it is single-use, when it expires, what page it opens, and what happens after an invalid click. Tracking and link rewriting must not break the token. Those are delivery-system checks, not properties a Figma preview can prove. ## Build the companion states The email is only one part of the experience. Design or document: - pending-confirmation page after form submission - successful confirmation page - expired-link page and resend path - already-confirmed response - “not me” or ignore guidance Copy should agree across every state. If the email says a link expires in one hour and the error page says 24 hours, the workflow loses credibility. Use [Emailify](/emailify/) to preview the real HTML structure on desktop and mobile. For a deeper mobile pass, use the [mobile email QA workflow](/articles/emailify-mobile-email-qa-workflow-before-export/). ## Test the actual delivery path After export, upload the template to the target email platform and send test messages through the real trigger. Check: - sender name, reply-to address, subject, and preheader - merge variables and fallback values - button and fallback-link destinations - expired and repeated clicks - focus visibility, alt text, and readable text scaling - dark mode and the email clients that matter to the audience - the subscriber record before and after confirmation Do not mark the workflow complete because the HTML looks correct in a browser. The important proof is that a pending address becomes subscribed only through the intended action and receives the correct next experience. ## Release checklist - Consent and disclosure wording has the required approval. - The email asks for one clear action and avoids competing promotion. - Sender and list context are immediately recognizable. - Every variable has a realistic fallback and length test. - The token survives the target platform's tracking behavior. - Expired, reused, and unsolicited-request paths are understandable. - HTML has been checked on relevant clients and mobile widths. - Subscriber-state changes were verified end to end. A strong double opt-in email is intentionally uneventful. It makes the requested choice obvious, protects people who did not request it, and hands a confirmed subscriber into the right next state without ambiguity.