GDPR double opt-in for newsletters: consent records guide

Does GDPR require double opt-in for newsletters?

The GDPR does not require double opt-in by name. What it requires is a lawful basis for every newsletter subscription, and where consent is that basis, the controller must be able to demonstrate that the person agreed, and must make withdrawal as easy as giving consent. For a self-hosted list in listmonk or Mautic, that means the platform must hold a provable record of each subscription and each withdrawal, not just a current status flag. Double opt-in is the most common way to evidence consent, because the confirmation click shows that the address belongs to the person who asked to subscribe. Single opt-in can also be defensible in some cases, but the lawful basis, the wording shown at signup and the stored evidence then need to be documented and checked against the GDPR principles in Article 5 and the consent conditions in Article 7. Confirm the basis with your data protection officer or counsel before you choose a list model.

The obligations sit mainly in the controller and processor chapter, including security of processing under Article 32, and in the data subject rights that require erasure and objection to be honored. Your team should be able to answer, for any subscriber, when and how they consented, what text they saw, which list they joined, and whether they have since withdrawn. Confirm that the platform keeps these records outside the mutable subscriber row, and that erasure requests also reach backups and exports on a defined schedule. The GDPR requires no audit, attestation or certificate, and certification under Article 42 is voluntary. The reason to get this right is the fine ceiling in Article 83, which reaches EUR 20 million or 4% of total worldwide annual turnover, whichever is higher, for breaches of the principles, lawful basis and data subject rights.

Consent versus other lawful bases for a newsletter

Which GDPR requirements a double opt-in setup must meet

This table maps the GDPR articles that shape a newsletter sign-up flow to the control the newsletter function needs and where it is configured in listmonk or Mautic. Read each row as a question to answer for your own list before the first send, and treat the evidence column as what an assessor or your data protection lead will ask to see.

Requirement	What the newsletter function must do	Configuration and evidence to keep
Article 6 and Article 7: lawful basis and conditions for consent	Show that each subscriber opted in freely, specifically and by a clear affirmative act, and that consent can be withdrawn as easily as it was given.	Use a double opt-in list for marketing newsletters. Keep the sign-up form wording, the consent text version and the list it applies to in your records.
Article 5: principles of purpose limitation and data minimization	Collect only the fields each list needs and use subscriber data only for the messages people signed up for.	Restrict custom subscriber attributes and separate lists by purpose. Review segment queries before each campaign so that none pulls data beyond the stated purpose.
Article 7(1): proof of consent	Be able to show, for any subscriber, when and how consent was given and which confirmation was clicked.	Retain subscription timestamps, the confirmation event and the opt-in source. Confirm with the vendor which of these fields are stored by default in your version.
Articles 12 to 22: data subject rights	Act on access, rectification, erasure, restriction and objection requests within the timelines the GDPR sets, and document each one.	Define a request workflow with an owner and log each action. Test that an erasure removes the subscriber from lists, campaign history and exports, subject to records you must retain.
Article 21 and Article 7(3): objection and withdrawal	Stop marketing to anyone who objects or withdraws consent, and make the unsubscribe path simple and immediate.	Include a working unsubscribe link in every campaign and transactional template where marketing content appears. Test suppression after an unsubscribe before each rollout.
Article 25: data protection by design and by default	Set privacy-protective defaults at build time, such as double opt-in on by default and limited data exposure in public forms.	Record the configuration choices as a design decision. Review default list settings and public subscription endpoints during implementation and after each upgrade.
Article 28: processor terms for the sending service	Hold a written processing agreement with any SMTP relay, managed mail service or hosting provider that handles subscriber data.	Store signed processor agreements and the sub-processor list. Confirm with each provider where mail logs and bounce data are kept.
Article 30: records of processing	Document the newsletter processing activity, its purpose, categories of data, recipients and retention periods.	Maintain an entry in the records of processing that names the platform, list types and sending services. Update it whenever a list or provider changes.
Article 32: security of processing	Protect the database, admin access, API tokens and backups that hold subscriber data.	Use single sign-on and role-based access where the platform supports it, rotate API tokens and encrypt backups. Confirm each control with your security team.
Articles 33 and 34: breach notification	Detect and assess a subscriber data exposure quickly enough to meet the notification deadlines.	Log admin and export activity, and keep a tested runbook that names who assesses an incident. Include the sending service in the breach contact chain.
Chapter V: transfers to third countries	Know where subscriber data, mail logs and tracking data are stored and whether any transfer outside the EEA takes place.	Document hosting locations for the platform, backups and every relay. Where a transfer occurs, record the transfer mechanism you rely on.
Backups and purge procedures	Remove erased subscribers from backups within a defined cycle, so restored backups do not re-subscribe them.	Write a backup purge or suppression-list procedure. Test a restore and confirm that erased addresses stay suppressed after recovery.

