Technical evidence and practical guide on three received emails, two of which contain an invisible tracking element.

1. What we examined

Two messages contain an invisible tracking element. A third shows no recognizable pixels in the examined HTML. It is the result of a static check on received emails, without activating links or downloading remote images.

The starting point is a TIM information notice on tracking pixels. That communication also contains an invisible image with an identifier. The comparison with a TIM password notification and a newsletter dedicated to nursing home rights shows why each message must be verified individually.

  • TIM, information notice of 27 October: contains an invisible image (0 × 0 pixels) with an identifier code.
  • TIM, password notification of 19 October: no recognizable pixel detected.
  • RSA Rights newsletter of 27 October: contains an invisible image (1 × 1 pixel, hidden) with two identifier codes, called q and mupckp.

The code makes it possible to document the setup for tracking. It does not prove that a specific opening was recorded, what data was retained, or that a legal basis was lacking.

2. TIM and the comparison between two emails

The information notice on tracking pixels

The message of 27 October 2026 comes from info@info.tim.it with the subject "Informazioni sull'utilizzo dei tracking pixel nelle comunicazioni di TIM". In the preserved headers, Gmail indicates that the sender is authentic (SPF, DKIM and DMARC checks passed). (E1)

The text explains the uses of pixels for statistics, service, and marketing. It also announces that emails containing pixels will carry a notice in the footer about the presence and purpose of tracking.

The code of the message contains this invisible image; its code is reproduced below, without the value of the identifier:

<img height="0" width="0" alt=""
src="https://t2.info.tim.it/r/?id=[OMESSO]">

The message also contains eight links, all directed to the same site and all with an identifier code (id parameter). The beginning of that code is the same in the invisible image and in the links: it is a clue that they belong to the same sending system, but on its own it does not prove that the code is associated with a specific recipient.

The HTML of E1 contains an invisible image with an identifier. The text describes several possible uses of pixels, but from the analysis of the message alone we cannot establish which one applies to that element.

The password change notification

The message of 19 October 2026 comes from tim@timnews.tim.it. Subject "Notifica ripristino password". Here too, the sender is authentic (SPF, DKIM and DMARC checks passed). (E2)

The examined content includes the TIM logo, social icons, and graphic assets with common paths. No recognizable pixels or personal parameters were detected in the links.

What the comparison does not allow us to conclude

The messages have different technical senders, purposes, and structures. They do not prove that TIM began using pixels on 27 October. Reconstructing a timeline requires other comparable communications, in particular earlier newsletters.

3. The newsletter on rights in care homes

The message "Diritti RSA", sent on 27 October 2026, bears the sender name CGIL Piemonte - Federconsumatori Piemonte and the address newsletter@caafcgil.com. The sender is authentic (SPF, DKIM and DMARC checks passed). This concerns the identity of the sender, not the lawfulness of the data processing. (E3)

The evidence in the code

The code contains an image of a single pixel (1 × 1), hidden with a style instruction (display:none!important), so the reader does not see it. It points to an address on the site tr.caafcgil.com (path /e/c) and contains two identifier codes, called q and mupckp. The values are not published to avoid exposing message identifiers.

<img width="1" height="1"
style="...display:none!important;..."
src="https://tr.caafcgil.com/e/c?
q=[OMESSO]&mupckp=[OMESSO]">

Together with the pixel, seven links pass through the same domain: four through the /e/tr path and three through the /e/r path. The eight elements show the same parameter names, q and mupckp; the values of q are all different, while the value of mupckp is identical. We describe here only the observed paths, without attributing the same function to both. Without querying the server we have not verified redirects or logs.

What the recipient sees

The text provides information on an initiative concerning the healthcare share of care home fees. The footer includes "Gestisci la tua iscrizione" and "Cancella iscrizione". No explicit explanation of the pixel or an option clearly dedicated to refusing tracking alone was found. Personal management pages were not opened.

Comparison with public information

