With Decision No. 284 of April 17, 2026 (web doc. no. 10241943), pending publication in the Italian Official Gazette, the Italian Data Protection Authority (Garante per la protezione dei dati personali) adopted the “Guidelines on the Use of Tracking Pixels in Email Communications.” That is a long-awaited intervention that fills an enforcement gap for a technology that is widely deployed, objectively invasive, and, until now, addressed only indirectly through the general framework governing cookies and other tracking tools.

The aim of this commentary is twofold: on the one hand, to present the content of the decision in an organized manner for the benefit of data controllers, Data Protection Officers, and operators involved in email marketing; on the other, to raise — from the perspective of those who apply the rules daily — a question that goes to the core of the system outlined by the Italian DPA and its relationship with the European consent framework.

1. The Decision at a Glance

Tracking pixels are tiny images — typically transparent and measuring a single pixel — hosted on remote servers and embedded in email bodies via HTML code. When the recipient opens the message, the email client loads the image: this operation allows the sender to detect that the message has been opened and to collect additional information, such as IP address, device type, timing and frequency of subsequent openings, and, in some cases, unique identifiers tied to individual recipients.

The Italian DPA emphasizes the particularly invasive nature of these tools, stemming from their covert character: in most cases, recipients are unaware of their presence or the operations they trigger. The Guidelines, therefore, aim to reaffirm that the use of such tools must be disclosed to recipients in advance and supported by the conditions for lawful processing required by the applicable law.

The decision sets a six-month deadline from the date of publication in the Italian Official Gazette by which the parties concerned must comply.

2. The Regulatory Framework: Article 122 of the Italian Privacy Code as Lex Specialis

The Italian DPA places the use of tracking pixels within the scope of Article 122 of the Italian Privacy Code, which transposes Article 5(3) of Directive 2002/58/EC, as amended by Directive 2009/136/EC (the ePrivacy Directive). This choice reflects the fact that the mechanism — inserting a pixel into the body of an email and subsequently reading the information produced when it loads — matches the dual-access mode regulated by the provision: storing information on the user’s terminal equipment and subsequently gaining access to that information.

This approach is consistent with EDPB Guidelines 2/2023 on the technical scope of Article 5(3) of the ePrivacy Directive, which clarified the provision’s scope in a technology-neutral manner. The Italian DPA also cites Recital 173 and Article 95 GDPR to reaffirm the lex specialis relationship between the ePrivacy Directive and the GDPR, with the former prevailing in matters for which specific obligations pursuing the same objective exist.

Consequently, under Article 122, paragraph 2-bis, a general prohibition on processing applies, unless one of the exceptions contemplated by the provision is met.

3. Parties Involved and Types of Messages

The decision maps out the roles that may become relevant: the sender of the message, the email delivery service provider (typically SaaS marketing automation platforms), providers of distribution-list rental services, providers of the tracking technology itself, content creators, and, of course, recipients. Identifying the relevant roles under data protection law — controllership, joint controllership under Article 26 GDPR, processor under Article 28 — is left to the controller’s accountability principle, on a case-by-case basis.

As for message types, the Italian DPA distinguishes among newsletters, DEMs (Direct Email Marketing), transactional and automated emails, and institutional or service messages. The distinction is not merely descriptive: it affects the identification of the applicable legal basis and whether a consent exception applies.

4. The Information Obligation

The Italian DPA draws attention to the fact that covert tracking tools, even before triggering the consent requirement, conflict with the principle of fairness enshrined in Article 5(1)(a) GDPR. It follows that, in every case, the controller must provide data subjects with a notice that complies with Articles 12 et seq. of the Regulation — clear, transparent, and consistent with the accountability principle.

Simplified notice formats are permitted, including layered structures (a summary at the point of contact with a link to the full notice) and delivery through multiple channels (pop-ups, chatbots, video channels, voice interactions). For processing operations already in progress when the Guidelines take effect, the controller may discharge the information obligation on the occasion of the next available mailing or at the first available point of discontinuity.

Where none of the exceptions apply — addressed in the following section — a controller intending to use tracking pixels in emails must obtain the recipient’s prior consent. According to the decision, consent must be informed, freely given, specific, and unambiguous.

The Italian DPA distinguishes two scenarios. For new processing operations, consent should preferably be collected when the email address is obtained, after appropriate information is provided. For ongoing processing operations, during the transitional period, the controller must implement a withdrawal mechanism that is immediately available and easily accessible to the data subject.