How a double opt-in flow records consent step by step

A double opt-in sequence turns a sign-up into a confirmed, provable marketing consent, and it only works if each step leaves a record you can retrieve later.

Capture the address and stated purpose
The sign-up form collects the email address and tells the person what they are subscribing to, such as a monthly product newsletter, in language they can read before submitting. In listmonk, this is typically a public subscription form tied to a specific list; in Mautic, it is a form that writes to a contact record and may add tags or segments. Confirm in your configuration that the form text names the purpose and that no pre-ticked boxes or bundled consents exist. The output is a pending subscriber record that is not yet on the marketing list.
Send the confirmation email
The platform sends a confirmation message to the address provided, asking the person to confirm. The message should identify the sender, state what the subscription covers, and contain only the confirmation action, not marketing content. In listmonk, the double opt-in template and the list setting determine whether this message goes out; in Mautic, you must build the confirmation step in a campaign or form action and verify it fires. Check that the message is sent through the same authenticated domain you use for newsletters. The output is a sent message you can find in the send logs.
Subscriber clicks a unique confirmation link
The link in the confirmation email contains a token tied to that subscriber, so the platform can match the click to one specific record. Confirm that tokens are unique, not guessable, and do not expire in a way that prevents a legitimate confirmation without a clear reason. The subscriber's action is the affirmative step that separates a request from consent. The output is a matched token that the platform can resolve to a single subscriber.
Record timestamp, IP and source
When the confirmation is accepted, the platform should store the time of confirmation, the source form or list, and, where your legal review permits and you have a documented reason, the IP address. Whether IP storage is lawful and proportionate is a decision for your data protection lead, and the GDPR does not prescribe a specific field set. Verify which fields your listmonk or Mautic version writes, where they are stored, and who can read them. The output is a consent record you can export for a given address.
Add the subscriber to the marketing list
Only after the confirmation is recorded does the subscriber move to the active marketing list. In listmonk, a double opt-in list holds subscribers in an unconfirmed state until the link is clicked; in Mautic, the contact should be placed in a segment or campaign only after the confirmation action, using a condition you have tested. Check that unconfirmed contacts cannot receive campaigns through any segment, API call or import. The output is an active subscription that appears in your list counts only after confirmation.
Confirm the record and test the edge cases
Run a test sign-up with a controlled address, click the link, and verify that the status changes, the record shows the expected fields, and the subscriber receives the first campaign. Then test an unconfirmed address, a repeated click and a resubscribe after unsubscribing. Document the results. Because the listmonk and Mautic behaviours differ in how they expose unconfirmed contacts and how they handle re-entry, treat your own test results as the only evidence you can rely on. The output is a signed-off test record kept with your processing documentation.

Which self-hosted platforms support GDPR-ready consent handling

Two self-hosted options dominate newsletter work in the EU: listmonk for list and campaign sending and Mautic for marketing automation with contact records. Both can support double opt-in and consent evidence, but the proof lives in your configuration, your database and your sending service, so each card names what to verify before you rely on it.

listmonk for double opt-in lists

listmonk is licensed under AGPL v3 and runs on PostgreSQL as its only dependency, which keeps the subscriber table, opt-in state and campaign history in one database you control. Lists can be set to single or double opt-in, so a double opt-in list holds subscribers in an unconfirmed state until they click the confirmation link. Check that the confirmation timestamp and list status are retained for each subscriber, and that your opt-in template records what the person agreed to.

