GDPR and Transactional Email: What Actually Changed for Senders in 2025
GDPR is not new, but its interpretation for transactional email tightened in 2024-2025. Consent rules, data minimisation, DPAs and EU-US transfer mechanisms — here is what matters now.
The GDPR text has not changed since 2018, but its application to transactional email keeps evolving. In 2024-2025 several developments shifted what European businesses must actually do: the EU-US Data Privacy Framework replaced the old Privacy Shield, supervisory authorities issued new guidance on tracking pixels, and Schrems-style litigation continues to test transfer mechanisms. If you ship transactional email from Europe, the rules of engagement in 2025 are not what they were in 2020.
This article catalogues the changes that actually matter operationally, separates them from the noise, and gives you a practical compliance checklist. We are not lawyers; this is engineering practice based on published guidance.
Quick Recap: GDPR Applied to Transactional Email
Transactional email (receipts, password resets, order confirmations, security alerts) processes personal data: at minimum the recipient's email address, often more (name, order details, IP, location). GDPR has always required:
- A lawful basis (contract performance covers most transactional use).
- Data minimisation (do not include data the recipient did not need).
- A DPA (Data Processing Agreement) with your ESP.
- Adequate technical and organisational measures (TLS, access control, suppression).
- Recipient rights honoured (access, rectification, erasure).
- Documented retention.
What changed in 2025 is not these basics — it is the rigour with which they are enforced.
Change 1: Transfer Mechanisms
The EU-US Data Privacy Framework (DPF) replaced the invalidated Privacy Shield in July 2023 and matured through 2024. US-based ESPs (SendGrid, Postmark, Mailgun without EU region) now rely on DPF certification + Standard Contractual Clauses (SCCs) + transfer impact assessment (TIA).
For Italian/European senders this means:
- Verify your ESP is DPF-certified at dataprivacyframework.gov.
- Have an SCC-based DPA signed.
- Document your TIA: what data, where it flows, why DPF + SCCs is adequate.
If your ESP is not DPF-certified, transfers rely on SCCs alone — possible but requires more documentation. EU-only ESPs sidestep this entire conversation.
Change 2: Tracking Pixels and Click Tracking
The French CNIL and the German DSK issued guidance in 2024 distinguishing strictly necessary tracking from non-essential. The summary:
- Open-tracking pixel: NOT strictly necessary. Requires legitimate-interest basis (with balancing test) or consent.
- Click-tracking redirect: NOT strictly necessary. Same basis required.
- Bounce / delivery tracking via SMTP responses: strictly necessary. No consent.
Practical impact: if you track opens, you must (a) document a legitimate interest assessment and (b) provide a privacy notice that mentions tracking. You should not track opens for purely transactional email where engagement metric is not part of the service.
Change 3: Strict DMARC = Better Compliance Posture
Gmail and Yahoo started requiring DMARC enforcement for bulk senders in February 2024. From a GDPR perspective, this is an "appropriate technical measure" — you must authenticate your mail. Not having DMARC at p=quarantine or p=reject is increasingly a documented risk in DPIA reviews.
💡 Tip: When auditors ask "what technical measures protect against impersonation of your sender domain?", "DMARC at p=quarantine with aggregate reporting" is the right answer.
Change 4: Data Subject Rights at Scale
The number of erasure requests has grown. EDPB guidance in 2024 emphasised that erasure must propagate to processors (your ESP) within reasonable time — typically 30 days. Practically:
- You need a DSR ticket flow that exports + deletes from the ESP.
- Your ESP must expose an erasure API (most modern ones do).
- Suppression list entries are themselves personal data and must be deletable on request — but you can keep a hash for "do not contact" purposes.
Change 5: Retention Policies Documented
EU DPAs increasingly ask for documented retention policies during compliance reviews. The pattern they expect:
| Data type | Typical retention | Rationale |
|---|---|---|
| Message content (body) | 30-90 days | Operational debugging |
| Headers / metadata | 12 months | Bounce reconciliation |
| Suppression list | Permanent (hashed) | Prevent re-contact |
| Engagement events | 12-24 months | Analytics |
| Aggregated stats | Indefinite | Not personal data after aggregation |
Pick numbers that match your operational need; document them; enforce them.
Change 6: Joint Controller Clarifications
The CJEU and several supervisory authorities clarified joint-controllership scenarios in 2024. For most ESP relationships, the ESP is a processor (acting on your instructions) and you are the controller. But where the ESP performs analytics across multiple customers or builds aggregate intelligence, joint controllership may apply.
Audit your DPA: does it clearly identify roles, restrict aggregate use, prohibit unrelated processing?
Change 7: The Cookie/Tracking Footer
Email itself is not a "cookie" but tracking pixels behave similarly. Several DPAs treat first-time email tracking as needing opt-in in the same way as analytics cookies. Practical pattern:
- Marketing email: explicit consent to tracking at signup.
- Transactional email: no tracking unless strictly necessary; disclose in privacy notice.
- Mixed: split into separate flows.
Operational Compliance Checklist
- DPA signed with each ESP, including SCCs where US.
- DPF certification verified for US ESPs.
- DPIA documented for any high-volume marketing flow.
- Privacy notice mentions email processing and tracking explicitly.
- Authentication: SPF, DKIM, DMARC at
p=quarantineminimum. - Transport: TLS enforced (MTA-STS in enforce mode).
- Retention: documented per data category.
- Erasure: API-driven, < 30 days.
- Suppression: append-only, hashed, deletable.
- Access logs: who accesses what, retained 12 months.
The Cookie-Less Tracking Trend
Aggregate engagement metrics (clicks, conversions) without individual-level identifiers are often acceptable without consent, since they are not "personal data" once aggregated. The technical pattern: hash + truncate + bucket so reconstructing the individual is statistically infeasible.
For transactional senders this means you can still measure trends without the legal burden of tracking individuals.
Common Misunderstandings
"Transactional doesn't need consent"
Mostly true: the lawful basis for transactional is contract performance, not consent. But tracking pixels in transactional mail are not part of the contract — they require their own basis.
"GDPR doesn't apply to B2B"
False. Business email addresses (alice@company.com) are personal data. GDPR applies in full.
"As long as the data is encrypted, we are fine"
Encryption is necessary but not sufficient. You also need consent/lawful basis, data minimisation, retention, subject rights.
"Our ESP is compliant so we are compliant"
False. The controller (you) is responsible. The processor (ESP) executes. Compliance is yours.
What Italian Companies Specifically Care About
For Italy-resident businesses, Garante (the supervisory authority) has been increasingly active in transactional email enforcement:
- 2023-2024: several penalties for excessive retention.
- 2024: clarifications on email-based marketing consent capture (must be granular).
- 2024-2025: DPA inspection priority on small/medium businesses with consumer data.
Italian DPIAs that pass Garante scrutiny share: clear retention table, granular consent capture for marketing, evidence of DSR handling tested in production, EU-resident processor.
Closing
GDPR for transactional email in 2025 is mostly about doing the basics rigorously: lawful basis documented, DPA signed, retention enforced, subject rights honoured. The 2024-2025 changes raised the bar on transfer mechanism documentation and tracking transparency, not on the fundamental shape of compliance.
Target SMTP processes all data in EU data centres (Italy and Germany), provides a DPA template aligned with current SCCs, exposes erasure and access APIs for DSR handling, and enforces TLS and DMARC alignment by default. The Send-Time Firewall can also enforce retention-based suppression — automatically removing tracking from messages older than your retention window — which makes some of the more operational GDPR requirements self-enforcing instead of audit-driven.