The CAAF privacy policy consulted describes newsletter subscription and website traffic data; no explicit explanation of individual open tracking was identified. The Federconsumatori Piemonte website refers to a national policy mainly addressing the website and cookies, with a newsletter section. That policy describes "pixel tags" as tools to monitor website traffic; this reference does not clarify the tracking of the newsletter. (S3, S4, S5)

Outcome. The presence of the pixel is documented. The data controller for this mailing, purpose, configuration of statistics, privacy notice actually provided, and legal basis remain to be established. The health-related informational content does not in itself prove that health data of the recipient was processed.

4. The Garante's guidance

The guidelines of 17 April 2026 issued by the Italian Data Protection Authority (Garante) apply to public and private entities. The use of pixels is governed by Article 122 of the Privacy Code, together with the applicable rules of the GDPR. (S1)

Information and consent

The recipient must be informed in advance, clearly, about the use of pixels and the purposes. For individual tracking of promotional campaigns, informed consent is required; it may be included in the consent to promotional communications, provided the request is neutral. (S1, S2)

Exemptions are not automatic

Exemptions may exist, each with its own conditions. For aggregated statistics the pixels must be the same for all recipients of a campaign and must not allow measuring the individual user. For security, for example, the pixel may serve to verify the authentication of the user. For institutional or service communications, the exemption applies to messages that the controller has a legal obligation to send. Concrete conditions must be verified by the controller. The mere label of "informative newsletter" does not settle the matter. (S1, S2)

Refusing tracking alone

When processing is based on consent, it must be possible to withdraw it for pixels alone as well, continuing to receive communications without service limitations. (S1, S2)

The compliance deadline

The decision grants six months from publication in the Official Gazette on 29 April 2026: the deadline falls on 29 October 2026. This page is dated 28 October 2026, one day earlier. (S1)

How to apply it to the examined cases

For TIM we have a message that openly discusses pixels and contains an invisible element with an identifier. For the "Diritti RSA" newsletter we have the pixel in the code and no explicit explanation in the received text.

These findings support a request for clarification. For an assessment of lawfulness, documentation of the relationship with the recipient and information on actual processing are missing. The fact that a notice does not appear in the email does not in itself prove that no information notice was ever provided.

The summary does not replace an examination of the specific situation.

5. Practical guide for Gmail

On computer

  • 1. Open Gmail and select the settings gear.
  • 2. Open "See all settings".
  • 3. In the Images section select "Ask before displaying external images".
  • 4. Scroll to the bottom and save changes. (S6)

From the Gmail app on iPhone and iPad

Open Menu and Settings. In the Inbox section look for Email preferences, then Images and "Ask before displaying external images". Labels may change with the app version. These instructions apply to Gmail, not to Apple's Mail app. (S7)

What the Gmail actions mean

Action or signalWhat it meansBasis
Blocked images (the setting "Ask before displaying external images")Gmail does not display external images and asks whether you want to see them.Google guide (S6)
Display images belowShows the external images of the message, including any tracking pixels.Label and function: S6. Extension to pixels: deduction
Click on a tracked linkGoes through the measurement server before the destination; blocking images does not prevent it.Passage through the server: Mailchimp (S9). Effect of blocking: deduction

The limits of Gmail's protections

Google explains that its image protections shield information about the computer and location and prevent images from being used to read or set browser cookies. It clarifies, however, that sometimes a sender can tell whether an email was opened. (S6, S7)

Blocking limits the automatic loading of images from that client and applies from the moment it is activated (technical deduction). Google states that a sender can sometimes tell whether an email containing an image was opened (S6), so blocking does not make every interaction anonymous. The sources consulted do not describe what happens to images already loaded, to copies kept in a cache or to other devices, so from the files alone we cannot reconstruct whether an event was already recorded.

A report from the recipient of the emails

