Guide
European regulators have confirmed that an open pixel is a read/write operation on the recipient's device, so consent is the default. What is new is a narrow, usable exemption for measuring opens purely to protect deliverability. This page maps which purposes sit on which side of that line.
Last reviewed September 2026
The short version
A tracking pixel is a hyperlink to a remote image with no informational value to the reader, in practice a 1x1 transparent GIF. Rendering it makes the recipient's device fetch it, and that fetch sends back the pixel ID, the IP address, and often device and timing data.
The EDPB's point is that Article 5(3) of the ePrivacy Directive covers information, not just personal data, and covers access, not just storage. Adding an identifier to an image URL is an instruction to the terminal to send that identifier back, and that is "gaining access". Even the client-side cache counts as storage, so temporary is still in scope.
The same logic covers tracking links, a click URL carrying a per-recipient identifier, and not only image pixels. If you are auditing your sends, the links count too.
Scope note
This is about email. Captive messaging inside a bank portal or a similar closed environment runs on different protocols and sits outside this analysis.
Every pixel and every tracking link in your sends belongs in one of these. If a purpose could plausibly sit in either, it sits on the left.
CNIL section 3.2
In principle, store only the date of the last known open, day only and no time, updated on each new open with the previous value deleted. A last-open date, not an open log.
The exemptions rest on the "explicitly requested by the user" carve-out, so they cover transactional emails and emails the recipient consented to. They do not rescue a cold campaign.
The whole exempt lane hangs on this definition, so it is worth being exact about it. A transactional email is triggered by a specific user action or event, is informative or functional rather than promotional, and is necessary to the contract or to the service the recipient requested.
In practice: welcome emails, account alerts, shipping notices, order confirmations and invoices, password resets, support replies, appointment and booking reminders, payment notifications, and service incident notices.
Public-sector emails sent as part of a public service mission sit in the same place, including proactive outreach about a right someone could claim.
The consent regime for pixels is independent of the consent regime for sending. Those are two different questions with two different answers, and conflating them is the single most common mistake in this area.
So pixel consent can be required inside emails that need no send consent at all:
Each of those is a message you may lawfully send. None of them comes with permission to measure whether it was opened, unless the purpose sits in the exempt lane above.
Who carries it
Roles under the GDPR, as the CNIL recommendation allocates them. The distinction that matters commercially is the last column: a processor acts on instructions, a controller answers for the purpose.
| Role | Who that is | What they are under GDPR |
|---|---|---|
| Sender | The brand that decided to send. | Controller, even when it outsources tracker management to an ESP. In principle also joint controller with third parties whose trackers it agreed to have placed in its emails. |
| ESP / sending platform | Provides the sending technology and the pixel feature. | Processor, acting on the sender's instructions. Becomes joint controller where it also uses pixel data for its own purposes, such as improving its own list quality or deliverability, and the client has contractually agreed to that. |
| Tracking vendor | A specialist third party. | Processor if it acts exclusively for the sender. Joint controller if it also uses the data for itself, for example to improve its own product. |
| Mailbox provider | Gmail, Outlook. Receives and displays the mail, and can block image loading, but does not use the pixel data. | Neither controller nor processor. |
For Omnivery clients the practical answer is that the obligation sits with the sender. The platform can make compliance easy; it cannot absorb the liability.
Collecting consent
Order matters here in a way it does not elsewhere: each step depends on the one before it, and skipping the first invalidates everything built on top of it.
Each purpose gets a short title plus a brief description, in language the recipient can act on. The full detail sits one click away, behind a disclosure control or a link to the trackers policy. CNIL published model wordings for the four common purposes; they follow this list.
The recipient must be able to tell which email address the choice applies to, and understand that the trackers will load on every device where they read that mailbox.
Best practice is that the information and the consent live in the signup form itself, with a link to the trackers policy. The link between "here is my address" and "here is what will be in the emails" is what makes the consent informed.
Send an email containing no consent-requiring tracker, with a link to a choice page. Guard against mail clients that pre-fetch links: the link must land on a page where the recipient takes a positive action, clicking a button, the way unsubscribe confirmations work. Use a unique link per recipient so only the mailbox owner can answer.
Consent requests must not be built to pressure, and must never obstruct reading the email.
Inaction is a refusal. Refusing must be as easy as accepting. Record the answer and leave people alone afterwards - roughly six months without re-asking is considered good practice.
CNIL published wording for each of the four common purposes. They are reproduced verbatim below, including CNIL's own spelling, because the point of a model wording is that you do not rewrite it. Substitute your own name for [Sender] and name the third parties explicitly.
"[Sender] and [third parties] use trackers (tracking pixels) to determine if and when you open emails, in order to establish distribution statistics and take the necessary actions (adjusting the frequency or stopping sending) to manage the distribution lists."
"[Sender] and [third parties] use trackers (tracking pixels) to know if you open emails, the time you do so, and information about the device you use, in order to personalise the content of messages, adapt the sending frequency, or the communication channel used."
"[Sender] and [third parties] use your preferences (for example, emails you have opened or topics that interest you) to offer you tailored content or advertisements on other sites, applications or communication channels."
"[Sender] and [third parties] use tracking technologies (tracking pixels) to detect and analyse suspected fraud. These technologies allow us to know if you open emails, when you do so, and to obtain information about the device you are using."
Getting the purposes right and then bundling them into one switch undoes the work. The rules on how finely consent has to be split:
Withdrawal must be as easy as consent, and available at any time. The practical shape is a per-recipient link in the footer of every email, landing on a page that withdraws in one action, with no form and no re-typing of the address.
It has to work going forward, and because old emails get reopened, you need a way to stop previously deployed trackers from firing on a re-open. That is the part most implementations miss: the withdrawal updates the database and the pixel in last month's newsletter keeps loading.
Consent has to be demonstrable per person, including the conditions under which it was obtained.
Where a third party collected the address and the consent on your behalf, a contractual clause saying "they got consent" is not proof. The contract should instead govern how valid consent is demonstrated, how the evidence reaches you, how long it is kept, and how the mechanism gets audited. If the third party fails, the liability is still yours.
Tracking already running on addresses collected before the recommendation was published could continue, but only on a condition with a deadline attached: clear, accessible information about the trackers had to reach those recipients within, in principle, three months of publication, so that anyone whose consent was not obtained as described could object to future emails. That window has closed.
The recommendation was adopted on 12 March 2026 and published in the Journal officiel on 14 April 2026 as Deliberation no. 2026-042. The three-month window therefore closed on 14 July 2026. If that information has not gone to your pre-existing lists, this is remediation rather than planning.
If you are going back to those recipients anyway
Where you return to a pre-existing list for fresh consent - to pass their data to new controllers for marketing, say - you have to obtain valid consent for the non-exempt tracking at the same time. One contact, both permissions.
There is no single European rulebook here, and treating the French recommendation as one is the way to get this wrong in the other direction.
At a glance
Questions
As a default, yes. The EDPB has confirmed that an open pixel is a read/write operation on the recipient's terminal under Article 5(3) of the ePrivacy Directive, which makes consent the starting position rather than something you need only for certain data. The exceptions are narrow: security measures contributing to authentication, and individual open measurement strictly limited to managing deliverability. Everything to do with measuring or optimizing campaign performance needs consent.
A tracking pixel is a hyperlink to a remote image with no informational value to the reader, in practice a 1x1 transparent GIF. When the mail client renders the message it fetches that image, and the fetch sends back the pixel ID, the IP address, and often device and timing data. That is how an open is recorded. Nothing is visible to the recipient, which is precisely why regulators treat it as access to the terminal rather than as displaying a picture.
No. Nothing bans them. The rules govern when you need permission before one loads and what you may do with what it tells you. The relevant provision is Article 5(3) of the ePrivacy Directive rather than the GDPR itself, though the GDPR supplies the standard the consent has to meet and the rules on who is responsible for it.
Only for a short list of purposes. Individual open measurement is permitted without consent where it is strictly limited to adjusting sending frequency, stopping sending to inactive recipients, or picking an alternative channel when email is not landing. Two conditions clamp it: in principle you store only the date of the last known open, day only and overwritten each time rather than kept as a log, and it applies only to emails the recipient explicitly requested. The moment the same data informs campaign performance, personalization or profiling, consent is required.
Yes, where the link carries a per-recipient identifier. The EDPB's reasoning is about the identifier, not the image: adding an identifier to a URL is an instruction to the terminal to send that identifier back, which is gaining access to information stored on it. A click URL unique to one recipient does that just as much as an image URL does. If you are auditing your sends, audit the links too.
No. It applies Article 82 of the French Data Protection Act and binds nobody outside France. It is nonetheless the most detailed application of Article 5(3) to email that any data protection authority has published, so expect other regulators and plenty of counsel to reach for it as a reference point. They may still draw the deliverability line differently. The EDPB guidelines are the EU-wide baseline, and they deliberately leave the exemptions to national law, which is the gap CNIL filled.
Not necessarily, and this is the most common mistake in this area. The consent regime for pixels is independent of the consent regime for sending. Order confirmations, soft opt-in prospecting for similar products to existing customers, charitable prospecting and B2B prospecting to professionals in the relevant field are all messages you may lawfully send without consent. None of them comes with permission to measure whether they were opened, unless the purpose sits in the exempt lane.
It depends on the purpose, not on the type of email. Transactional emails qualify as explicitly requested by the recipient, which is one of the two conditions the exemptions rest on, so open measurement for deliverability is available on them without consent. That does not make them a free-tracking zone: analyzing opens on a transactional message to optimize campaign performance or to build a profile still requires consent, exactly as it would on a newsletter.
In principle the date of the last known open, day only and no time, updated on each new open with the previous value deleted. That is a last-open date, not an open log, and the difference is the whole point: the exemption exists to let you manage a distribution list, not to accumulate an engagement history under a deliverability label. If your stack cannot hold that field separately from campaign analytics, the exempt lane is not genuinely narrow and the exemption is doing no work for you.
The sender is the controller, even when tracker management is outsourced. An email service platform is a processor acting on the sender's instructions, and becomes a joint controller only where it also uses the pixel data for its own purposes, such as improving its own list quality, and the client has agreed to that contractually. A mailbox provider like Gmail or Outlook is neither controller nor processor: it displays the message and can block image loading, but does not use the data. The practical answer is that the obligation sits with the sender; a platform can make compliance easy but cannot absorb the liability.
Sometimes. One consent can cover direct electronic marketing plus pixels serving a directly related purpose, such as marketing expressly presented as personalized where the pixel drives that personalization, or anti-fraud pixels in a competition email where they exist to keep entry fair. Unrelated purposes need their own consent, and display advertising and marketing are explicitly two different purposes. The default remains consent per purpose.
Best practice is to put the information and the consent in the signup form itself, at the point where the address is collected, with a link to the trackers policy. Each purpose gets a short title and a brief description the recipient can act on. If you have to ask later, send an email containing no consent-requiring tracker with a link to a choice page, and make the choice page require a positive action such as clicking a button, because mail clients pre-fetch links. Use a unique link per recipient so only the mailbox owner can answer. Silence is a refusal, and refusing must be as easy as accepting.
Using a web consent management platform for email pixels is possible but risky. People read those tools as web and app controls, so the consent has to make clear that it concerns a different environment and a specific mailbox. The recipient must be able to tell which email address the choice applies to, and understand that the trackers will load on every device where they read that mailbox. A generic web banner that says nothing about email is unlikely to carry that meaning.
Existing tracking on those addresses could continue provided clear, accessible information about the trackers reached those recipients within, in principle, three months of publication, so anyone whose consent was not obtained as described could object to future emails. The recommendation was published on 14 April 2026, so that window closed on 14 July 2026. If the information has not gone out, this is remediation rather than planning. And if you return to those recipients for fresh consent anyway, obtain valid consent for the non-exempt tracking at the same time.
What to do
The lane markers show which side of the split each item belongs to.
This page is a summary written for people who run email programs. It is not legal advice, and it does not replace your own counsel's read of either document.
Consent to be emailed, consent to be measured, and the mechanics of getting into and out of a list are three separate questions. These cover the other two.
The exempt lane only stays exempt if the data behind it stays narrow. Omnivery keeps delivery telemetry separate from engagement analytics, and processes under an EU entity with no US sub-processors in the core email service.