Guide
Double opt-in is a subscription process where a recipient enters their email address, then confirms it by acting on a message sent to that address. The subscription is only recorded once that second step is completed. Single opt-in records the subscription immediately, with no verification that the address belongs to the person who entered it.
Last reviewed September 2026
The two models
Neither model is simply better. Single opt-in grows a list faster and removes a step where people drop out, and for a low-risk newsletter with a low-value address it is a defensible choice. Double opt-in trades some of that growth for a verified address and a consent record you can defend. What follows is the trade, stated plainly rather than argued in one direction.
| Single opt-in | Double opt-in | |
|---|---|---|
| What records the subscription | Submitting the form | Acting on the confirmation message sent to the address |
| Address ownership verified | No | Yes - the confirmation only reaches the real mailbox |
| Catches typos | No - a mistyped address is added and mailed indefinitely | Yes - a mistyped address never confirms |
| Catches hostile or third-party signups | No - anyone can subscribe anyone | Yes - the address owner has to act |
| Initial list growth | Faster - every submission counts | Slower - a share of submissions never confirm |
| Engagement and complaint rates over time | Diluted by unverified and unengaged addresses | Higher engagement, lower complaints, on a smaller list |
| Spam trap exposure | Higher - recycled and typo addresses enter the list | Lower - unconfirmed addresses never enter it |
| Strength of the consent record | A form submission, from an unverified source | A form submission plus a confirming action from the address itself |
| Where it fits | Low-risk newsletters, low-value addresses, jurisdictions with a low evidential bar | Anything with a compliance exposure, a paid acquisition cost, or a deliverability reputation to protect |
Most writing on this subject overstates the legal position, so it is worth being precise. The GDPR does not mandate double opt-in. The phrase does not appear in the regulation. What the regulation does is define what consent has to be, and then put the burden of proving it on you.
Article 4(11) defines consent as "any freely given, specific, informed and unambiguous indication of the data subject's wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her". Recital 32 adds the negative case: silence, pre-ticked boxes and inactivity do not constitute consent.
Article 7(1) is the sentence that decides how you should build your signup form: "Where processing is based on consent, the controller shall be able to demonstrate that the data subject has consented to processing of his or her personal data." The obligation is evidential. It is not enough that the person consented; you have to be able to show it.
That is the whole argument for double opt-in, and it is a practical argument rather than a legal one. A single opt-in record proves that a form was submitted from somewhere with a particular address typed into it. It does not connect that submission to the person who owns the address. A double opt-in record adds an action taken from inside the mailbox itself, which is the piece that makes the record hold up.
No jurisdiction names double opt-in in statute. Germany comes closest in practice: the Federal Court of Justice ruled in BGH I ZR 164/09 of 10 February 2011 that the sender carries the burden of proving valid prior consent for every commercial message, and German courts have consistently treated a bare form submission as insufficient to discharge it. The result is a jurisdiction where double opt-in is not legally mandated and is nonetheless the only approach that reliably survives a challenge. Several other European regulators take a similar line in guidance without writing it into law.
Outside the EU the picture differs. Canada's CASL requires express consent but does not specify how it is obtained. The US CAN-SPAM Act requires no opt-in at all, only a working opt-out. A sender operating across all three is in practice building to the strictest of them, which is why GDPR-grade consent handling tends to become the house standard rather than a regional variant.
A consent record is only as good as what is in it. At minimum, capture and retain:
That last item matters more than it looks, and the next section is why.
A double opt-in record is stronger than a single opt-in record because it contains an action taken from the recipient's mailbox. That reasoning holds only for as long as the action was taken by the recipient. Very often it was not.
The chain is short and each link is well documented:
Mimecast, Proofpoint, Barracuda and Microsoft Defender for Office 365 extract every URL from an inbound message and visit each one to check it for malware and phishing. That happens before the recipient sees the message, and often whether or not they ever open it. The industry term for the resulting events is Non-Human Interactions, or NHI.
Security products do make an effort to recognize these links and leave them alone. They fail regularly. In practice both link types are followed by automated systems every day, which is not a controversial claim among deliverability practitioners so much as a routine one.
The one-click unsubscribe standard requires the action to run on an HTTPS POST rather than a GET, precisely because an automated fetch that follows links cannot complete a POST by accident. The reasoning is spelled out in the List-Unsubscribe header guide.
There is no equivalent standard. Confirmation links are almost universally plain GET URLs that record the consent on page load, which is exactly the shape RFC 8058 exists to prohibit at the other end of the lifecycle.
The same infrastructure RFC 8058 was written to defend against follows the confirmation link and completes the opt-in. Nobody consented to anything.
A scanner-triggered unsubscribe costs you a recipient, which is a real loss and a visible one. A scanner-triggered confirmation costs you something harder to account for:
Worth naming the asymmetry plainly: the standards body mandated protection for opting out and left opting in exposed, even though the compliance consequence of a false opt-in is larger than that of a false opt-out.
The fix is not to detect the scanner. It is to build a confirmation step that a link fetch cannot finish. One rule covers it:
A GET request should render a confirmation page. Only a subsequent POST from that page should record consent.
The same principle RFC 8058 applies to unsubscribes, applied to the opposite end of the subscription lifecycle.
The confirmation step is where the defensible part of the consent record is created, so capture what makes it defensible: the timestamp, the IP address, the user agent, and specifically the fact that the confirmation was completed by an interaction rather than by a page load. A record that says "a POST arrived from this address after a checkbox was ticked" answers a challenge. A record that says "the confirmation URL was requested" does not.
The automated activity that corrupts a consent record is the same activity that inflates open and click rates. It is one phenomenon with two consequences, and most senders only ever notice the reporting one. The State of Email Bots 2026 puts roughly half of B2C opens and about 16% of B2C clicks in the non-human column, with corporate link scanning accounting for the overwhelming majority of clicks on B2B traffic.
Classifying interactions as human or non-human lets a sender tell a scanner-generated confirmation from a real one, and audit a list that was built before anyone was watching for this. That is what the Bot Detection API does, and it is genuinely useful for the retrospective question: which of the consents already in the database are real.
It is corroboration, not the fix. The fix is the confirmation page design above, because a confirmation that cannot be completed by a link fetch does not need to be classified afterward. Build the page correctly first, then use classification to check the list you already have.
At a glance
Questions
Double opt-in is a subscription process with two steps. The recipient enters their email address on a form, then confirms it by acting on a message sent to that address. The subscription is only recorded once the second step is completed. Because the confirmation can only be completed from the mailbox itself, it verifies that the address is real and that its owner agreed to be subscribed.
Single opt-in records the subscription the moment the form is submitted. Double opt-in records it only after a confirmation sent to the address is acted on. The practical difference is verification: single opt-in cannot tell whether the address belongs to the person who typed it, so typos, hostile signups and mistyped addresses all enter the list. Single opt-in grows a list faster; double opt-in produces a smaller list with higher engagement, lower complaint rates, less spam trap exposure and a consent record that can be defended.
No. Double opt-in is not named anywhere in the GDPR. What the regulation does is define consent in Article 4(11) as a freely given, specific, informed and unambiguous indication of the person's wishes given by a clear affirmative action, and then place the burden of demonstrating that consent on the controller in Article 7(1). Double opt-in is not a legal requirement; it is the most reliable way to meet that evidential burden, because it produces a record showing the address owner acted.
No jurisdiction names double opt-in in statute. Germany is the closest thing to an exception in practice: the Federal Court of Justice ruled in BGH I ZR 164/09 of 10 February 2011 that the sender carries the burden of proving valid prior consent for every commercial message, and German courts have consistently treated a bare form submission as insufficient. So it is not mandated and is nonetheless the only approach that reliably survives a challenge there. Canada's CASL requires express consent without specifying how it is obtained, and the US CAN-SPAM Act requires no opt-in at all, only a working opt-out.
Yes, and it happens routinely. Corporate email security products follow the links in inbound messages to check them for malware and phishing, before the recipient sees the message. Opt-in confirmation links are almost always plain GET URLs that record the consent on page load, so the scanner's check completes the confirmation. Security vendors do make an effort to recognize opt-in and unsubscribe links and leave them alone, and they get it wrong regularly.
Make the link render a page rather than perform the confirmation. The page should require a deliberate action before the opt-in is recorded: a checkbox and a submit button, a CAPTCHA and a confirm button, or any equivalent interaction an automated link fetch cannot complete. As a rule, a GET request should render the confirmation page and only a subsequent POST from that page should record consent. User-agent detection, delaying the write and blocking security vendor IP ranges all fail, because scanners present ordinary browser user agents, revisit links, and share address space with genuine corporate recipients.
No. Consent under Article 4(11) requires a freely given, specific, informed and unambiguous indication of the person's wishes given by a clear affirmative action, and Article 7(1) puts the burden of demonstrating it on the controller. A confirmation generated by a security scanner is none of those things. The record will look entirely valid in a database, which is what makes it dangerous: it is indistinguishable from a genuine confirmation, and it will not survive being challenged.
To check where the links go. A corporate email gateway receives a message, extracts every URL from it, and visits each one to see whether it leads to malware or a phishing page. That check has to happen before the recipient can click, so it runs on delivery, often whether or not the message is ever opened. It is the security product doing the job it was bought for, which is also why the traffic cannot simply be blocked: the scanner belongs to your recipient.
It reduces the recorded subscriber count, because a share of people who submit the form never complete the confirmation. Whether that counts as harm depends on what those addresses were worth. Unconfirmed addresses include typos that will never deliver, addresses entered by someone other than their owner, and people who lost interest between the form and the inbox. Removing them lowers the headline number and raises engagement, complaint and deliverability metrics on what remains. For a list with an acquisition cost attached to it, the honest comparison is confirmed subscribers against confirmed subscribers, not raw signups.
The timestamp and IP address of the original form submission, the timestamp and IP address of the confirmation, the specific form or source the submission came from, the exact wording the person consented to as it appeared at the time, and the nature of the confirming interaction. That last item is what separates a defensible record from a weak one: "a POST arrived after a checkbox was ticked" answers a challenge in a way that "the confirmation URL was requested" does not.
There is no legal deadline, and the trade-off runs in both directions. A short window keeps the consent contemporaneous with the request, which is the position a regulator would prefer, but it discards genuine confirmations from people who read their mail on a delay. A common practice is between 24 hours and 7 days, with 48 to 72 hours a reasonable default. What matters more than the specific number is that the link expires at all, that the token is unique per subscription and hard to guess, and that an expired link leads to a page offering to send a fresh confirmation rather than a dead end.
The legal position here is quoted from the regulation itself rather than paraphrased, because most writing on this subject overstates what the GDPR requires.
This page covers the opt-in end of the subscription lifecycle. The opt-out end has the same problem and a standard that solved it.
The same automated activity that inflates your open and click rates also writes consent records nobody agreed to. Bot Detection classifies the interactions; GDPR-grade infrastructure keeps the rest of the sending defensible.