The decisive passage of the decision, from a systemic perspective, is different. The Italian DPA states that, to simplify and avoid consent fatigue, consent to receiving tracking tools may, in principle, be bundled into the broader consent to receiving promotional communications, so that the person expresses a single informed consent. The compensating safeguard for this bundling is the possibility of granular withdrawal: the data subject may withdraw consent in full (stopping the mailings altogether) or limit it to tracking only, while continuing to receive communications free of tracking markers. Granular withdrawal must be accessible via a standardized icon or a link in the message footer, leading users to a dedicated area for managing their rights.

The Italian DPA identifies three scenarios in which consent is not required, provided the information obligation is still met:

  • Anonymous statistical purposes aimed at measuring the overall opening rate of messages to improve deliverability and combat spam. The exception applies on condition that unique pixels are used — identical for all recipients of the campaign, not differentiated per individual user — and that other related technical data (IP address, client information) are anonymized. The methodological reference is Article 29 Working Party Opinion No. 05/2014 on anonymization techniques.

  • Security measures tied to authentication processes, account confirmation or update, password-change requests, or handling requests to exercise data subject rights.

  • Institutional or service communications that the controller is legally required to send and for which the recipient’s actual knowledge is relevant: warnings about phishing or fraud, contractual changes, privacy notice updates, security incident notifications, and reminders about contractual or administrative deadlines.

In all these scenarios, the Italian DPA considers that the information obtained through the pixel serves to deliver the service more effectively, to the benefit of the recipient.

7. System Architecture and Technical Configuration

The foregoing considerations on consent and exceptions can only be fully understood in light of the technical mechanism by which tracking pixels operate and the implementation architectures available in practice today. Understanding this mechanism is not a purely technical exercise: it is a precondition for assessing, at the operational level, which configurations enable controllers to comply with the Guidelines and, more broadly, with data protection principles.

A tracking pixel is an <img> HTML element embedded in the body of an email that points to a resource — typically a tiny transparent image — hosted on a server controlled by the sender or its service provider. When the recipient’s email client automatically downloads images in the message, it sends an HTTP GET request to the server: this request carries, in addition to the identifiers the controller has embedded in the URL (typically a campaign identifier, a message identifier, and a recipient identifier), a series of data that the client transmits by default — the recipient’s IP address, the User-Agent string identifying the device and email client, the browser language, and the timestamp. The server returns the image and records the request in its logs: open-rate metrics displayed in marketing dashboards are built from these records.

Two technical points are legally relevant. First, a pixel does not, strictly speaking, extract information from the user’s terminal: collection occurs via the standard HTTP request the client spontaneously issues to load the resource. It is precisely this apparent innocuousness — a simple GET for an image — that led the EDPB, in Guidelines 2/2023 on the technical scope of Article 5(3) of the ePrivacy Directive, to clarify that the operation nonetheless falls within the scope of the provision, as it constitutes an instruction to the terminal to send specific information to the remote server. Second, in most commercial implementations, the pixel’s identifier is unique for each recipient of each campaign, and this uniqueness — designed to enable granular metrics — is exactly what the Italian DPA characterizes as individual tracking that requires the data subject’s consent.

Architecturally, the possible configurations span a spectrum. A structured review is useful for gauging how closely the solutions actually available on the market align with the principles.

The most common configuration — the default on major SaaS marketing automation platforms — embeds a unique per-recipient identifier in the pixel, which is automatically included in every email sent. The controller setting up the campaign takes no specific action to enable tracking: it is the platform’s default. Disabling it, where technically possible, is often all-or-nothing for the entire campaign, cannot be segmented per recipient, and in some cases is reserved for higher-tier plans. That is the configuration that, in the language of the Italian DPA’s decision, cannot operate under the statistical exception: tracking is individual and, outside the exception scenarios, requires consent.

A second configuration — corresponding to the measures the Italian DPA explicitly cites as an application of Article 25 GDPR — replaces the identifier directly tied to the recipient’s email address with a non-sequential, unintelligible token, while retaining the mapping between the token and the email address in a separate internal layer of the platform. The recipient’s IP address, collected in the HTTP request, can be anonymized on intake through truncation (of the last octet for IPv4 and the least-significant 64 bits for IPv6). This configuration reduces the exposure of personal data in server logs. In the event of a security breach or unauthorized access to the logs, no email addresses or full IP addresses are found in clear text. This configuration operates at the pseudonymization layer; it does not, however, change the individual nature of the processing, since, through the mapping maintained in the internal layer, the controller can still reconstruct each recipient’s behavior.

