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 on every axis. 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.
The industry position is not neutral, though, and it is worth knowing before reading the table as a toss-up. M3AAWG's Sender Best Common Practices, version 4.0 of August 2026, ranks three levels of opt-in in ascending order: single opt-in, single opt-in with a notification message ("Better"), and confirmed opt-in ("Best"). Confirmed opt-in is its own term for double opt-in, and it calls it "the highest standard opt-in best practice". Of the first level it says only that it "should be used with extreme caution as it allows unconfirmed addresses to be added to mailing lists".
| 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 M3AAWG places it | Level 1, to be used "with extreme caution" | Level 3, "the highest standard opt-in best practice" |
| 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:
M3AAWG's Sender Best Common Practices asks for substantially the same set and adds the reason to hold it in a retrievable form rather than a defensible one: the record "should be easily accessible should there be a requirement to prove consent to an individual, ISP, or RBL operator or regulator". A regulator is the case most consent writing anticipates. The other three are the ones that actually turn up first, and none of them will wait while somebody queries a database by hand. It also notes what should be obvious and often is not: the laws governing storage of personal data apply to the consent record itself.
That last item in the list 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 problem above is a machine completing a confirmation nobody asked for. This one runs the other way, and it is the part of double opt-in that its advocates tend not to mention.
M3AAWG's Sender Best Common Practices, version 4.0, describes list bombing as a script "filling out hundreds of subscription forms to one email address". The resulting confirmation messages, subscription notifications and transactional mail "overwhelm the victim's mailbox and cause it to cease functioning for an extended period". It is usually cover for something else: a fraud alert or a password reset notification buried under thousands of individually legitimate messages while the actual attack proceeds.
The uncomfortable part is that the confirmation message is the payload. A signup form that emails a confirmation to any address typed into it is a free, well-authenticated, reputable mail cannon aimed wherever an attacker likes. Building double opt-in properly does not reduce this exposure. The confirmation step is precisely the thing being conscripted.
M3AAWG also names why nobody notices: "Many times a single form is not abused in a significant way on its own, but as part of a massive subscription effort across hundreds of websites at the same time. The impact is exponential. This process makes it harder for a single company to recognize they are part of the problem." Your form contributes a handful of messages to somebody's bad week. Nothing in your own metrics looks wrong.
These are M3AAWG's countermeasures. The document is explicit that they work in combination rather than individually, and that the list is not exhaustive.
firstname, lastname and email. M3AAWG's own suggestion is to use something like First_Banana and Em_Orange instead, which feels silly and works because the automation is pattern-matching on common names.Several of those are the same idea as the fix for scanner-confirmed opt-ins one section down: make the action depend on something an automated client cannot supply. The honeypot and the timing check do for the signup form what requiring a POST does for the confirmation link.
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 POST rule fixes the part everybody gets wrong. M3AAWG's Sender Best Common Practices sets out the rest of it, and each level of its opt-in ladder inherits the one below, so a confirmed opt-in flow is expected to include all of this:
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.
Yes, and it is ranked rather than merely endorsed. M3AAWG's Sender Best Common Practices, version 4.0 of August 2026, sets out three ascending levels of opt-in: single opt-in; single opt-in with a notification message, which it labels "Better"; and confirmed opt-in, which it labels "Best" and describes as "the highest standard opt-in best practice". Confirmed opt-in is its term for double opt-in, also called closed-loop subscription. Of single opt-in it says only that it "should be used with extreme caution as it allows unconfirmed addresses to be added to mailing lists". Note this is an industry position rather than a legal one: no statute mandates double opt-in, which is a separate question covered above.
List bombing is an attack in which a script submits one victim's address to hundreds of subscription forms at once, so the resulting confirmation messages, subscription notifications and transactional mail overwhelm the mailbox and, in M3AAWG's words, "cause it to cease functioning for an extended period". It is usually cover for something else, burying a fraud alert or a password reset under thousands of individually legitimate messages. Double opt-in does not cause it, but the confirmation message is the payload, so implementing double opt-in does not reduce a form's exposure to being conscripted into one. What reduces it is hardening the form itself. The attack is also hard to see from a single site, because each form contributes only a handful of messages to an effort spread across hundreds of them.
M3AAWG lists ten countermeasures and is explicit that they work in combination rather than individually: a CAPTCHA the form will not submit without; restricting which systems may post to the backend so the page cannot be bypassed; per-IP rate limits; monitoring for the same address arriving at many different forms; regional limits where the service is regional; honeypot fields that a person never sees and a script fills; a page-load timestamp or key, rejecting submissions faster than a person could plausibly manage; non-standard field names so scripts scanning for "firstname" and "email" find nothing; relocating a form that has already been attacked; and adding a Form-Sub header, proposed in the IETF draft draft-levine-mailbomb-header, so receiving mailbox providers can recognize form-generated mail. Several of these share a principle with the confirmation-link fix: make the action depend on something an automated client cannot supply.
Yes, and this is the step most systems skip. M3AAWG's guidance is that if a user updates their email address in your system, the new address should be confirmed in the same way as the original. Without it the whole flow can be bypassed after the fact by editing a profile, and the consent record you are holding then points at an address that never confirmed anything, which is exactly the situation double opt-in exists to prevent.
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.
This guide is revised as the standards and the automated behavior behind them change. Subscribe to hear when it is updated, and when new research on automated confirmation clicks is published.
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.