Tracking pixels in email: what you need in place by 29 October 2026

29 October 2026 is the deadline for complying with the Italian Data Protection Authority’s guidelines on tracking pixels in email communications. It is the most cross-cutting date in our calendar: not just manufacturers, not just the public sector — anyone who sends a newsletter or a commercial email.

The date first, because a different one is going around. The measure is no. 284 of 17 April 2026, adopted under art. 154-bis(1)(a) of the Italian Data Protection Code; the Authority’s press release is dated 21 April. The period runs from neither: the guidelines set “a period of 6 months from the moment of their publication in the Official Gazette within which those bound must comply”. Publication was in the Gazzetta Ufficiale, Serie Generale no. 98 of 29 April 2026, editorial code 26A02030. Six months from 29 April gives 29 October. Counting from the press release gives 21 October: wrong.

A pixel is access to the recipient’s terminal

An image one point wide, often transparent, sitting on a remote server: when the message is opened the client downloads it, and that request tells the sender the email has been read.

The Authority frames the operation like this: inserting the pixel and “reading” the information that follows from it are “operations that fall within the case of access to the terminal governed by art. 122 of the Code”. And that fit “covers both modes of access provided for there”: both the “storage of information in the terminal equipment of a subscriber or user” — placing the pixel — and the subsequent “access to information already stored”, that is, the recording of the recipient’s behaviour.

Paragraph 2-bis of that article lays down a general prohibition, save for consent or the derogations the provision itself allows. Legitimate interest does not come into it: the measure never mentions it, and the e-Privacy Directive is lex specialis to the GDPR. On identifiability the Authority invokes recital 30: online identifiers “may leave traces which […] may be used to create profiles of the natural persons and identify them”. Its preamble also recalls its own precedents on cookies (no. 229 of 8 May 2014) and on online profiling (no. 161 of 19 March 2015).

The Authority does not require two tick boxes. It holds that consent to tracking “may, in principle, be encompassed within the more general consent to receiving promotional communications”, to avoid consent fatigue, “on condition, however, that the request is framed neutrally and without pressure”.

The real condition sits upstream. Pixels “are particularly invasive markers, above all because of their hidden character”, and their use must be disclosed beforehand, “failing which they are unusable”. Consent collected without saying the message carries a tracker does not cover the tracker: for processing already under way the gap must be closed “with the first available send or in any case at the first point of discontinuity”. The measure distinguishes newsletters, DEM, transactional email and service email, but the duty does not turn on the type of message: it turns on the pixel being there.

Granular withdrawal breaks the architecture of sending platforms

The heaviest point in practice. Someone who has consented must be able to withdraw “easily […] including granularly: either by withdrawing the single consent given, with the effect of preventing further messages, or by withdrawing it only in part, exclusively as regards the tracking”. By way of an icon or a footer link to a dedicated area. And anyone refusing tracking must keep “full use of the service”, with “no limitation”.

Today the dominant model is binary: subscribed or unsubscribed. What is required here is a third state — subscribed and not tracked. The first check is not on your privacy notice, it is on the software: does that function exist? If it does not, rewriting a text will not fix it.

Second-order consequence. The pixel almost always belongs to the sending platform, not to you, but the roles are not a given: the measure requires them to be defined “case by case, and in accordance with the accountability principle in art. 5(2) of the Regulation”, weighing “where relevant” art. 26 on joint controllership. You as controller and the platform as processor is not automatic: it depends on who decides the purposes and means of the tracking. Ask for the processor appointment and read what it says about tracking.

Which metrics do you actually need

In inspections carried out in October 2025 and February 2026 the Authority found that pixels “are used in practically every case”. Consent, however, is not always needed. There are three derogations: statistical counting of the “overall percentage of message opens”, provided you use “single pixels, that is, not differentiated per user but identical for all recipients of the same campaign” and anonymise IP addresses and technical data; security measures tied to authentication; and institutional or service messages the controller is legally obliged to send.

It is needed when “individual measurement and analysis of the open rate” serve to assess campaigns, adjust their frequency and subject line, or infer tastes and preferences. The question: which metrics do you need in order to decide something, and which do you collect only because the platform collects them by default? Every open recorded without a legal basis is processing without a legal basis, and it does not become lawful because it is the default setting of a tool you bought.

The non-sequential identifier

The verb matters: the Authority “suggests”, it does not prescribe. It considers it “appropriate to suggest that, in order to reduce the risk of identifying recipients, […] the sender generate an unintelligible and non-sequential identifier and associate it with the recipient’s email address, keeping that correspondence in an internal, separate layer of the platform used”. It is art. 25 GDPR applied to a very small detail.

It says something more general, though: a sequential identifier lets you infer relationships between recipients without reading a single name — who came first, who signed up on the same day, how many of you there are. That holds for any system that assigns codes to people. One corollary: a code that is hard to guess is not in itself a control.

Soft spam covers the sending, not the tracking

This is the likeliest misreading. The measure names soft spam once, and not among the derogations: it cites it while describing how the address may have been obtained, “for instance in the course of an online commercial transaction, relevant also for any reliance on the derogation in art. 130(4) of the Code on soft spam or for upselling procedures”. That derogation concerns sending to someone who has already bought. Tracking sits under art. 122 and has its own regime: being allowed to write is not being allowed to measure.

Where the sending runs

Granularity of withdrawal, separation between identifier and address, the choice of which metrics exist at all: these are design decisions. They turn into a request against someone else’s price list only when the system is not yours.

That is why we work in two modes only: on-premise, in the client’s own environment, or CSIDIA dedicated cloud — an environment reserved to the single client, access over a dedicated VPN, data centre located in Italy, premises staffed directly by us. Either way lists, sends and metrics stay inside a perimeter you control, and that is where you decide what gets measured and what does not. It is the method we describe here.

If you need to work out what changes in your sending before 29 October, write to us.