Does your website use third-party services? Get GDPR compliant in minutes.
Try FlowConsentFree plan · 10-min setup
GNU Mailman is free, open-source mailing list and newsletter software. Self-hosted by the operator, it manages subscriptions, sends list messages and stores archives without third-party tracking.
GNU Mailman is a free, open-source mailing list manager developed by the GNU Project and distributed under the GNU GPL. It powers discussion lists, announcement lists and newsletters by handling subscriptions, message moderation, bounce processing and web-based archives. Because Mailman is software you install and operate yourself, the controller is the organisation running the server: there is no SaaS vendor, no built-in third-party analytics and no shared subscriber database. For an EU operator this makes Mailman one of the most privacy-friendly options for running a newsletter, provided the underlying server, hosting and operational practices are aligned with the GDPR and the ePrivacy Directive.
A typical Mailman list processes subscriber email addresses, optional display names, list-membership metadata, message bodies, moderation decisions and bounce data. The mail server (Postfix, Exim) and the web UI (typically served via Apache or Nginx) also log IP addresses, timestamps and User-Agent strings. For newsletter and marketing lists the appropriate legal basis under Article 6(1)(a) GDPR is the subscriber''s freely given, specific, informed and unambiguous consent, reinforced by Article 13 of the ePrivacy Directive on unsolicited electronic communications. Internal discussion lists for employees may rely on legitimate interests or contract, but newsletters to the public must rely on consent.
Mailman ships with confirmation-by-email enabled by default, which is exactly the double opt-in pattern recommended by the CNIL in France, the BfDI in Germany and the AEPD in Spain. After a user submits the subscription form, Mailman sends a confirmation message containing a unique token; only once the user clicks the link is the address added to the list. Keep the confirmation log (date, IP and User-Agent of the click) as evidence of consent under Article 7(1) GDPR. Avoid pre-ticked boxes, bundled consents and overly broad list descriptions, all of which would invalidate consent under EDPB guidelines.
Get GDPR compliant in 10 minutes
Free plan available · No credit card required
The Mailman web interface uses a small set of strictly necessary cookies to keep moderators and subscribers logged in while they manage their preferences. These session cookies are exempt from prior consent under Article 5(3) of the ePrivacy Directive because they are strictly necessary to deliver the service the user explicitly requested. Out of the box, Mailman does not embed third-party fonts, analytics, pixels or social widgets, so a Mailman-only deployment does not trigger a cookie banner. Operators should be careful when customising templates not to introduce trackers (Google Fonts loaded from Google, Matomo on a third-party domain) without re-evaluating cookie consent.
Every Mailman message includes an unsubscribe link and a List-Unsubscribe header, satisfying the right to withdraw consent as easily as it was given (Article 7(3) GDPR). Subscribers can also access and edit their own membership settings, which supports the rights of access and rectification. For erasure, operators must delete the address from the active list and decide on a policy for the public web archives: either disable archives, restrict them to members, or scrub historical posts on request. A clear retention policy (for example, purging inactive addresses after 24 months and archives after a defined period) helps satisfy Article 5(1)(e) GDPR (storage limitation).
Because the operator controls the server, an EU organisation can choose to host Mailman entirely within the EU/EEA, avoiding the Chapter V GDPR international-transfer questions raised by US-based newsletter SaaS. Run the service over HTTPS with a valid certificate, enable SPF, DKIM and DMARC on the sending domain to limit spoofing, restrict admin URLs by IP or VPN where possible, and apply security updates from the Mailman project promptly. Combined with double opt-in and a clear privacy notice, a self-hosted Mailman instance is a defensible, low-to-medium risk choice for newsletter operations under the GDPR.
Websites using GNU Mailman must obtain user consent under GDPR regulations.
DPIA considerations
Mailman processes subscriber email addresses, list memberships, message bodies and IP/User-Agent in mail server logs. A DPIA is generally not mandatory for a standard newsletter list, but a records-of-processing entry (Article 30 GDPR) is required. Document retention for archives, moderation logs and bounce data, and restrict admin access to the Mailman web UI.
Sample consent text
I agree to receive the [list name] newsletter by email. I understand that my email address will be processed by [Operator] using GNU Mailman, that I can unsubscribe at any time via the link in every message, and that I can exercise my GDPR rights at [contact email].
Third-party domains contacted
list.example.orglists.example.orgmailman.example.orgpostorius.example.orgCookies placed
| Name | Type | Duration | Purpose |
|---|---|---|---|
| sessionid | session | session | Strictly necessary session cookie set by the Mailman/Postorius web interface to keep moderators and subscribers logged in while they manage list settings and preferences. Exempt from prior consent under Article 5(3) of the ePrivacy Directive. |
| csrftoken | session | 1 year | Strictly necessary security cookie used by the Django-based Postorius web UI to protect form submissions against Cross-Site Request Forgery attacks. No tracking purpose; required for the secure operation of the management interface. |
| django_language | persistent | 1 year | Functional cookie that stores the language preference selected by the user in the Mailman/Postorius web interface, so the same locale is shown on the next visit. Considered strictly necessary for the requested service and exempt from cookie consent. |
| messages | session | session | Strictly necessary cookie used by the Postorius web UI to deliver one-shot notification messages (success, error, validation feedback) across redirects. Contains no personal identifiers and is required for the basic operation of the admin interface. |
GNU Mailman collects user analytics data — you legally need a consent banner. Try FlowConsent free.
Yes. Adding a person to a public newsletter list is a marketing communication and requires their freely given, specific, informed and unambiguous consent under Article 6(1)(a) GDPR and Article 13 of the ePrivacy Directive. Mailman's default subscribe-then-confirm flow (double opt-in) is the recommended way to collect and document that consent.
No, not for Mailman alone. The Mailman web UI only sets strictly necessary session cookies for logged-in subscribers and admins. Under Article 5(3) of the ePrivacy Directive, strictly necessary cookies are exempt from prior consent. A banner is only needed if you add non-essential third-party trackers (analytics, embedded social widgets, externally hosted fonts).
For an EU-based operator the simplest path is to host Mailman on a server located in the EU/EEA, using an infrastructure provider not subject to non-EU government access powers. This avoids the Chapter V GDPR analysis required for international transfers and aligns with guidance from the EDPB after the Schrems II ruling.
Administrators can remove a subscriber from a list through the web UI or command line, which deletes their address from the active membership database. For public web archives, decide between disabling archives, restricting them to members, or scrubbing historical messages on request. Document your retention and erasure procedure in your records of processing under Article 30 GDPR.
Not by itself. Mailman is software, not a service, so data flows are entirely defined by where you host the server and which SMTP relays you use. If you host inside the EU/EEA and relay mail through EU servers, there is no third-country transfer. Transfers only arise if you rely on a non-EU smarthost, log aggregator or backup provider.
There is no fixed period in the GDPR; under Article 5(1)(e) (storage limitation) you must define a proportionate retention period and document it. A common pattern is to keep active subscribers as long as they remain subscribed, automatically remove hard-bounced addresses, and re-confirm or delete addresses that have been inactive for a defined period (often 24-36 months).
Mention the controller and contact details, the categories of data processed (email, list membership, IP and User-Agent in logs), the legal basis (consent for newsletters), the purposes, the hosting location, the retention periods for active lists and archives, the recipients (only the operator and any subprocessors), and how to exercise GDPR rights, including the right to withdraw consent and to lodge a complaint with a supervisory authority.
Technically yes, but legally only if every address on the list previously gave a valid GDPR-grade consent for the same purpose and that consent can be documented. Importing scraped, purchased or otherwise un-consented lists is not compliant. EU regulators (CNIL, BfDI, AEPD) recommend re-confirming consent with a fresh double opt-in when migrating between systems.