An email address feels like a small thing to collect. It isn't. The moment someone types an email into your signup form, you're processing personal data, and your email service provider is quietly attaching a lot more to that address than the address itself: signup timestamp, IP address, open and click behavior, engagement score, tags, and a permanent record of how consent was given. If your site runs a newsletter through Mailchimp, ConvertKit, Substack, or anything similar, you need a privacy policy that actually describes what's happening, not a generic template that never mentions email marketing at all.
What your email platform actually collects
Beyond the email address itself, most email service providers (ESPs) build a much fuller profile than subscribers assume:
- Signup metadata. IP address and timestamp at signup, and the specific form or page the subscriber came from. ESPs keep this partly to prove consent was given, which matters if you're ever asked to demonstrate compliance with GDPR's accountability principle.
- Engagement tracking. Open tracking (a 1x1 tracking pixel embedded in the email) and click tracking (links rewritten to route through the ESP's servers before redirecting) let the platform record which emails a subscriber opened and which links they clicked.
- Device and location data. Opens and clicks usually come with approximate location (from IP) and device/client type, which the ESP surfaces in its analytics dashboard.
- Tags, segments, and scores. Mailchimp's audience fields and engagement scoring, and ConvertKit's tagging and automation-sequence data, both build a behavioral profile tied to the subscriber's record over time, not just a static contact list.
None of this is unusual for an ESP. It's necessary infrastructure. But it means "we collect your email address" understates what's really happening, and a privacy policy that stops there is incomplete.
Which consent rule applies depends on where your subscriber lives
Newsletter consent isn't governed by one universal rule. Three regimes commonly apply, and they don't agree with each other:
Newsletter consent rules by jurisdiction
| GDPR (EU/EEA) | CAN-SPAM (US) | CASL (Canada) | |
|---|---|---|---|
| Default posture | Opt-in required before sending | Opt-out model, no upfront consent | Express consent generally required |
| Pre-checked signup boxes | Allowed | ||
| Unsubscribe deadline | Must be honored promptly | 10 business days | 10 business days |
| Existing-customer exception | Narrow soft opt-in exception | Not applicable, opt-out already | Implied consent, 2-year window |
GDPR treats a newsletter signup as consent-based processing: the checkbox has to be unticked by default, the request has to be specific to email marketing (not bundled into a general "I agree to terms" checkbox), and withdrawal has to be as easy as giving it was. CAN-SPAM, the US federal law, doesn't require opt-in at all, it requires that every commercial email include a working unsubscribe link, honored within 10 business days, with no fee and no login requirement, and that the link stays functional for at least 30 days after the message was sent. CASL, Canada's law, sits closer to GDPR: express consent is the default requirement, though there's a narrower implied-consent window for existing business relationships.
If your subscriber list has any EU, UK, or Canadian addresses, and most lists with any real traffic do, the practical move is to build for the strictest applicable rule (opt-in, specific, easy to withdraw) rather than trying to detect jurisdiction and branch your signup flow.
Double opt-in isn't just a nice-to-have
Double opt-in, where a subscriber confirms their email address by clicking a link in a confirmation message before they're added to your list, does two jobs at once. It filters out typos and bot submissions, which keeps your sender reputation clean. It also creates a timestamped, ESP-logged record that the subscriber affirmatively wanted to be on the list, which is exactly the kind of proof of consent GDPR's accountability principle expects you to be able to produce if asked. Single opt-in is legal in most cases, but it leaves you relying on the signup-form timestamp alone as your evidence, which is weaker.
Unsubscribes don't erase everything, and that's fine
A common misconception is that honoring an unsubscribe request means the subscriber's data has to disappear. It doesn't, and in most cases it shouldn't. When someone unsubscribes, the correct outcome is that their address moves to a suppression list, a record your ESP keeps specifically to make sure you never email that address again. Retaining a suppression list is itself a form of data processing, but it's one most privacy frameworks recognize as resting on your own legitimate interest, avoiding accidental re-contact of someone who opted out, rather than requiring separate consent. Deleting the address entirely, rather than suppressing it, actually creates risk: without a record, a re-imported list or a synced integration could email that person again by accident.
Where full erasure does apply is a direct GDPR right-to-erasure request. If a subscriber specifically asks you to delete their data rather than just unsubscribe, that's a different request, and your privacy policy needs to explain how to make it and roughly how long it takes to process.
List hygiene is a privacy practice, not just a deliverability one
ESPs regularly clean lists by removing hard bounces (addresses that don't exist), marking spam complaints, and flagging chronically inactive subscribers. These practices exist to protect sender reputation, but they're also personal-data processing decisions worth naming in a privacy policy. A hard-bounced address gets removed rather than retried indefinitely. A spam complaint triggers immediate suppression, similar to an unsubscribe, since a complaint is at least as strong a signal that the recipient doesn't want further contact. Some ESPs also auto-archive subscribers who haven't opened an email in a long stretch, which affects reporting more than legal status but is worth a line if your platform does it, since a subscriber who checks "am I still on this list" deserves an accurate answer.
International transfers: where the data actually goes
Most major ESPs, Mailchimp and ConvertKit both included, are US-incorporated companies. If any part of your subscriber base is in the EU, UK, or another jurisdiction with its own data-transfer rules, sending that data to a US-based ESP counts as an international transfer, and GDPR requires a lawful transfer mechanism for it, typically Standard Contractual Clauses (SCCs) that the ESP signs as part of their data processing agreement (DPA) with you. You generally don't need to negotiate this yourself, most ESPs publish a standard DPA covering exactly this, but your privacy policy should still disclose that transfers happen and roughly what safeguard applies, rather than staying silent on where subscriber data physically lives.
Naming your ESP matters
Mailchimp, ConvertKit, and every comparable platform are data processors acting on your behalf, not just tools you happen to use. Your privacy policy should name the platform you use, describe what it's used for (sending campaigns, tracking opens and clicks, managing the subscriber list), and note that data may be transferred to and stored by that processor, including outside your visitors' home country if the ESP is US-based, which most of the major ones are. This isn't boilerplate for its own sake, it's the specific disclosure GDPR's transparency requirement and most US state privacy laws expect: who else touches this data, and why.
Our Privacy Policy Generator builds this section for you, naming your actual email platform, covering the consent basis your signup flow uses, and disclosing suppression-list retention in plain language, rather than a generic "we may use third-party services" line that says nothing. If your site also runs analytics or ad tracking alongside the newsletter signup, our Cookie Policy Generator covers those separately, since tracking pixels in emails and tracking cookies on your site are governed by overlapping but distinct rules.
For the broader question of when a site needs a privacy policy at all, our guide on whether a blog needs a privacy policy covers the baseline case a newsletter signup form almost always trips. And if you're weighing GDPR's opt-in default against a more permissive US framework elsewhere on your site, our GDPR vs CCPA cookie consent guide walks through the same opt-in-versus-opt-out split in more depth.
The information in this article is for informational purposes only and should not be construed as legal advice on any matter, and does not create a lawyer-client relationship.