A third configuration — the only one compatible with the statistical exception identified by the decision — uses a unique-per-campaign pixel rather than a unique-per-recipient one: every message sent within the same campaign embeds the same identifier, and the server records only the total number of requests received, with no possibility of associating them with individual users. Anonymization of accessory technical data (IP address, User-Agent) completes the configuration. This architecture enables the controller to understand the overall campaign open rate and to act on deliverability and spam-fighting. Still, it forgoes by design any individual measurement and, consequently, any form of behavioral profiling.

Finally, there is a fourth configuration, which, in the view taken here, appears the most consistent with the requirement in Article 25(2) GDPR. In this configuration, no pixel is embedded by default in any message: the pixel is inserted only for recipients who have given specific, separate consent to tracking — consent collected separately from consent to list subscription or to receiving promotional communications, documented autonomously and immediately revocable. The mailing list is segmented upstream into two groups: the first receives the message with an active pixel, the second receives the same message without any tracking element. The default is non-tracking; activation is the informed, documented, and revocable exception that the data subject claims for a specific purpose. This configuration is technically achievable: it requires neither technologies that do not exist nor particularly complex infrastructure. It does, however, require a platform design oriented toward minimization by default, treating tracking as a separate, documented feature rather than as a function bundled into the standard service package.

As a complement to the sending-side design picture, it is worth considering that the technical landscape has also consolidated on the receiving side over recent years. A meaningful share of email clients and providers implement countermeasures against pixel tracking: preemptive blocking of automatic remote image loading, a long-standing feature widespread in privacy-oriented clients (Thunderbird, Proton Mail, Tutanota, and others); active identification of tracking pixels, offered by clients such as MailMate which — as documented in the vendor’s official release notes — block by default images originating from known trackers (based on a dedicated list of tracking services) and explicitly report the download of 1×1 pixels as a strong indicator of email tracking; systematic proxying of requests, introduced by Apple with Mail Privacy Protection in 2021 and adopted in analogous forms by other providers, which loads pixels indiscriminately for all recipients and renders open-rate metrics structurally unreliable for senders; and DNS-level network filters, widely used among technically attentive users.

The presence of these countermeasures carries two implications relevant to the present analysis. First, tracking through pixels is recognized as inherently invasive by the technical community itself, to the point that families of tools have been specifically developed to counter it — a factual datum that confirms the characterization of particular invasiveness formulated by the Italian DPA and, before it, by the EDPB. Second, effective protection today depends to a significant extent on the recipient’s informed choice of reading tool. This choice presupposes technical skills and attention to privacy that are not uniformly distributed across the user population. A regulatory model that entrusts data protection to individuals’ diligence in selecting their email client departs, in our view, from the logic of Article 25(2) GDPR, which places on the controller the duty to design a system that is protective by default.

A separate consideration is warranted regarding systematic proxying. When the recipient’s provider automatically loads pixels for every message, regardless of actual opening, the metrics collected by the controller lose their signaling value: the open rate is artificially inflated, IP addresses collected are those of the provider’s proxies rather than those of actual recipients, and the request timestamp does not correspond to the real moment of reading. The cumulative effect is twofold. On the one hand, a significant share of individual tracking today produces behaviorally unusable data — suggesting that the economic rationale for individual tracking with unique per-recipient identifiers is progressively eroding, even from the controller’s perspective. On the other hand, since proxying does not affect user populations uniformly — impacting Apple clients more than others — residual individual tracking increasingly targets less-protected recipients, producing a selection effect that reflects contingent technical circumstances rather than design choices and that, on this further ground, conflicts with the principle of fairness under Article 5(1)(a) GDPR.

On this last point, an operational issue arises that the Guidelines do not address and warrants flagging for its implications for controllers’ responsibilities. In market practice, it is far from obvious that the most widely used commercial email marketing platforms — adopted by most Italian controllers for newsletters, promotional communications, and transactional emails — offer the fourth architecture described above as a native capability. Individual tracking with a unique per-recipient identifier is the default in standard configurations; disabling it is typically all-or-nothing for the entire campaign and cannot be segmented per recipient; and segmentation of the mailing list based on consent to the specific tracking purpose does not appear, from the available evidence, to be a native feature of the most common market solutions.

A controller intending to fully comply with the privacy by design principle, as interpreted in the following section, therefore faces a narrower range of choices than the Italian DPA’s decision suggests: negotiate custom configurations with the provider — a possibility formally available on enterprise plans but rarely practical for ordinary organizations; adopt self-hosted email marketing solutions, on which a PbD-compliant architecture can be implemented with dedicated technical work; or operate permanently under the statistical exception, forgoing individual metrics in exchange for compliance with the minimization principle. The chain linking the controller’s legal responsibility — grounded in Articles 24, 25, and 28 GDPR — to the technical configurations actually available on market platforms is, in practice, imperfectly welded. The Italian DPA’s decision, focusing its technical guidance on pseudonymization of identifiers and minimization of accessory data, does not address this aspect, which in our view is one of the grounds on which practice, and especially contractual governance between controllers and email service providers, will be particularly tested in the months following the Guidelines’ entry into force.

