Consent¶
Not legal advice
It is the reasoning behind why the plugin is built this way — so that the decision stays comprehensible and is not reopened with the next blog headline.
Do you need a consent checkbox? No.¶
For a plain subscription form — enter an address, press a button, purpose exclusively the newsletter — a separate checkbox is not required.
Entering the address and clicking the submit button are the „clear affirmative action" the GDPR requires (Art. 4 no. 11).
The best available evidence is the subscription form of the supervisory authority itself: the Data Protection Commissioner of Baden-Württemberg runs a newsletter sign-up with an e-mail field, an „Anmelden" button, a reference to the privacy notice and double opt-in — without a checkbox.
Offering a checkbox as a precaution is not a neutral step
The supervisory authorities point out that a mandatory tick box suggests a voluntariness that does not exist at that point — you cannot untick it, or the subscription does not happen.
A tick box in the wrong place is therefore more of a transparency problem than a safeguard.
When a checkbox is needed after all¶
When the newsletter consent is collected together with something else — in a contact form, with an order, before a download. Then it has to be separate and optional, or it is not freely given (prohibition of bundling, Art. 7(4) GDPR).
The plugin ships no field for that case. If you put the newsletter tick box into someone else's form, you build it there and call the subscription through the REST or SOAP interface.
What the plugin does instead¶
| Requirement | Where in the plugin |
|---|---|
| Duty to inform at collection (Art. 13 GDPR) | The sentence above the button, referring to your privacy policy |
| Right of withdrawal, stated before consent (Art. 7(3)) | „You can unsubscribe from the newsletter free of charge at any time." — in the same sentence |
| Provability (Art. 7(1)) | Double opt-in as the default, plus the consent record |
| Confirmation that the address belongs to the sender (BGH I ZR 164/09) | Double opt-in |
Only double opt-in proves consent¶
Under Form configuration the After subscribing field offers four options. Three of them turn double opt-in off.
| Choice | Provable |
|---|---|
| Send registration mail (double opt-in) | yes |
| Subscribe directly without confirmation mail | no |
| Subscribe directly and send confirmation mail | no |
| Activate manually | no |
The reason is simple: only the click in the confirmation mail shows that the address entered belongs to whoever entered it. Without it, anyone can enter anyone else's address — and you end up writing to somebody who never wanted it.
For e-mail marketing the burden of proof lies with the sender. Anyone choosing one of the other three should have some other record in hand.
Since 2.0 this sentence sits next to the field
Up to 1.1.4 the four options stood side by side without comment. Nothing is forbidden — there are cases where the address is already confirmed by other means.
The consent record¶
New in 2.0, in the core, in both packages.
Why it exists¶
Until then there were two timestamps in the database: when the form was submitted and when it was confirmed. Both prove a process, not a content.
But the sentence under your form changes. A privacy policy is added, its address changes, you reword things. After that there was no way to say, for the existing subscribers, what text stood there at the time — and that is exactly what Art. 7(1) GDPR asks for in a dispute.
What is recorded¶
Every event that changes something is recorded. Usually that is two — the submission of the form and the click in the confirmation mail — and for each:
| When | The time, in server time |
| To what | The complete wording: the sentence above the button and the button's own label. Together they are the consent — the sentence informs, the click declares |
| Where | The page the form was on |
If a privacy policy is published, its address appears in clear text in the record. In the form it is a link.
What is confirmed is the consent of that time
On clicking the link in the confirmation mail, the same wording is recorded as at sign-up, not today's. Otherwise the record would show something the subscriber never read.
Subscribing again gets its own line¶
Since 2.0.1. When someone subscribes who was on the list before — because they unsubscribed and want back, or because the first confirmation never arrived — that is recorded as an event of its own. The older lines stay next to it.
The record then reads as a history: when someone came, when they left, when they came back.
The click refers to the latest subscription, not the first. Someone who agreed in 2024, unsubscribed in 2025 and subscribes again today is confirming today's wording.
An active subscriber who submits the form again leaves nothing behind — nothing changes either.
Subscriptions from a third-party system¶
Since 2.0.1 there is one more event: "Subscribed through the interface, for example in a shop checkout". It is written when a connected system subscribes someone through the REST interface — as a rule wpShopGermany, when a customer ticks the newsletter box in the checkout.
The wording comes from that system: it has to send the text the customer agreed to, otherwise the interface does not accept the subscription. So this route too records what someone consented to — not merely that they did.
Only in the Pro and Enterprise editions
The REST interface is not part of the free edition. This event does not occur there.
No IP address, no user agent¶
Many guides recommend both as part of the proof. Here the click in the confirmation mail is the evidence, and it is the stronger one: it shows that the address belongs to whoever entered it. An IP address does not show that.
Collecting data in stock to win a dispute that may never come contradicts data minimisation.
Where you see it¶
| Newsletter → Subscribers → edit | As text, not as a field |
| Tools → Export Personal Data | With the wording — a data subject should be able to read what they consented to |
| Newsletter → Configuration → Data collected | As a line of its own with the core |
The subscriber above came in through the form, confirmed, and later agreed again in a shop checkout. The wording of the first two lines is the wording of that time — in December 2025 this site had no privacy policy for the sentence to point at.
Why it is not an input field
A proof the operator can edit in the backend is no proof.
Existing subscribers stay empty¶
There is no retroactive migration. Subscribers from before 2.0 have the two timestamps and nothing else; their form shows no record.
That is more honest than a wording slipped in afterwards that they never saw.
On deletion¶
The record goes with the subscriber. The wording stays — it belongs to the remaining subscribers and carries no personal reference.
An import is not consent¶
The CSV import writes no record: the plugin does not know what was consented to, or when.
If you take a list over from another system, keep the proof from there — export of the sign-up data, date, wording. If you have none, the honest route is to import with the status waiting for confirmation and ask for confirmation through the bulk action Send opt-in mail again.
You will lose addresses in the process. The ones that stay will hold up.
What has to go into your privacy policy¶
One line: that, as proof of consent, it is recorded when it was given and confirmed, what wording was consented to and which page the form was on.
You will find the exact sentence under Newsletter → Configuration → Data collected, ready to adopt. It is there and not here so that the two do not drift apart.
No IP address, no user agent — so that does not need to be in there.