On 17 April 2026, the Italian Data Protection Authority (Garante per la Protezione dei Dati Personali, the “Garante”) adopted Provvedimento n. 284, the first dedicated guidelines on the use of email tracking pixels.
The rules were published in the Gazzetta Ufficiale n. 98 on 29 April 2026 and give organizations six months to adjust, ending 29 October 2026. The core change is simple: any tracking pixel that fires when a recipient opens a message and identifies that recipient now needs prior opt-in consent, the same legal standard already applied to cookies.
💡 The one-line version: if a pixel can be tied back to an individual recipient, the Garante now treats it like a cookie. Same opt-in rule, same proof-of-consent requirement, same six-month transition window.
If you run email marketing for an Italian brand, or you send to recipients in Italy from an EU base, this affects almost every newsletter and promotional send you ship.
What the Garante’s rules say
Tracking pixels are tiny images embedded in email HTML. They fire automatically when the message is opened, triggering an HTTP request that carries identifiers (pixel ID, IP address, user agent, timestamp) back to the sender’s server. For a longer explainer of what a tracking pixel actually does, our earlier piece covers the mechanics.
The Garante grounds the new consent rule in Article 122 of the Italian Privacy Code (Codice Privacy), which transposes Article 5(3) of the EU ePrivacy Directive (the cookie law). The European Data Protection Board (EDPB) confirmed this reading in its Guidelines 2/2023 on the technical scope of Article 5(3) (final version, 7 October 2024): loading a pixel is a form of “gaining access” to information stored on the recipient’s terminal, the same operation the cookie rule already governs. Pixels and cookies now share the same consent standard.
Why 29 October 2026 is the date that matters
Six months from publication in the Gazzetta Ufficiale on 29 April 2026 lands on 29 October 2026. That’s the date by which organizations sending email to recipients in Italy should have updated their consent flows, sign-up forms, and email templates.
The Garante built in some flexibility for addresses already in your list. During the transition, existing promotional sends with tracking can continue, provided recipients are informed at the first useful opportunity and offered a granular opt-out. For newly collected addresses from publication onward, the consent-first regime applies right away.
When consent is required, when it isn’t
Most pixels used in marketing emails need consent. A narrow set of operational uses do not.
| Email type/pixel purpose | Garante position |
|---|---|
| Newsletter, DEM, promotional email, open-rate tracking | Consent required |
| Recipient profiling or cross-channel targeting | Consent required |
| Authentication, MFA, password reset | Exempt |
| Deliverability (remove inactive recipients, transactional only) | Exempt, strict conditions |
| Anonymous aggregate open rate (same pixel per campaign) | Exempt, anonymized only |
| Legally mandated or institutional email | Exempt |
Two of those exemptions need a closer look. The deliverability exemption applies only to transactional emails (not promotional sends), only to drop genuinely inactive recipients, and the platform can store only the date of the last open, day-level, with no time component. The anonymized aggregate exemption is a Garante-specific allowance: the pixel must be identical for every recipient on the campaign, and IP and client data must be anonymized.
The Garante requires that, for the aggregate exemption to apply, only non-individualized tracking pixels may be used and related technical data, such as IP addresses and client information, must be anonymized before any storage. This rests on the same data-minimization principles already familiar from the General Data Protection Regulation (GDPR).
How the Garante fits the wider European picture
France’s Commission nationale de l’informatique et des libertés (CNIL) took a parallel position a month earlier. On 12 March 2026 it adopted Deliberation n° 2026-042, published 14 April. Same principle: prior consent before any individualized pixel. Two differences are worth flagging if you send across both markets.
First, the CNIL treats marketing consent and pixel consent as two separate consents. The Garante allows them to be bundled into a single informed consent, provided the language is neutral and not coercive. Second, the CNIL does not accept the anonymized aggregate-stats exemption; the Garante does.
The transition windows also differ. The CNIL gave three months for pre-existing addresses, ending 14 July 2026. The Garante gave six. If you operate in both jurisdictions, you will need to satisfy both sets of requirements, since each has specific obligations the other does not replicate. A setup that meets the CNIL’s granularity requirements will generally cover the Garante’s consent standard, but the Garante adds requirements the CNIL does not prescribe with the same specificity, including mandatory two-level withdrawal and explicit opaque pixel ID architecture.
💡 Sending across both markets? Neither rulebook is strictly stricter. Plan for the union of both: separate marketing-and-pixel consents (CNIL), plus two-level withdrawal and opaque pixel IDs (Garante). The CNIL deadline for pre-existing addresses passed on 14 July 2026, so that side should already be in place if you send into both markets.
What agencies and marketing teams need to do before 29 October 2026
Most of the work is in your forms, templates, and policies, not your sending infrastructure. Ten concrete actions:
- Audit your email program. List every email type (promotional, newsletter, transactional) and every pixel in use. Flag which sends already rely on valid consent and which don’t.
- Update your sign-up forms. Add a pixel-specific disclosure and an unchecked opt-in box. Name the controller, and any vendor that also uses pixel data for its own purposes (a joint controller under Article 26 GDPR).
- Update your privacy policy. Add a section on pixel processing: data collected, legal basis (consent), retention, third-party recipients, and processor or joint-controller status. The brand owns this document. If you’re an agency working for a client whose policy doesn’t yet mention pixels, flag the update to their legal team early.
- Refresh your preferences page. The destination behind the footer link should be informative and offer granular choice: pixel-only opt-out, full unsubscribe, or both.
- Add a “manage tracking preferences” link to the footer of every tracked email template.
- Build two-level withdrawal. Recipients should be able to turn off pixel tracking without unsubscribing. Log both choices separately.
- Send a transition notice. Before the deadline, inform existing subscribers via the first useful email and offer opt-out, especially for addresses you collected before publication.
- Use opaque pixel IDs. Pixel URLs should carry an internal, non-sequential identifier, never the email address itself.
- Add a no-track HTML variant. Your sending platform should be able to deliver a pixel-free version of the email when consent is absent or withdrawn, not just block at the server level.
- Keep a consent log. An immutable per-address record: consent timestamp, purposes, wording version, and every subsequent change. Our Consent Database gives you that out of the box, including proof on revocation.
💡 One framing point worth holding onto: the sender is the controller, even when pixel management is fully outsourced to an email service provider. A contract clause requiring your ESP to collect consent on your behalf is not enough; you need the underlying evidence records too.
How to separate marketing consent from tracking consent
The rules ask you to treat two things as separate decisions: consent to receive marketing emails, and consent to the pixel that reports when those emails get opened. A subscriber who wants your newsletter but not the open tracking has to be able to say so, and turning tracking off can’t mean unsubscribing.
Store both as distinct preferences on the same address in the Consent Database: one for the newsletter subscription, one for email tracking. Each gets its own timestamp, purpose, and proof of revocation, so each can be withdrawn on its own and you keep the evidence for both. Our Consent Database integration guide walks through the setup on the major platforms.
Storing the preference is half the job. The pixel stops firing only if your email platform reads that signal and applies it to each recipient, so check what yours actually supports before you treat the flow as complete. Platforms differ. Some expose a per-contact tracking field you can keep in sync with the Consent Database through a webhook. Others let you turn off open tracking only for a whole list or segment, or by hand, one contact at a time.
A setup that holds up end to end looks like this:
- Collect the two preferences separately at signup, and let people change either one later from a preference page
- Write both to the Consent Database, so every change is logged with proof
- Sync the tracking preference to your email platform, ideally as a per-contact field, using Consent Database webhooks
- Send a pixel-free HTML variant to anyone who declined tracking, and keep the withdrawal link working in the emails you do track
If your platform can’t suppress the pixel per recipient today, ask your provider if and when they’ll support it. That answer decides how much of the work sits on your side.
How iubenda can help
Our Privacy and Cookie Policy Generator includes two dedicated email tracking pixel clauses, so the privacy-policy update from action 3 above comes down to picking the right one:
- Email tracking pixel (marketing/advertising) covers pixels that measure email performance or feed audience segments. It sits under the Advertising purpose and states that tracking runs on prior consent, with a withdrawal link in every tracked email.
- Email tracking pixel (operational use) covers pixels that only confirm delivery of transactional, security, or account messages. It sits under the Monitoring delivery of service communications purpose, which is strictly necessary and needs no consent.
If you use the same provider for both marketing and transactional sends, declare the two uses separately. The operational clause applies only to a setup dedicated to service communications, such as a separate transactional stream, sub-account, or scoped API key.
The Consent Database handles the per-address consent log, including timestamp, purpose, and proof of revocation. If you already use iubenda for your privacy policy and consent records, you have the two most critical building blocks in place. What’s left is checking that your pixel disclosure and withdrawal flow match the requirements above.