listmonk access control and SSO

listmonk supports OIDC single sign-on with granular roles, permissions and API tokens, so staff who can export or edit subscriber data can be limited to the lists they manage. This matters because consent records are only as trustworthy as the access controls around them. Confirm which roles can export subscriber data, how API tokens are issued and revoked, and whether administrator actions are logged in the version you deploy.

Mautic contact and consent features

Mautic is licensed under GPL-3.0 and stores contacts with consent and preference data inside its own marketing database, alongside campaigns and segments. Its consent handling depends on how your team configures contact fields, channel preferences and campaign rules, so the evidence of consent is not automatic. Test whether the consent state you need to prove is stored as a field, how changes are timestamped, and whether it is preserved when contacts are merged or imported.

Mautic cron and queue dependencies

Mautic relies on cron jobs for segment updates, campaign triggers and broadcasts, and a messenger consumer when emails are queued. If a job stops, a withdrawal of consent may not reach every segment in time, so a person who has unsubscribed could still be targeted by a scheduled campaign. Ask your operator to confirm that suppression changes are applied before the next send, that cron jobs are staggered as the project recommends, and that job failures generate alerts.

Mautic hosting and version requirements

Mautic 7.0 requires PHP 8.2 to 8.5, MySQL 5.7 or higher with InnoDB or MariaDB 10.2 or higher, and a web server such as Apache, Nginx or IIS. The project states it should not be installed on shared hosting, so a VPS or dedicated server is the baseline. Security support windows differ by release, so confirm which version you will run, its end of security support, and whether your consent evidence survives upgrades on your target version.

The sending service is a processor

Whichever SMTP relay or sending service carries your messages receives personal data and acts as a processor under the GDPR, so a written processor agreement under Article 28 is needed before go-live. Your self-hosted platform records consent, but the relay handles delivery logs and bounce data that may also be personal data. Confirm where the relay stores logs, how long it retains them, which sub-processors it uses, and whether transfers outside the EU are covered by appropriate safeguards.

Evidence a supervisory authority or auditor will ask for

This table lists the records a supervisory authority or assessor is likely to request for a double opt-in newsletter, which component produces each one, and whether the sending vendor holds it. Use it to check your own evidence gaps before an inquiry. The main takeaway is that consent logs, processor agreements and transfer documentation often sit partly outside your servers, so confirm them with the vendor in writing.

Evidence item	Produced by	Where it is held	Vendor-only?
Records of processing (Article 30)	Your privacy team, with input from the platform owner	Your governance register	No
Consent log with timestamps and confirmation events	listmonk or Mautic subscriber and opt-in records	Your PostgreSQL or MySQL database	No
Consent text version shown at sign-up	Your template and form configuration history	Git repository or template change log	No
Unsubscribe and erasure request log	Platform admin actions and subscriber status changes	Platform database plus your ticketing system	No
Backup retention and purge records	Your backup tooling and restore test results	Backup storage and runbook records	No
Signed processor agreement with the sending service	Contract between you and the sending vendor	Your contract repository	Yes
Transfer documentation for third-country sub-processors	Sending vendor's sub-processor list and transfer terms	Vendor documents you obtain and file	Yes
Breach response records	Your incident response team, with vendor notices	Incident register and vendor correspondence	Yes

How erasure and unsubscribe reach lists, logs and backups

Must an unsubscribe delete the address or only suppress it?

An unsubscribe usually needs to suppress the address, not delete it, because the sender must keep a record that stops future marketing email to that address. Deleting the address removes the only memory the system has of the opt-out, so a later import or re-sync can send to it again. Erasure under Article 17 of the GDPR is a separate request that can require deletion of the personal data, with narrow exceptions your legal team should document. Ask your counsel to confirm how each request type is handled in your records, and configure the platform so that unsubscribe sets a suppression status rather than removing the subscriber row.

How do you keep a suppression record without the marketing profile?

