Monitoring Double Opt-In: When Confirmation Mail Stalls

Why the confirmation flow deserves its own measuring point

From an operations point of view a signup is a process with a single visible result: the form answers, the visitor sees the notice about the confirmation mail, the counter goes up by one. Everything after that happens outside your own site. The message enters a queue, moves from there to a sending path, and from there to a mailbox that may accept it, delay it or sort it out. If it stalls on the way, that produces no error page and no entry in the website error log. The process looks successful on both ends although it broke in the middle. How the visible part of such a chain can be checked is described in the article Monitoring contact form delivery; the confirmation flow attaches a second, considerably longer half to it.

This second half carries the legal weight of the whole process. Under Article 4 no. 11 GDPR, consent is any freely given, specific, informed and unambiguous indication of the data subject's wishes by which they signify agreement through a statement or a clear affirmative action (GDPR). Recital 32 of the Regulation states explicitly what does not qualify: silence, pre-ticked boxes or inactivity should not constitute consent (GDPR). Article 7(1) requires the controller to demonstrate that consent was given (GDPR), and Article 5(2) turns this into a general accountability duty (GDPR). The click on the confirmation link is the affirmative action this chain calls for, and at the same time the point at which the evidence either comes into being or fails to.

• Section 7(2) no. 2 UWG: Advertising using electronic mail without prior express consent of the addressee counts as an unreasonable nuisance (UWG).
• Article 4 no. 11 GDPR: Consent is a freely given, specific, informed and unambiguous indication of wishes in the form of a statement or a clear affirmative action (GDPR).
• Recital 32 GDPR: Silence, pre-ticked boxes or inactivity of the data subject should not constitute consent (GDPR).
• Article 7(1) GDPR: The controller must be able to demonstrate that the data subject has consented (GDPR).
• Article 5(2) GDPR: The controller is responsible for compliance with the principles and must be able to demonstrate it, the so-called accountability duty (GDPR).
• Article 7(3) GDPR: Withdrawing consent must be as easy as giving it (GDPR).

Between a signup and a demonstrable signup lies exactly one delivered and clicked message. Anyone who only evaluates the number of submitted forms is measuring intent rather than outcome. The gap between those two numbers is the actual key figure of this flow, and it behaves differently from a form abandonment rate: abandonment inside the form happens in front of the visitor and can be traced through field-level analysis, as described in the article Reducing form abandonment with form analytics. Abandonment in the confirmation flow happens inside someone else's mailbox and leaves no trace on your own site.

Where the flow typically tears

The flow consists of five stations, and each of them can fail on its own without disturbing the others. First, the form accepts the input and answers with a status code. Second, the application creates a record with a token, a timestamp and the wording of the consent. Third, it hands the message over to the sending path, which accepts or rejects it. Fourth, the recipient's mail server delivers, delays or rejects for good. Fifth, the recipient clicks the link and the status switches to confirmed. Monitoring that only checks the first station reports green as long as the form answers, even when no confirmation at all has arrived for days.

The most frequent tears are in the middle. A worker process that drains the queue and was not restarted after a release keeps accepting jobs and processes none of them. An access key for the sending path expires, and every handover acknowledges an error nobody reads. A changed sender address falls out of authentication and lands in the spam folder. A subject line that lost its character encoding during a migration looks like data garbage in the mailbox and gets deleted unread, a failure pattern the article Finding broken umlauts after a migration shows in other places. And the confirmation link itself may have expired before the recipient next opens their mailbox.

The five measuring points

Five stations produce five measuring points, and they do not all sit in the same area of responsibility. The first two belong to your own application, the third to the handover to the sending path, the fourth to a foreign system and the fifth again to your own application. Usable monitoring reflects this distribution instead of laying a single check across the whole chain. Only if the failure of a station can be named does the alert lead to an action rather than to a search.

1. Form response: The signup path is walked in a real browser until the page with the notice about the confirmation mail appears. Status code, response time and the presence of the notice text are measured. A form that answers with status code 200 while displaying an error message shows up only in this check.
2. Record: After the signup, an entry exists with a token, a timestamp, an origin and the wording of the consent. The check confirms that the entry was created and that its status is pending. If it is missing, the application accepted the input and discarded it.
3. Handover to the sending path: The sending service acknowledges acceptance with an identifier. This acknowledgement is the first hard proof that the message left your own system. Without it, the job is sitting in the queue, and then the length of that queue is the value that has to be measured.
4. Delivery: The recipient's mail server accepts, delays or rejects. Temporary rejections with a status code in the 4xx range are part of normal operation and get retried, final rejections in the 5xx range are not. A rising number of final rejections points, in our experience, to a problem with authentication or the sender address rather than to wrong recipient addresses.
5. Confirmation click: The status switches from pending to confirmed. This switch is the only measuring point that evidences an action by a human being, and the only one that carries the demonstration required by Article 7(1) GDPR (GDPR).

