How to run a GDPR-compliant newsletter (without a legal team)
GDPR has a reputation for being a lawyer's problem. For a newsletter, most of it isn't. You need consent you can prove, a way to honour a few subscriber rights, and some honesty about where the data lives. That's most of it. The rest is paperwork you'll do once.
This is a practical walkthrough, not legal advice. If you run a large operation with sensitive data, talk to someone qualified. But if you send a newsletter to people who asked for it, the compliance bar is lower than the internet makes it sound, and most of the work is choosing tools that don't fight you.
The one thing GDPR actually cares about: consent
Everything else follows from this. GDPR says you need a lawful basis to email someone, and for a newsletter that basis is almost always consent. Consent has to be freely given, specific, and provable.
"Freely given" means no pre-ticked boxes and no bundling ("agree to marketing to download this"). "Specific" means they agreed to your newsletter, not to a vague "we may contact you." "Provable" is the one people miss. If a regulator or an annoyed subscriber asks, you need to show when and how someone agreed.
This is where double opt-in stops being a deliverability nicety and becomes your evidence. When someone signs up and then clicks a confirmation link, you have a timestamped record that this specific person agreed. Single opt-in gives you a name in a box. Double opt-in gives you proof. They're not the same when someone disputes it.
What you actually have to do
Four things, and none of them takes long.
Collect consent properly. An unticked box, clear language, a real confirmation step. Say what they're signing up for. Keep the record of the signup.
Let people leave easily. One-click unsubscribe, honoured immediately, no "log in to manage preferences" maze. This is both the law and basic decency, and since 2024 the mailbox providers require it too, so you were doing it anyway.
Handle the rights requests. A subscriber can ask what you hold on them, ask for it in a portable form, or ask you to delete it. In practice this means: export their data, or wipe it, within about a month. For a newsletter this is rare and quick, but you have to be able to do it.
Be honest about subprocessors. Anyone who touches your subscriber data on your behalf (your sending platform, your hosting) is a "processor," and you're the "controller." You should know who they are and be able to name them. A good platform lists its own subprocessors so you don't have to go digging.
That's the compliance core. Notice what's not on the list: no cookie banner marathon, no consent-management platform, no quarterly audit. A newsletter is a low-complexity case.
Where your list actually lives
Here's the part most guides skip, and it's the one that quietly causes the most trouble: where is your subscriber data physically stored?
If your platform stores it in the US, you're not automatically breaking anything, but you've taken on a dependency. EU-to-US data transfers rely on legal mechanisms that have been struck down and rebuilt more than once in the last decade. Every time that happens, everyone relying on the transfer scrambles. You inherit that instability whether you follow the news or not.
Storing EU subscriber data in the EU makes the whole question disappear. There's no transfer to justify, no framework to monitor, no clause to keep current. It's the difference between managing a risk and not having it.
Worth separating two things people conflate here: where your list is stored, and where your emails are sent from. A platform can store your subscribers in the EU but relay the actual sending through infrastructure elsewhere. Both matter, and they're not always the same region. The sending layer has its own residency map (Postmark is US-only, Mailgun runs a German region, Resend sends from Ireland but stores account data in the US), which we went through provider by provider separately. If EU residency is the reason you're reading this, it's worth checking both, not just the marketing headline.
The tools do most of the work
None of this requires a legal team. It requires a platform that treats consent, unsubscribes, exports, and residency as defaults rather than upsells.
The problem is that a lot of the big newsletter tools were built US-first, with GDPR bolted on afterward. You get the features, but the data still lives in the US, and the EU-friendly settings are yours to find and switch on. It works. It's just more of your problem than it needs to be.
This is roughly why we built Yellaro the way we did. It's managed Listmonk hosting, and the list lives in the EU, on your own isolated instance, not pooled inside a shared US platform. Double opt-in is the default, one-click unsubscribe is built in, and export and deletion are there when a subscriber asks. The sending runs through our own EU infrastructure rather than a shared pool, so the reputation you're borrowing is yours, not a stranger's. We list our subprocessors on the privacy page so you can name them without asking.
None of that makes you automatically compliant. Compliance still depends on how you collect consent and what you promise people. But it removes the technical barriers, which is the part that's genuinely annoying to do yourself. You handle the honesty; the platform handles the plumbing.
Before you send
A short checklist, whatever platform you use:
- Confirm your signup uses real, unticked, specific consent.
- Turn on double opt-in so you can prove it.
- Check that unsubscribe is one click and honoured immediately.
- Know where your list is stored, and where it's sent from.
- Be able to export or delete a subscriber on request.
- Know who your subprocessors are.
That's a GDPR-ready newsletter. It's less than a day of setup and then mostly nothing, which is about the right amount of effort for something that sounds this scary.
If your sending domain isn't set up yet, our free DMARC and SPF checkers will tell you what's missing before it becomes a deliverability problem. And if your emails are landing in spam despite all this, that's usually authentication, not GDPR. If you're moving off a US platform to sort this out, we wrote up the migration itself too, or you can just see how it works.
FAQ
Is double opt-in required under GDPR? Not strictly, but it's the easiest way to prove consent was freely given. GDPR requires you to demonstrate that a subscriber agreed. A double opt-in leaves a timestamped record of that agreement, which single opt-in doesn't.
Does my newsletter data have to be stored in the EU? Not legally required, but it removes a whole category of problem. Storing EU subscriber data outside the EU means relying on transfer mechanisms that keep changing. A platform hosted in the EU sidesteps that entirely.
What subscriber rights do I have to support? Access, export, correction, and deletion, plus a clear way to withdraw consent. In practice this means being able to export a subscriber's data and wipe it on request within about a month.
Is Mailchimp GDPR-compliant? Mailchimp can be used in a GDPR-compliant way, but it stores data in the US, so you rely on standard contractual clauses for the transfer. An EU-hosted platform avoids that dependency. Compliance always depends on how you collect consent, not just the tool.