> New newsletter rules: GDPR and Pixel Tracking - what changes and what to do

It happens on a Thursday. The Privacy Guarantor publishes a forty-eight-page measure, and within forty minutes the WhatsApp groups of Italian marketers are filled with three-minute audios of people who haven't read the document but already have a very strong opinion. Classic.

I have read the whole document(if you believe!). It is called measure no. 284 of april 17, 2026, is about tracking pixels in email, and it is one of the most dense regulatory texts with technical implications that I have read in recent years(I don't read often). It is a developer's piece and an email infrastructure manager's piece.

The fact, reduced to the bone

Tracking pixels are those invisible, pixel-sized images that email marketing platforms insert into newsletters to know whether the email has been opened. They work like this: the remote server serves the image only when the client requests it, and the request contains all the useful metadata-IP address, user agent, timestamp, recipient identifier.

The Garante made two inspections of an email provider and a marketing automation platform between October 2025 and February 2026. Textual conclusion of the measure: tracking pixels are used “in almost all cases”. It is not a downward estimate. It is an assessment.

The key legal passage is this: the pixel is qualified as a case falling under the’Article 122 of the Privacy Code, i.e., the same standard as cookies. Article 122 contains a general prohibition, subject to exceptions: no one may store information in a user's terminal or access it without prior, free, specific and informed consent. The rule has existed since the transposition of the ePrivacy Directive in 2012. What was missing was explicit guidance applying it to email. Now there is.

Six months from publication in the Official Gazette to comply. Then the penalty regime of Article 83 of the GDPR is triggered. Twenty million or 4% of worldwide turnover. Whichever is higher.

This is not just an Italian problem

The ePrivacy directive is European. It exists identically in every member state. The Italian Garante's measure explicitly recalls the EDPB Guidelines 2/2023 dated October 7, 2024, which are the shared European-level framework on the technical scope of Article 5(3) ePrivacy. Translated: the Italian Garante came first, but the interpretation already exists at the EDPB level.

France's CNIL-which on privacy matters is notoriously a Category A villain-will probably follow within months. The Germans also. The Irish have a more biblical time frame but will get there. Those who send newsletters to European citizens have a problem anyway, wherever the company is based.

The interesting technical part (and which no one is commenting on)

In paragraph 6 of the measure there is a precise architectural recommendation that as a developer made my ears perk up. The Garante, in application of Article 25 GDPR (privacy by design), suggests this:

“The sender generates an unintelligible, nonsequential identifier and associates it with the recipient's e-mail address, maintaining that correspondence in a separate, internal layer of the platform used.”

In human language: the pixel URL must not contain the recipient's email. Neither in plain text, nor in base64, nor in any other easily reversible format. It must be an opaque, separately generated identifier whose correspondence with the email address lives in an internal database and never transits the public network.

Well: go see how your platform does it. Open the HTML of a recent newsletter, look for the tag <img> Of the tracking pixel and see what URL it produces. If you find your email in there, a hash that's not “salty,” or any string that in thirty seconds leads back to the address, that platform is not ready. And it is the default setting of more platforms than you imagine.

This is the part of the measure that, outside of generalist comments, requires real technical work-not a “privacy compliance” plugin downloaded on the fly from the repository.

What you can do without consent (the three exemptions)

The provision is not the opening paragraph of a dystopian novel. Paragraph 5 lists three cases where consent is not needed.

Anonymous aggregate statistics. You can measure the overall open rate of a campaign without asking for consent, provided you use an identical pixel for all recipients (not a unique pixel per user) and anonymize IP and client. Result: you know a campaign was opened by 34%, you don't know who. Round number, zero individual profiling.

Security and authentication. Password reset, account confirmation, data portability, handling GDPR requests. Here the pixel is used to verify that the message arrived at the right home and the waiver is full.

Mandatory institutional or service communications. Contract changes, data breach notifications, deadline reminders, phishing alerts. Legitimate.

What not is legitimate without consent is the ordinary case: I track who opens to see if the subject line works, I adjust the frequency based on the individual's interest, I profile who's hot and who's cold, I customize the next send. That is, exactly what Mailchimp, Brevo, ActiveCampaign, HubSpot, Klaviyo, FluentCRM, Substack do -- out of the box, by default, from day one.

The false problem that someone is already selling

As soon as the measure came out, my lawyer Alessandro Vercellotti - who does digital law and chews on these things for a living - pointed out something worth repeating. Agencies are already going around proposing “double hard consent”: one box for the newsletter, another separate one for tracking, both mandatory at sign-up. Price of intervention: substantially high. Haste: very high.

The problem is that the Supervisor wrote the opposite.

The text of paragraph 6 is explicit: consent to tracking can be included in the more general one to the newsletter, as long as the request is neutral and as long as-this is the point that changes everything-the revocation is granular. A box at sign-up is fine, but then the user must be able to uncheck only tracking without losing the newsletter. Preferences panel accessible from the footer of each email. Point.

As Vercellotti pointed out, whoever is selling double consent either hasn't read the document, or is betting that you won't read it. In either case, same rule: ask for a second opinion before you sign quotes(maybe just ask him who is really good).

The four consequences, without sweetening

1. Open rate as a KPI is in intensive care.

A slice of your subscriber base will end up in the “newsletter yes, tracking no” segment. For them, open rate will no longer be measurable. If you bill the customer based on open rate, start building an alternative model today: clicks on valuable links, direct responses, attributable downstream conversions. Open rate survives as a technical indicator of delivery. As a proxy for engagement, it is in decline.

2. The preference panel is code, not compliance

The granular revocation panel that the measure mandates is not a checkbox in the email. It's a real page, linked from the footer, connected to the CRM, that persists the user's choices as subscriber property, and that changes the behavior of the pixel rendering on send. If your platform today exposes neither a UI for the user nor a developer hook to conditionally suppress the pixel, you are building technical debt at fire speed.

3. Penalties are no longer the 30,000-euro theater

Up to 4% of global turnover. No one starts at the ceiling, but the enforcement environment is hot: in the same week that these guidelines came out, the Garante imposed a sanction of 12.5 million to Poste Italiane and Postepay On a different case (ThreatMetrix device in BancoPosta apps). The Authority is not sleeping.

4. Your email platform is the first bottleneck

Three checks you can do today, without calling anyone. Open the HTML of a recent newsletter and look at the pixel URL: does it contain the recipient's email (in plain text or trivially reversible formats)? If yes, the platform is not privacy-by-design according to the Guarantor's criteria. Open the admin panel and try sending the same campaign to two segments with different tracking policies: can you do it without duplicating the campaign? If not, the workflow does not support the new regime. Search the documentation for the hook or filter that allows you to suppress the pixel conditionally per-subscriber: does it exist? If not, write to platform support now.

Six months. Which is not six months

In software we know one thing that the right often ignores: development timelines are not linear. If adapting requires database audits, information update, CRM intervention, preference panel build, possible platform migration, re-consent campaign, end-to-end testing, post-deployment monitoring--six months is a tight timetable. Not wide.

Those who start in late summer work in a hurry. Those who start in October arrive late. Those who arrive late take what is left of the market, which is usually not the best: rigid platforms, hasty consultations, patch solutions. The first one to move in order gets to choose. Platform, partner, architecture, timing.

Sources

• Measure No. 284 of April 17, 2026 - Privacy Guarantor (full text)
• Official press release from the Guarantor
• EDPB Guidelines 2/2023 on Article 5(3) ePrivacy
• Legal for Digital - Alessandro Vercellotti

If you have an active newsletter and so far have only read the three-minute audios, that's the sign. The measure is there, takes less than an afternoon to read, and contains everything you need to know where to start. In six months, the conversation will change. Not for the better for those who will have procrastinated.