The first and the fifth point can be checked from outside: both are addresses on your own website and can be walked with a browser check. Points two to four sit on the inside and need either an interface that reports the state or a signal that the application sends of its own accord. Neither is much effort. An endpoint returning the number of open signups, the age of the oldest open signup and the length of the sending queue covers points two and three. For point four, evaluating the responses of the sending path is sufficient in many cases.

Check intervals and the deadlines behind them

An interval answers the question of how often something is measured. A deadline answers the question of when a deviation becomes an incident. In the confirmation flow the two are far apart, because one part of the chain is slow by nature. The form path can be checked every minute; whether a confirmation is missing can be judged at the earliest after a deadline that matches the retry rules of mail servers. Treating both as the same thing produces either false alarms or a detection that arrives two days late.

The deadline in the second-to-last row is the only value in this table that cannot be chosen freely without ignoring the technology behind it. Why it sits in the order of hours rather than minutes is explained further down in the section on retry rules. Everything else is a question of operations: a mailing list that receives two signups a month does not need an hourly rate evaluation but a check that fires when the single signup of the week stays unconfirmed.

What the flow can be monitored with

Four types of check together cover the five measuring points. None of them is new in itself, the combination is: the browser takes the visible ends, the interface check takes the handover, the heartbeat takes the silent worker process and the alerting takes the deadline.

What cannot be mapped this way is the route inside the foreign mailbox. Whether a message sits in the inbox or in the spam folder is invisible to the sender. The approximation for it is the share of confirmed signups over time: if it falls without anything having changed in the form and in the text of the message, the cause lies with some probability in delivery. That is not a measurement but an indication, yet an indication that arrives early enough to check authentication.

Calculating the confirmation rate correctly

The share of confirmed signups looks like a simple division and is nevertheless regularly wrong for the current hour. Anyone who divides all signups of a period by all confirmations of the same period counts signups whose confirmation is not even due yet. The rate of the last hour then sits structurally low, the rate of the previous day recovers on its own, and an alert on this value fires every evening. The calculation therefore needs a maturity period: only what is older than the deadline within which a confirmation is expected gets counted.

// Share of clicked signups: only mature cases are counted.
// A signup is mature once its confirmation deadline has passed.
function clickedShare(signups, deadlineHours, now = Date.now()) {
  const deadline = deadlineHours * 3600 * 1000;
  const mature = signups.filter((s) => now - s.createdAt >= deadline);

  if (mature.length === 0) return null;   // no measurement, not 0

  const open = mature.filter((s) => s.clickedAt === null);
  const clicked = mature.length - open.length;

  return {
    population: mature.length,
    clicked,
    share: clicked / mature.length,
    openMaxDays: open.length
      ? Math.max(...open.map((s) => (now - s.createdAt) / 86400000))
      : null
  };
}

Two values fall out of this, and both belong on the dashboard. The share shows whether the flow carries overall; the age of the oldest open signup shows whether it is stalled right now. The second value reacts faster: if sending stalls, it grows steadily from the first open signup onwards, while the share only tips once enough cases have passed the deadline. An alert on the age of the oldest open signup is therefore usually the more usable first stage, and the share the second, slower confirmation of the same fault.

A confirmation mail that nobody misses is the quietest failure in the stack. It costs no error page, no phone call and no complaint, only every consent that should have come into being during that time.

— XICTRAQ

What the mailbox providers require

Technically, the confirmation mail is a message like any other and falls under the same rules as the mailing list it opens access to. Since 1 February 2024, Google requires all senders sending to Gmail accounts to meet a catalogue of requirements (Gmail); anyone sending more than 5,000 messages per day to Gmail accounts has additionally fallen under an extended section since the same date (Gmail). What follows from this for ongoing sending is set out in the article Deliverability rules for bulk email. For the confirmation flow, four points matter most.