Keep the suppression list minimal: a hashed or minimal identifier, the list or channel it applies to, the date and the reason, and nothing about behavior, segments or campaign engagement. Store the suppression in a separate table or a restricted list that marketing users cannot export with the full profile. In listmonk, the subscriber status can be set to blocklisted while personal attributes are removed. In Mautic, the contact can be marked do not contact with its profile fields cleared where your policy allows. Confirm with your privacy team whether a hashed identifier satisfies your own records policy before relying on it.

How does erasure reach Mautic or listmonk segments?

Erasure does not propagate automatically across a self-hosted stack. A segment is a query or a stored list, so removing a contact from the subscriber table changes segments only when they are re-evaluated. Mautic depends on cron jobs for segment and campaign updates, so a deleted contact can remain in a cached campaign audience until those jobs run and the queued messenger items are processed. In listmonk, segments are SQL expressions over subscribers, so they update on query but any exported CSV or campaign already queued keeps its copy. Build an erasure runbook that lists every table, queue, cache and export, and test it on a staging copy before go-live.

What about sub-processors and SMTP logs?

Each sending service, SMTP relay, analytics or webhook messenger that receives a subscriber address is a processor or sub-processor that holds personal data. Under Article 28 of the GDPR, the controller must have a written processor agreement with each one, and the sub-processor chain must be disclosed. SMTP and relay logs often keep recipient addresses, message IDs and timestamps for days or longer, and those logs need their own retention settings and deletion path. Ask each provider for its log retention period, deletion process and sub-processor list, and confirm the transfer mechanism for any non-EU hosting, including reliance on the EU-US Data Privacy Framework only where the provider is certified.

Can a backup restore bring back erased contacts?

Yes. A restore from a backup taken before an erasure can reinstate deleted subscribers and their consent state, and the restored list may then receive email the subject asked to stop. The fix is a documented restore procedure: after any restore, reapply the erasure requests and suppression records logged since the backup date before the platform sends anything. Keep the erasure and suppression log outside the restored database, or replicate it to the restore environment, so it can be replayed. Backups that are not restored within a set period are typically deleted on rotation, and that rotation period should be stated in your retention policy. Confirm with your backup vendor how point-in-time restores and snapshots are handled.

How long should consent logs be kept?

The GDPR does not set a fixed retention period for consent records, so the period follows from the controller's need to demonstrate consent and from its own retention policy. Under the accountability principle in Article 5, you must be able to show when and how consent was given, which argues for keeping the consent event for as long as the subscriber's data is processed, plus the period in which a claim could be made. Many teams keep the consent event and suppression record longer than the profile, and delete the rest on erasure. Ask your data protection officer or counsel to set the period in writing, and make sure the consent log is excluded from routine profile deletion.

Can our own team run erasure and suppression, or do we need a partner?

A small team with database access and a clear runbook can run erasure and suppression on a single platform, but the work becomes error-prone when subscribers sit in several systems, backups, queues and third-party logs. The effort depends on the number of systems that hold personal data, how many sub-processors are involved, how often restores are tested, and whether the runbook is automated. DeployOpen implements, configures, backs up and documents self-hosted platforms inside your infrastructure under a fixed scope agreed in writing, and can prepare the erasure, suppression and restore procedures as part of that scope. Ask any partner to define in writing which systems, logs and backups are covered.

What tooling alone does not satisfy

A self-hosted newsletter platform gives you the mechanics of consent capture, storage and suppression, but it does not decide whether your sending is lawful. The items below are decisions and documents that sit with your legal, privacy and business owners, and each one shapes how the software should be configured.

Lawful basis decision

Under Article 6 of the GDPR, you must choose and record the lawful basis for each newsletter, campaign and list. Consent is one option, but a product update sent to existing customers may rest on a different basis, and the choice changes what the opt-in flow must prove. The platform can tag lists, but it cannot tell you which basis applies. Confirm the decision with your data protection officer or legal counsel before you build the first list. Document it per list so the record survives staff changes.

Consent notice wording

Consent must be freely given, specific, informed and unambiguous, so the words shown at sign-up matter as much as the checkbox or button. Your legal team should approve the notice text, the named sender, the purposes, the withdrawal route and the retention period. Templates in listmonk or Mautic can hold the wording, but nothing in the software checks whether it is accurate. Version each notice and keep the version that each subscriber saw.