After selecting «Ask before displaying external images», the recipient of the three emails reported seeing the Gmail notice «Le immagini non sono visualizzate» ("Images are not displayed"), relating to the TIM notification and the «Diritti RSA» newsletter. This is a report from the recipient of the messages, distinct from the evidence contained in the three EML files. It is not a test carried out directly by the author of this page, it was not verified with screenshots or by measuring network traffic, and it does not allow us to conclude that no request reached the senders' servers or that no opening was recorded. The operating instructions in this section come from Google's official guide (S6, S7), not from this report.

6. Not just pixels

An invisible image is not the only way to detect an interaction with an email. Blocking images limits one detection channel, but leaves other measurements possible.

MethodWhat it can detectBlocking images
External customized visible imageA logo or banner with an individual URL can signal loading.Limits it.
Tracked linkThe route through the measurement server before reaching the destination (S9).Does not stop it.
Web version of the emailAccess to the page, if the link contains identifiers. In E3 the link "Se non leggi correttamente questo messaggio, clicca qui" goes through the /e/r path with the q and mupckp parameters; we did not verify its destination.Does not stop it (deduction: it is not an image).
Read receiptA notification that the email program returns to the sender, only if supported and enabled. Google provides it only for work or school accounts; the recipient may have to approve sending it; it does not apply to group addresses; an IMAP email program that marks a message as read can trigger it even without opening the message; it does not certify delivery (S10).Does not depend on image loading (deduction).

A click can also be counted as an open: Mailchimp writes that it considers those clicks as opens even if the tracking image was not loaded. Tracked links can also be handled in the plain text version of emails. (S9)

Personal Gmail. Google writes that Read receipts are only available for work or school accounts and not for personal @gmail.com accounts. (S10)

Recorded event does not mean human reading. Apple Mail, by default, downloads remote content in the background regardless of whether the user interacts with the email (S11). Mailchimp lists Apple Mail Privacy Protection activity among those that can falsely inflate open and click metrics. (S9)

For this page the consequence is concrete: all URLs of images and links must be checked, not just pixel dimensions. A common graphic asset does not in itself prove individual tracking; an identifier in the path or query requires further examination.

7. Methodology and subsequent verifications

A static and repeatable check

The three original EML files were examined: headers, MIME parts, decoded HTML, images, styles, and link addresses. Invisible elements, URL parameters, and tracking information in the text were searched for. In the public version, personal addresses, tokens, and hashes of the original files are omitted.

We did not open email links, request images from senders' servers, or activate management and unsubscribe pages. Consultation of public sources was carried out separately, without using the personal tokens from the messages.

The distinction that matters

  • Presence in the message: ascertained for the TIM information notice and RSA newsletter.
  • Request to the server: not measured during opening in Gmail.
  • Event recorded and retained: not verified in the sender's systems.
  • Consent or other applicable legal basis: to be reconstructed with the controller.
  • Established violation: not determinable with the files alone.

Questions to ask the sender

Who is the data controller for this specific communication? Does the pixel collect only aggregated statistics or does it allow recognizing the individual recipient? What technical data and events are retained, for how long, and with which vendors?

What is the legal basis invoked? What privacy notice was provided and when? If processing is based on consent, what choice is recorded? How can one continue receiving communications while disabling tracking alone?

The privacy contact published by CAAF is privacy@caafcgil.com; the DPO is listed at privacy@cafcgil.it. These are contact points to ask for clarifications, not proof of the role of each entity in this mailing. (S8)

A useful check on the past

Comparing earlier newsletters of the same type and from the same sender can show whether the pixel structure was already present. Without other evidence, it does not allow dating the start of processing or reconstructing all recipients involved.

Sources

Public sources consulted on 28 October 2026. Personal addresses, token values, hashes, and specific message times are not reproduced.

Examined messages:

  • E1 Informazioni sull'utilizzo dei tracking pixel nelle comunicazioni di TIM (27 October 2026)
  • E2 Notifica ripristino password (19 October 2026)
  • E3 Diritti RSA (27 October 2026)

Editorial note: This page documents three messages, not the entire conduct of the senders. It contains no allegations of wrongdoing. The absence of findings in public research does not exclude separate, earlier, or account-area privacy notices.