Heads-up for EU users, Italian DPA ruling on tracking pixels affects every newsletter sent with FluentCRM...
Hi everyone,
Posting this because it's going to land on a lot of EU inboxes in the next few weeks and I'd rather we discuss it here before panic sets in.
On April 17, 2026 the Italian Data Protection Authority published a binding opinion on email tracking pixels. The short version: the open-tracking pixel that FluentCRM (and basically every other email platform — Mailchimp, Brevo, ActiveCampaign, HubSpot, Klaviyo, Substack, all of them) injects by default into campaigns is now classified under Art. 122 of the Italian Privacy Code, which is the local implementation of the EU ePrivacy Directive. In practice this means the pixel requires prior, specific, informed, freely given consent — the same standard that already applies to non-essential cookies.
A generic newsletter opt-in is no longer enough. The user must either explicitly consent to tracking, or be given a granular way to opt out of tracking while remaining subscribed.
Three things worth knowing:
1. This is not only an Italian problem. The legal foundation is the EU ePrivacy Directive, which applies everywhere in the Union. The Italian ruling is the first explicit interpretation on pixels specifically, but other national authorities (CNIL in France, the German DPAs, the Irish DPC, etc.) tend to align quickly on this kind of interpretation. If you send newsletters to EU recipients from anywhere in the world, this concerns you.
2. There's a grace period, then real sanctions. Italian businesses have six months from publication in the Official Gazette to comply. After that, fines fall under GDPR Art. 83 — up to €20M or 4% of global turnover. This is not a "€500 slap on the wrist" regime.
3. The fix is technical, not just legal. You need (a) an updated privacy policy that explicitly names tracking pixels and the data they collect, (b) a mechanism for subscribers to opt out of tracking without unsubscribing from the newsletter, (c) the ability to actually suppress the pixel for non-consenting contacts.
On point (c), FluentCRM right now doesn't expose a per-subscriber opt-out flow or a clean filter hook to conditionally suppress the pixel at render time — I've opened a feature request ticket with the Fluent team asking for both admin-level and subscriber-level tracking controls, plus developer hooks as a minimum viable step. If this matters to your business, adding a +1 or your use case to that ticket helps it move up the roadmap.
In the meantime, a few things I'd suggest to fellow EU users:
- Audit your current opt-in flow. Does your privacy policy mention tracking pixels explicitly? If not, it needs to.
- Don't panic-send a re-consent email tomorrow. You have time. Plan it: decide who needs what (fresh opt-in vs tracking-specific re-consent vs nothing because the existing policy already covers it).
- If you rely heavily on open rates as a KPI, start now on an alternative engagement model (replies, clicks on meaningful links, conversions) — a meaningful chunk of your audience will end up in a non-tracked segment either way.
Happy to discuss specific implementation ideas if anyone has them — I'm a developer running an agency managing EU/Swiss clients, so I'm looking at this from both the compliance and the "how do we actually build it" side.
Source https://www.garanteprivacy.it/home/docweb/-/docweb-display/docweb/10241943 https://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/10241977
In the version 3, we have added tracking configurations.
So you can control how you want to track or completely disable it.
Shahjahan Jewel love! we need just another little thing the user need to control if revoke or not tracking! thx again
Edoardo Guzzi Looks like too many rules you guys got. We added this feature to make it easier for users in different regions.
We don't want to ship the subscriber-level consent UI in core, every site handles consent differently (cookie banner, CMP, separate preferences page, meta field tied to a form, some store those as part of the user or other plugins) and baking one flow into core would just get in the way for most users.
What we can do is expose a filter hook that lets you suppress the open-tracking pixel per subscriber, based on whatever consent state you're already storing. Since you're on the dev side, you wire it to your existing consent logic and keep full control over the UX. That covers the compliance piece without us forcing an opinion on how consent should look.
I would just disable open tracking for this case as Open Tracking matrix is not correct as most of the email clients block / pre-render it anyway.
Shahjahan Jewel for me is good :D
Yes, we have too many rules, but they’re popping up everywhere. :P
Shahjahan Jewel I agree, too many rules, every day a new suprise comes out.
Am I allowed to say that EU is a 💩?