• Complaint rate below 0.3 percent: For the spam rate reported in Postmaster Tools, Google names an upper limit of 0.3 percent (Gmail). Confirmation mails are marked as unwanted less often than a mailing list, but they count towards the same rate.
• Authentication of the sender domain: SPF, DKIM and DMARC belong in place and monitored before the mailing list grows. The procedure is described in the article Setting up SPF, DKIM and DMARC; what gets monitored is not only whether the records exist but whether they match the address actually sending.
• One-click unsubscribe: For marketing and subscribed messages, Google requires one-click unsubscribe plus a clearly visible unsubscribe link in the message body in the section for senders of more than 5,000 messages per day (Gmail). Technically, RFC 8058 describes a List-Unsubscribe-Post header field with the value List-Unsubscribe=One-Click for this (RFC 8058).
• Reputation of the sending address: If the IP address or the domain of the sending path is on a blocklist, the confirmation mail is hit first, because it goes to a mailbox that does not know the sender yet. How this can be checked continuously is described in the article Blacklist monitoring for email deliverability.

Checking the flow from outside

Before monitoring is set up, a look from outside with simple means is worthwhile. Four calls are enough to establish whether the flow answers at the intended places at all: the form, the state endpoint, the authentication of the sender domain and the page behind the confirmation link. The addresses in the following example sit on a domain that demonstrably belongs to nobody.

The last call is the most revealing one. An expired or invented token should produce a designed page with a clear message, not a server error and not an empty page with status code 200. The second call also shows how little it takes to make the inner stations measurable from outside: three numbers and a timestamp. If this endpoint is fed by an external sending service, it is worth watching whether its interface announces a retirement; how that can be detected automatically is described in the article Monitoring sunset and deprecation headers.

Why delivery takes time

A mail server that cannot get rid of a message right away does not throw it away but tries again. RFC 5321 recommends at least 30 minutes between two attempts and points out at the same time that a more refined strategy is beneficial when the reason for non-delivery is known (RFC 5321). For monitoring this means: a confirmation mail that is not in the mailbox after ten minutes is not an incident but a normal intermediate state. An alert on this state produces a notification nobody can act on, and trains the on-call rotation to skip notifications of that kind.

At the other end sits the give-up time. According to the same passage in RFC 5321, retries continue until the message is transmitted or the sender gives up, with the give-up time generally needing to be at least four to five days (RFC 5321). Two decisions follow from this. First, the confirmation link should stay valid considerably longer than that span, otherwise it expires while the message is still in transit. Second, the alert deadline for missing confirmations belongs in the order of hours up to one day: short enough to notice a stalled dispatch on the same working day, long enough not to report the normal retry as a fault.

What has to remain documented

Monitoring that notices the failure does not replace documentation of what worked. Article 7(1) GDPR requires demonstrating consent (GDPR), Article 5(2) turns this into the controller's accountability duty (GDPR). In practice this means the record has to describe the process in such a way that it remains comprehensible years later without knowledge of the system of the time. What gets stored for this belongs in the record of processing activities and in the privacy notice; the following list is a technical recommendation and does not replace legal advice.

• Time of the signup and of the confirmation, each with a time zone and in machine-readable form.
• The wording of the consent, not just a reference to the page. The text changes, the record should hold the state at the time of the signup.
• The identifier of the form and of its version, so that it can later be attributed which version was actually shown to the visitor.
• The identifier of the sent confirmation mail including the acknowledgement of the sending path, so that the route between signup and click is demonstrable.
• Origin data to the extent covered by your own privacy notice, for example a truncated IP address. What is not announced is not stored either.
• Withdrawal and unsubscribe with time and route, because otherwise the stack only knows the granting and not the end of the consent.

Rolling it out in two weeks

In the first week the measurement basis is created. This includes a state endpoint returning the number of open signups, the age of the oldest open signup and the length of the sending queue, a heartbeat from the process that drains the queue, and a test address in a dedicated mailbox. In parallel, the signup path is walked once completely by hand while recording how long each step takes. This measurement supplies the number from which the confirmation deadline is derived later, instead of estimating it.

In the second week the checks are set up and the deadlines are configured: browser check on the signup path, interface check on the state endpoint and the confirmation page, heartbeat with an expectation, two alert stages with different deadlines. Finally the chain is deliberately broken once, for example by stopping the worker process, and it is verified that the alert arrives and that somebody picks it up. Anyone touching the signup path anyway should check the consent layer of the page in the same pass, because it technically affects the signup path; how to implement it cleanly is described in the article Implementing cookie consent correctly.