Email Tracking Pixels in France: What the CNIL Recommendation Changes

Short answer. On 12 March 2026 the CNIL adopted a recommendation on tracking pixels in emails, published in the Journal officiel on 14 April 2026, followed by a 27-question FAQ on 22 July 2026. The CNIL says the recommendation is neither regulatory nor exhaustive: the binding obligation comes from Article 82 of the French Data Protection Act. Four pixel purposes sit on the consent side, including campaign performance measurement. Only two are exempt: authentication security and deliverability. The least intuitive part: the pixel regime is independent of the sending regime.

An open pixel is a one-by-one image loaded from your email platform's servers. It is also the foundation of a large share of any CRM program: open rate, engagement segments, flow triggers, sunset policy. In 2026 the CNIL published two documents setting out how it reads Article 82 of the French Data Protection Act on this specific point.

This guide covers what those documents say, with a link to the source behind each claim, and flags what they do not say. None of this is legal advice.

1. What the CNIL published, and the exact status of the text

The text is deliberation no. 2026-042 of 12 March 2026, published in Journal officiel no. 0088 on 14 April 2026, the same day the dedicated CNIL page went live. The draft went through a public consultation from 12 June to 24 July 2025.

The PDF states its own status in the introduction: the recommendation is "neither regulatory nor exhaustive". The obligation itself has existed since 2019 and comes from Article 82 of the French Data Protection Act, which makes any read or write operation on a user's terminal equipment conditional on consent, subject to two narrow exceptions.

On 22 July 2026 the CNIL added a 27-question FAQ, the most useful document in practice because it settles concrete cases. At European level, EDPB guidelines 2/2023 already treated the pixel reaching the terminal as storage and the collection of the associated identifiers as gaining access.

2. Why a one-pixel image falls under Article 82

Part 2.1 lays out the reasoning: embedding the pixel amounts to an instruction given to the recipient's terminal to send back targeted information (pixel identifier, IP address, and so on), and the collection of that information by the server hosting the image is a read operation on that terminal.

The operational consequence is widely misread. What triggers Article 82 is that read on the terminal, not the storage of the event in your database. A setup that lets the pixel load and simply refrains from logging the open is not addressing the same object the text targets.

The scope is broad. The FAQ (question 3) applies the recommendation to any use of trackers in emails, whatever the context and whatever the status of the recipient, including an employee. Question 2 adds that the CNIL can investigate players established outside France without going through the European one-stop-shop mechanism. Part 2.2 classifies the sender as controller and the email service provider as processor.

3. The pixel regime is decoupled from the sending regime

This is the point that surprises CRM teams most, and it is stated explicitly. A "Point d'attention" box says the consent regime for pixels is independent of the one that applies to sending the email. Consent for the pixel can therefore be required in emails that need no consent to be sent at all: order confirmations, prospecting for similar products among your own customers, B2B prospecting. Question 16 of the FAQ works through the concrete cases.

Translated for an ecommerce account: your cart recovery flow, even sent to a fully opted-in list, gets no pixel exemption. Your order confirmation does, as long as you do not slip a cross-sell into it.

4. Four purposes under consent, two exemptions

Part 3.1 lists the purposes that call for consent:

1. analysing open rates to optimise campaign performance, by personalising content or adjusting frequency or channel;
2. building profiles from stated preferences and interests, in order to target people in contexts other than email;
3. detecting suspected fraud, for instance unusual or mass opens;
4. individual open-rate measurement for deliverability purposes, outside the exemption below.

Part 3.2 keeps only two exempt purposes: security measures contributing to user authentication, and individual open-rate measurement for deliverability purposes. Both can only cover emails requested by the recipient or attached to a service they requested, the recommendation leaning on the notion of express request in Article 82.

5. The deliverability exemption comes down to the columns you keep

This is where compliance becomes a database audit rather than a checkbox. The CNIL asks controllers to demonstrate that operations stay limited to what is strictly necessary to adjust frequency or stop sending to inactive recipients. On data minimisation, it adds that in principle only the date of the last known open should be kept, to the day and without the hour, overwritten at each new open.

Two answers close the usual escape routes. Question 5 removes the exemption as soon as the pixel collects information that is not strictly necessary, and cites the open time as an example. Question 7 says that anonymising or deleting the IP address or user agent after the fact does not undo the fact that they were collected beyond what was needed.

Compare that with an ESP's factory settings. Klaviyo documents that an open event stores the account, the recipient, the message, the timestamp, the IP address and device or browser information. Brevo documents that its pixel counts opens, estimates location and time zone, determines device type and identifies the email address. Neither looks like the single column the CNIL describes.

Question 8 spells out what to do with the signal: a lack of opens should lead the sender to treat the channel as ineffective for that recipient, with three listed follow-ups, stopping sends and removing the person from the database, lowering frequency, or switching to another channel. That is the logic of a disciplined sunset policy and list hygiene routine.