In light of the technical configurations now described, the critical dimension can be addressed with greater precision. The Guidelines expressly invoke Article 25 GDPR and suggest several noteworthy technical measures: using a non-sequential, unintelligible identifier associated with the recipient’s email address, with the mapping kept in a separate internal layer of the platform; counting opening events through the identifier alone, without the email address traveling in the technical request generated by the pixel loading; and documenting the recorded choices made by data subjects, for purposes of proof of consent under Article 7(1) GDPR.

These are pointed, technically sound indications commendably aimed at reducing the risk of recipient identifiability. The reflection that, in our view, deserves to be carried out, however, addresses a different — and broader — plane than that of technical measures. Privacy by design, as enshrined in Article 25 GDPR, is not exhausted in the minimization or pseudonymization measures adopted once processing is underway: it requires the controller to configure the system — the means of processing, the default settings, the architecture of choices offered to the data subject — so that data protection is a structural feature rather than the consequence of individual assertion.

Article 25 is textual on this point. Paragraph 1 requires the controller to implement appropriate measures “both at the time of the determination of the means for processing and at the time of the processing itself”: the first site of intervention is therefore the design phase, not the operational one. Paragraph 2 adds that the controller shall implement appropriate technical and organizational measures to ensure that, “by default,” only personal data necessary for each specific purpose of the processing is processed. The default — the system’s behavior absent user intervention — must be oriented toward minimization.

The question that emerges is therefore not whether consent and privacy by design are, in the abstract, compatible: they are, since consent may legitimize processing that goes beyond what is necessary to deliver the service or perform the agreement, provided that the requirements for a valid expression of will are met. The question is, more precisely, whether the consent model designed by the Guidelines holds up under the parameters of privacy by design — that is, whether a system built around unified consent for both receipt of promotional communications and tracking, with granular withdrawal delegated to a link in the message footer, satisfies the requirement that “by default” the controller process only personal data necessary for each specific purpose pursued.

In our view, this point warrants careful reflection. In the model outlined by the decision, individual tracking of opening behavior is not a processing operation necessary for delivering the email service or the promotional message; it is additional processing pursued for purposes belonging to the controller (measuring commercial performance, adapting campaigns, profiling interests). Precisely because it is not necessary, the GDPR conditions its lawfulness on consent. But once consent is obtained jointly with consent to receipt, and the data subject’s choice regarding the autonomous tracking purpose is deferred to a subsequent withdrawal — moreover, one made accessible through a link in the footer of each email — the system’s configuration is such that, by default, tracking occurs. Data subjects who want only a receipt without tracking, though abstractly entitled to it, must take affirmative steps to obtain it. The non-tracking condition is not the system’s default; it is a choice the user must explicitly enable.

This configuration, in our view, is in tension with the logic of Article 25(2). The privacy-by-default principle holds that minimization is the system’s starting point. It places the choice of additional processing — including consent-based processing — within the data subject’s sphere of affirmative action for each distinct purpose. A configuration more consistent with that principle would more likely have involved: a default without tracking pixels; affirmative action by the data subject, specific and tied solely to the tracking purpose, to enable it; and separate documentation of that action from consent to receipt of the promotional message. The Guidelines, at their decisive juncture, move in a different direction: unified consent and ex post granular withdrawal yield a system in which privacy does not emerge as the default condition but as an outcome users must obtain by taking action.

The technical measures suggested by the decision — however commendable — operate within this configuration without correcting it. An unintelligible identifier is a pseudonymization measure applied to processing that, in the model designed, is already underway by default. It is risk mitigation, not structural prevention. The difference, from the standpoint of Article 25, is not trivial: the privacy-by-design principle requires acting on the system’s design before addressing risk-reduction measures adopted once processing is active.

The core of privacy by design, as developed by Ann Cavoukian and subsequently codified in Article 25 GDPR, is precisely this: privacy is not a choice offered to the user, but a condition of the system. The Italian DPA’s Guidelines, in adopting a simplification aimed at combating consent fatigue, construct a model in which the data subject’s protection depends to a decisive extent on the individual initiative of the recipient — an initiative that, as years of cookie-banner enforcement have shown, is in the great majority of cases not exercised. The result is a system in which consent, formally obtained, covers processing that, in a fully PbD-compliant configuration, would presumably not occur by default.

