Double opt in email: how the confirmation flow works, and why the friction is worth it

A double opt in email is the message sent to a new subscriber immediately after they sign up, carrying a link they have to click before they are added to a list. The first opt-in is the form. The second is the click. Only the second one proves that the person who controls the inbox, rather than whoever typed the address, wants the mail.

The same flow goes by the names double opt-in and confirmed opt-in; some mailbox providers prefer the second because it says what the flow does. Whatever you call it, the shape is fixed: collect an address, send one confirmation, wait for the click, and only then record the subscription. Everything else in this post is the detail of doing those four things so that the record you end up with will stand up later.

It matters because a list is only as good as the worst address on it. A typo, a prank sign-up with a stranger’s address, a bot filling in forms — every one of those becomes a bounce or a complaint the first time you broadcast, and reputation is scored on exactly those two things. The confirmation step is a filter that runs before the damage rather than after it.

Single opt-in is the form alone: submit, and you are on the list. It is simpler and it grows a list faster, and both of those are true right up until the first campaign.

The middle row is the one that decides it. Under single opt-in the list carries every mistake the form accepted, and you discover them as bounces during a broadcast, which is the worst possible moment. Under double opt-in the mistakes stay in a pending table you never send to. Hard bounces from a newsletter are almost always addresses that should never have been on it.

Five moves, and two of them are API calls. The first sends one transactional email; the second records the consent on the contact. Nothing about the flow is specific to a framework, so the samples are plain Node with fetch.

1. Collect the address into a pending table — Take the address from your form and write it to a pending row on your side, with the time and the source. Do not create a contact yet: an unconfirmed address has no consent to record.
2. Send one confirmation email with a signed link — Sign an HMAC over the address and an expiry with a secret only your server holds, put the token in a link, and send it through POST /emails with an Idempotency-Key of confirm-<contactId> so a retried submission cannot send two.
3. Verify the click and record the opt-in on the contact — On the confirm route, recompute the MAC, compare it in constant time and check the expiry. Then POST /contacts with topics: [{ id, subscription: "opt_in" }], which writes a consent record with its source and time.
4. Store the proof on your side too — Write your own row with the confirmation time, the IP address and the user agent against the contact id. The consent ledger says when; your row says from where, and you want both.
5. Only then let the contact into a segment — A segment is a filter evaluated when a broadcast sends, so a contact that exists is one filter away from being mailed. Create the contact only after the click, and keep the pending table outside the audience.

import { createHmac } from "node:crypto";
const SECRET = process.env.CONFIRM_SECRET!;const TTL_MS = 48 * 60 * 60 * 1000; // 48 hours
export function confirmationToken(email: string, expiresAt: number): string {  const payload = Buffer.from(JSON.stringify({ email, expiresAt })).toString("base64url");  const mac = createHmac("sha256", SECRET).update(payload).digest("base64url");  return `${payload}.${mac}`;}
/** contactId is the id of the pending row you wrote when the form was submitted. */export async function sendConfirmation(contactId: string, email: string): Promise<string> {  const token = confirmationToken(email, Date.now() + TTL_MS);  const url = `https://acme.example/confirm?token=${encodeURIComponent(token)}`;
  const response = await fetch("https://api.rasket.com/emails", {    method: "POST",    headers: {      authorization: `Bearer ${process.env.RASKET_API_KEY}`,      "content-type": "application/json",      "user-agent": "acme-billing/1.0",      "idempotency-key": `confirm-${contactId}`,    },    body: JSON.stringify({      from: "Acme <news@send.acme.example>",      to: [email],      subject: "Confirm your subscription to Acme news",      html: `<p>You asked to hear from us. <a href="${url}">Confirm your subscription</a>.</p><p>If this was not you, ignore this message and nothing will be sent.</p>`,      text: `You asked to hear from us. Confirm here: ${url}\n\nIf this was not you, ignore this message.`,    }),  });
  if (!response.ok) throw new Error(`confirmation send failed: ${response.status}`);  const { id } = (await response.json()) as { id: string };  return id;}

import { createHmac, timingSafeEqual } from "node:crypto";
const SECRET = process.env.CONFIRM_SECRET!;const TOPIC_ID = process.env.NEWSLETTER_TOPIC_ID!;
function verifyToken(token: string): string | null {  const [payload, mac] = token.split(".");  if (!payload || !mac) return null;
  const expected = createHmac("sha256", SECRET).update(payload).digest("base64url");  const given = Buffer.from(mac);  const wanted = Buffer.from(expected);  if (given.length !== wanted.length || !timingSafeEqual(given, wanted)) return null;
  const { email, expiresAt } = JSON.parse(Buffer.from(payload, "base64url").toString());  return expiresAt > Date.now() ? email : null;}
export async function confirm(token: string, proof: { ip: string; userAgent: string }) {  const email = verifyToken(token);  if (email === null) return "expired_or_invalid";
  const response = await fetch("https://api.rasket.com/contacts", {    method: "POST",    headers: {      authorization: `Bearer ${process.env.RASKET_API_KEY}`,      "content-type": "application/json",      "user-agent": "acme-billing/1.0",    },    body: JSON.stringify({      email,      topics: [{ id: TOPIC_ID, subscription: "opt_in" }],    }),  });  if (!response.ok) throw new Error(`contact write failed: ${response.status}`);  const { id } = (await response.json()) as { id: string };
  // Your own copy of the proof: when, from where, with what.  await db.consent.insert({    email,    contactId: id,    confirmedAt: new Date(),    ip: proof.ip,    userAgent: proof.userAgent,  });  return "confirmed";}

This is not legal advice, and consent rules differ by country. What follows is the shape of the two requirements a developer building the flow is most likely to be asked about.

Some share of sign-ups will not click. Some were typos, some were bots, some were real people who lost interest between the form and the inbox. The rule for all of them is the same: they are not subscribers, and the pending table must never be mailed.

• Expire the token. Forty-eight hours is a common window. After it, the link fails with a plain message and an offer to sign up again, which sends a fresh confirmation with a fresh token.
• One reminder, at most. A second confirmation a day or two later, keyed confirm-<contactId>-2 so it cannot double either, is defensible. A third message is a newsletter to someone who has now twice declined to confirm.
• Never add them. Not to a segment, not to a “maybe” topic, not with opt_out as a placeholder. An address with no confirmation has no consent to record, so there is nothing to write. Delete the pending row after the window closes.

The reason the pending list must stay out of reach is structural rather than moral. A segment is a filter evaluated when a broadcast sends, so a contact that exists at all is one filter change away from being mailed. The safest place for an unconfirmed address is outside the audience entirely, in a table the broadcast pipeline cannot see. Once the click arrives, the contact is created with its opt_in and becomes eligible for the segments broadcasts target — and sending the newsletter itself is a separate post.