Signed processor agreement

If an external sending service delivers your newsletters, the provider acts as a processor and the contract must meet Article 28. Ask the provider for its data processing terms before go-live, and confirm the subject matter, duration, data categories and security measures. A self-hosted platform does not remove this obligation when mail still leaves your network through a third-party relay. Keep the signed copy in your contract register.

Transfer assessment for sub-processors

Sending chains often include analytics, bounce handling, monitoring or support tools based outside the EU. Map each sub-processor, identify where subscriber data travels, and check whether a transfer mechanism under Chapter V applies, including any adequacy decision such as the EU-US Data Privacy Framework. Tracking pixels and link redirects can also transfer personal data. Record the assessment before you enable those features in the platform.

Retention policy approval

Decide how long subscriber records, consent logs, suppression entries and campaign analytics are kept, and who approves that period. Suppression data often must outlive the subscriber record so that you do not re-subscribe someone who opted out. Backups extend the retention period unless you set rules for them. Confirm the policy with your records or privacy owner, then configure deletion jobs and backup expiry to match it.

Staff training and access control

Marketing, support and developer staff handle consent evidence, exports and erasure requests, so each role needs to know what it may do. Train staff to recognize a withdrawal request sent by email or a support chat, and to route it into the suppression process within the time your policy sets. Limit export and API token rights to named roles, and review those roles on a schedule. Training records are part of the evidence you show a supervisory authority.

What double opt-in and consent records cost and take to set up

What drives the cost of a double opt-in setup for newsletters?

The cost follows the scope you agree in writing, mainly the number of lists and consent purposes, how many sending domains and forms need the flow, and how deeply the platform connects to your CRM and website. Each list with its own confirmation wording, language versions and preference center adds design and testing work. Backup and erasure design also adds effort, because deleted subscribers must be removed from live data, exports and restored copies in a way you can explain. Ask for each of these as a separate line in the quote so you can see which choices move the total.

How long does a fixed-scope double opt-in implementation take?

The timeline depends on the scope agreed in writing before work starts, not on a standard duration. A single list with one confirmation email and a basic unsubscribe page is a much smaller job than several lists across multiple domains with CRM sync, consent logging and erasure procedures. Time is also spent waiting on your legal review of consent wording and on your data owner's decisions about retention. Ask the implementation partner to show the phases, the dependencies on your team and which items are fixed and which depend on your decisions.

What does the team need to provide for a consent records project?

Three groups of people usually need to be available. Legal or privacy counsel must approve the consent wording, the purposes stated in each form and the retention periods for proof of consent. A data owner for the subscriber data must decide which fields are stored, who can see them and how erasure requests are handled across lists and backups. Engineering needs access to the listmonk or Mautic host, the database, the mail sending service, the web forms and any CRM connection. Confirm named people and their time before the schedule is signed.

Can we set up GDPR double opt-in and consent records in-house?

Yes, a team with the right skills can build it, and the platforms are open source, so no licence purchase is needed for the software itself. listmonk supports single and double opt-in lists, and Mautic offers its own form and contact handling, but the legal design, proof-of-consent storage, erasure across backups and processor paperwork still require privacy and security judgement. The main questions are whether your engineers can maintain the setup after go-live and whether your privacy team can sign off the design. Compare the internal time, including ongoing upgrades and monitoring, against a fixed-scope engagement before deciding.

Which costs recur after the double opt-in setup goes live?

Several costs continue after launch. Hosting and database storage grow with the subscriber count and retained consent logs. Platform upgrades, security patches and mailbox-related changes need someone to apply them, and your sending service may charge by volume. Erasure and access requests need a documented process that someone runs each time. If you buy support or a retainer, that is a recurring line item. Ask the partner to separate one-time implementation costs from these recurring costs in the quote.

What should we confirm in a quote for consent records work?

Ask for a written scope that lists the lists, sending domains, forms and integrations covered, plus the consent records to be stored and the retention rule for each. Confirm what happens to backups and archives during erasure, who signs off the consent wording and what the handover includes, such as configuration documentation and runbooks. Check which items are excluded, including legal advice and any compliance audit, since DeployOpen prepares controls and evidence but does not issue audit reports or certifications. Confirm the support terms after go-live and how changes to scope are priced.