The anonymous statistics argument does not help either: the audience measurement style exemption exists in the web cookies and trackers corpus, not here, and question 18 recalls that Article 82 applies whether or not the data is personal. Only downstream reuse escapes this, provided the original collection was lawful (question 6).

6. Collection, withdrawal, proof and the timeline for an existing list

Part 4.2 recommends collecting consent at the moment the email address is captured, with information identifying the address concerned and making clear that trackers will be dropped on every device used to read the mail. Your signup forms deserve a fresh read against that standard. Deferred collection remains possible through a message that carries no consent-based pixel, with a link leading to a page where the person takes a positive action, so that automatic prefetching cannot count as agreement.

Three points for implementation: silence counts as refusal, a pixel cannot be dropped purely in anticipation of future consent (question 10), and proof cannot rest on a contractual clause delegating collection to the other party (part 6). For withdrawal, the CNIL recommends a tracked footer link leading to a page that does not require re-entering the address; question 22 refers to a mechanism that ignores any request carrying a pixel identifier whose consent has been withdrawn.

For addresses already on file, part 7 allows operations to continue provided clear and accessible information is sent within a period that should in principle not exceed three months. Question 25 sets the starting point at 14 April 2026 and allows a reasonable extension where difficulties are documented. Past 14 July 2026 with no information sent, question 26 makes the rules applicable, failing which the sender must stop using the pixels concerned. On enforcement, the CNIL announces support and then vigilance as part of its future investigations, with no date or theme, and no penalty figures appear in these documents.

7. Klaviyo and Brevo: what the tools do, where their docs diverge

Klaviyo published a dedicated article on tracking pixel regulations and hands the legal qualification back to the customer. Its open tracking controls work at account level, or per recipient through a three-value status that can be loaded by CSV, API or SFTP, with one limit documented honestly: the pixel stays in the email and the request still reaches Klaviyo's servers, only the recording is blocked. Brevo built a per-contact consent setup with dedicated attributes, a configurable default for contacts whose consent is unknown, a field in the transactional API and a footer withdrawal link.

Four gaps between those docs and the CNIL texts tend to circulate afterwards as rules:

• Brevo calls the recommendation binding. The CNIL writes that it is neither regulatory nor exhaustive.
• Brevo presents the footer withdrawal link as mandatory since 14 April 2026. The CNIL frames it as a recommendation.
• Brevo's internal FAQ describes the deliverability exemption as covering global, aggregate tracking only. Part 3.2 exempts individual measurement, under conditions.
• Brevo limits the scope to marketing content sent to contacts based in France. Question 3 of the FAQ describes a broader material scope.

The CNIL has approved none of these products. No setting, in any tool, makes an account compliant by itself.

8. What the sources do not settle

Apple Mail Privacy Protection. Neither the recommendation nor the FAQ mentions MPP, proxy image prefetching or machine opens. The closest reference, in part 2.2, notes that the mailbox provider can influence a pixel's ability to trigger a read, without drawing any legal conclusion from it. The friction is real: the deliverability exemption rests on detecting inactives through opens, and both Klaviyo and Brevo document that a human open cannot be told apart from an automated one under MPP. The business side is covered in our guide on Apple MPP and email metrics.

Click tracking. Question 1 of the FAQ says tracked links are not directly targeted by the recommendation while still falling under Article 82, with a case-by-case analysis still to be done. No conclusion can be drawn either way. The same applies to identifying recipients located in France inside a multi-country list: no reliable method is described.

Want to know what your account actually records? An expert reviews your settings and segments in an email program audit.

FAQ

Is open rate banned in France?

No. The recommendation places open-rate analysis aimed at optimising campaigns among the purposes requiring consent, and exempts individual measurement for deliverability under the conditions in part 3.2. Everything turns on the purpose pursued and the data retained.

Are my transactional emails affected?

The pixel regime is independent of the sending regime. The FAQ answers case by case: yes for a purchase confirmation or a subscription renewal, provided they carry no promotional elements; no for an abandoned cart reminder, which it treats as a promotional email.

What happens to a list collected before April 2026?

The recommendation allows operations to continue provided clear and accessible information is sent within a period that should in principle not exceed three months from 14 April 2026, extendable where difficulties are documented. Past that deadline with no information sent, the FAQ makes the rules applicable.

Is turning off open tracking in my ESP enough?

No public source supports that claim. Klaviyo documents that the pixel stays in the email and the request still reaches its servers, with only the recording blocked, whereas the CNIL anchors Article 82 in the read on the terminal. The CNIL has taken no position on any product.

→ Book a diagnostic of your email program

Further reading

• Apple MPP: which email metrics to track
• SMS and GDPR in France: the CNIL rules
• Email list hygiene
• Klaviyo sunset flow: cutting dead contacts
• The 12 lifecycle email KPIs

Charlotte Rodrigues, CRM Lead at Deliver.