9. A Second Profile: The Relationship with the Specificity and Granularity Requirements Established by the EDPB

Alongside the system-configuration question discussed under Article 25, a second issue arises, internal to the consent regime under Article 4(11) of the GDPR. The two issues converge but operate on distinct planes: the first concerns the overall design of the processing; the second concerns the validity requirements of consent as a legal basis.

The consent required by Article 122 of the Italian Privacy Code, transposing Article 5(3) of the ePrivacy Directive, refers — as to its notion — to the general data protection framework: Article 2(f) of the ePrivacy Directive equates the consent of the user or subscriber with the consent of the data subject as defined in Directive 95/46/EC, now replaced by the GDPR pursuant to Article 94(2). The EDPB, in its Opinion 5/2019 on the interplay between the ePrivacy Directive and the GDPR, explicitly reiterated this cross-reference. It follows that the requirements of Article 4(11) of the GDPR, as articulated in the EDPB Guidelines 05/2020 on consent, apply in full.

Among these requirements is specificity, which the EDPB articulates as a set of cumulative constraints, including the granularity of the consent request: where processing pursues multiple purposes, consent must be given separately for each. Recital 43 of the GDPR is clear on this point: consent is presumed not to be freely given if it cannot be given separately for distinct processing operations. The setting for granularity is the genetic moment at which consent is formed. Withdrawal, while mandated by Article 7(3) of the GDPR, serves as an additional safeguard rather than a substitute for granularity.

The system outlined by the Italian DPA takes a different path. The data subject’s choice as to each distinct purpose — receipt of the promotional communication on the one hand; tracking of interaction behavior with it on the other — is not formed at the moment of unified consent, but is exercised subsequently through the partial withdrawal mechanism. Granularity is thus attenuated in its genetic, ex ante dimension and entrusted, as compensating safeguard, to ex post granular withdrawal: a configuration that, while formally retaining the prior-consent scheme, presents a potential friction with the criteria established by the EDPB, which identify the granularity of the request — and not merely of the withdrawal — as a requirement of the free and specific expression of will.

Moreover, a logical tension surfaces within the decision’s reasoning. The justification for the simplification rests on the “close correlation between the purposes pursued.” But if the two purposes are so correlated as to be amenable to unified consent, the very premise of their autonomy — the same autonomy that grounds the need for a dedicated tracking consent — is weakened. Either the purposes are autonomous, and genetic granularity applies; or they are so contiguous as to constitute substantially a single processing operation, and the very premise of the separate-consent obligation ought to be reconsidered.

For completeness, it should be noted that policy reasons weigh in favor of the Italian DPA’s choice: consent fatigue is a real phenomenon acknowledged by European practice itself, and simplification may constitute a measure of substantive protection. Yet the point is that this simplification — read together with the reflection set out in the preceding section on Article 25 — builds a system in which data protection is not the default condition and the specificity of consent is attenuated in its genetic dimension. The two profiles reinforce each other: friction with the European consent parameters, on the one hand, and tension with the privacy-by-design principle, on the other, converge to suggest that the model adopted by the decision deserves close observation in its actual application — and, if appropriate, revision through the dialogue among national authorities, the EDPB, and the courts.

10. Compliance Deadline and Operational Recommendations

The six-month deadline from publication in the Italian Official Gazette calls for a compliance path that, for more articulated communication flows, is not trivial. By way of summary, it is advisable to: carry out a review of current email flows, distinguishing by type (newsletters, DEMs, transactional, service) and by purpose; map the providers involved in service delivery, verifying contracts under Articles 26 and 28 GDPR; update notices and consent-collection procedures; implement the granular withdrawal mechanism according to criteria of effective recognizability and accessibility; adopt the privacy-by-design measures suggested by the Italian DPA; and prepare documentation to support proof of consent.

The effectiveness of protection will depend to a significant extent on the quality of implementation — in particular, on the visibility and immediacy of the withdrawal mechanism, which is left to the controller’s discretion.

11. Concluding Remarks

The Italian DPA’s decision is a commendable intervention: it addresses a widespread, objectively invasive technology, aligns it with the applicable legal framework, and provides operational guidance that fills a long-standing gap. The questions it leaves open — which we have flagged from a practitioner’s perspective — do not detract from its systemic value. Rather, they signal that the compatibility between simplification and the European consent parameters remains an evolving terrain, one on which the dialogue among national authorities and the EDPB will continue.

References