Does a double opt-in implementation need a processor agreement with the sending service?

The GDPR sets obligations for controllers and processors, and the Article 28 contract between you and any processor, such as an SMTP relay or hosted sending service, should be confirmed with your legal team. Your self-hosted platform keeps subscriber data in your infrastructure, but the sending service that delivers the messages may still process personal data. Ask the provider for its data processing terms and where data is handled, and confirm them before the quote is final. The partner can document the technical flows, but the contract is a legal task for your organization.

Where do GDPR fines and enforcement risk affect the project scope?

Article 83 of the GDPR sets maximum administrative fines of EUR 10 million or 2% of worldwide annual turnover for infringements such as those covering security of processing, and EUR 20 million or 4% for infringements of the principles, lawful basis and data subject rights, whichever is higher in each case. These ceilings explain why the consent evidence, unsubscribe handling and erasure steps deserve explicit scope items and tests. Ask the partner which records and tests the engagement will produce so your privacy team can check them against your obligations.

Where to check the legal text and the latest changes

Check the GDPR text itself before you rely on any consent design. The authoritative version is Regulation (EU) 2016/679, which you can read in full on EUR-Lex. For a newsletter team, the provisions that matter most are the ones on lawful basis for processing, the controller and processor duties in Chapter IV, and the fine structure in Article 83. Save a dated copy of the articles you cite in your consent design file, so you can show which text you relied on when you set up the double opt-in flow and the consent record.

As of October 2026, the GDPR text has not been amended. Two proposals are still moving through the EU process. The Omnibus IV proposal (COM(2025) 501) has a text agreed in interinstitutional negotiations on 26 June 2026 and is waiting for Parliament's first-reading vote. The Digital Omnibus proposal (COM(2025) 837) is awaiting a committee decision. Track both through the European Parliament's Legislative Observatory) and the Digital Omnibus entry, and record the status and date each time you review your list setup. Neither proposal is law yet, so do not change consent practice on the strength of a draft.

Regulation (EU) 2025/2518 sets additional procedural rules for complaints and investigations in cross-border GDPR cases and applies from 2 April 2027. It changes how enforcement proceeds, not what a valid consent looks like, but it may affect how a supervisory authority requests your records. Confirm the current status of all three instruments with your data protection officer or external counsel before you rely on any change, and ask them to confirm whether any national rules in your member states add requirements for newsletter consent.

How DeployOpen scopes and supports consent-ready newsletters

DeployOpen plans, implements, customizes, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so consent flows and consent records for newsletters can be designed around your lawful basis and your data location. We prepare the systems, controls and evidence that a compliance assessment would examine, while your legal counsel and any independent auditor make the final determinations.

How we scope

Engagements are fixed-scope, with the list types, opt-in flows and consent fields agreed in writing before work starts.
The written scope names which lists use single or double opt-in and which consent evidence each list must store.
We confirm with your legal and data protection team which lawful basis applies to each newsletter and campaign type.
Scope also records the sending service, its processor terms and the locations where subscriber data is held.

How we build

We configure double opt-in confirmation emails, confirmation pages and list settings on listmonk or Mautic in your environment.
Consent records capture the timestamp, source form, confirmation event and the wording shown at sign-up.
Unsubscribe and erasure requests are tested across active lists, segments, transactional logs and backup copies.
Each flow is tested with sample subscribers before go-live, and the test results are documented.

How we hand over

Handover includes a written description of each opt-in flow, the consent fields and their retention settings.
You receive runbooks for handling withdrawals, erasure requests and proof-of-consent lookups.
Documentation maps configured controls to your own data protection records, such as your record of processing activities.
We provide a checklist of processor agreement items to confirm with your sending service provider before launch.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after go-live.
Upgrades to listmonk or Mautic are planned, tested and documented so consent flows keep working after each release.
Periodic checks confirm that opt-in forms, templates and suppression rules still match the agreed scope.
Ask any partner to confirm response times, backup handling and support terms in the written agreement.

GDPR double opt-in and consent records for newsletters