The short version

Four things to take away

  • Consent for open tracking was always required. That has not changed.
  • You may now measure individual opens without consent, but only to manage deliverability - frequency, suppressing inactives, choosing another channel - and only on emails the recipient actually asked for.
  • The moment you use open data to optimize campaigns, personalize, profile, or detect fraud, you are back in consent territory.
  • Pixel consent is a separate question from whether you were allowed to send the email at all.

A pixel is not a picture. It is an instruction.

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.

Two lanes

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.

No consent needed

You may measure

CNIL section 3.2

  • Security measures contributing to user authentication, for example confirming that an email carrying an auth code was opened on a terminal known to belong to the intended user.
  • Individual open measurement for deliverability, strictly limited to what is necessary to adjust sending frequency, or to stop sending to inactive recipients (list hygiene).
  • Subject to that same limit, evaluating and adapting the communication channel, to pick an alternative way to reach someone when email is not landing.
  • Keeping a record that an email was opened, where that evidences compliance with a legal obligation to deliver information to the recipient.
  • Per-recipient unique links used to express or withdraw a preference. These authenticate the recipient, so they count as a security measure.

Data minimization

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.

Only emails the recipient asked for

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.

What counts as a transactional email

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.

Being allowed to send the email does not mean you are allowed to track it

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:

  • Order confirmations and other transactional mail
  • Soft opt-in prospecting for similar products to existing customers
  • Charitable prospecting
  • B2B prospecting to professionals in the relevant field

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

Who is responsible

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.

RoleWho that isWhat they are under GDPR
SenderThe 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 platformProvides 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 vendorA 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 providerGmail, 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

How to actually collect the 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.

  1. Say what the trackers do, before asking

    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.

  2. Make the scope of consent legible

    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.

  3. Ask at the point of address collection

    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.

  4. If you cannot, ask later, carefully

    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.

  5. Do not lean on people

    Consent requests must not be built to pressure, and must never obstruct reading the email.

  6. Treat silence as no

    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.

The model wordings, ready to paste

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.

Analysis of email open rates for deliverability purposes
"[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."
Analysing open rates to measure and optimise campaign performance
"[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."
Creating recipient profiles based on expressed preferences and interests, to target you outside email
"[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."
Detection and analysis of suspected fraud
"[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."

Granularity, where most consent screens go wrong

Getting the purposes right and then bundling them into one switch undoes the work. The rules on how finely consent has to be split:

  • The default is consent per purpose.
  • A single global "accept" at the first level is acceptable only if the second level lets people choose per purpose, or per related family of purposes.
  • One consent can cover direct electronic marketing plus pixels serving a directly related purpose. Marketing expressly presented as personalized, where the pixel drives that personalization, is the clean example; so are anti-fraud pixels in a competition email, where they exist to keep entry fair.
  • Unrelated purposes need their own consent. Display advertising and marketing are explicitly two different purposes.
  • Using a web consent management platform for email pixels is possible but risky. People read those as web and app tools, so the consent has to make clear it concerns a different environment and a specific mailbox.

Withdrawal, and proving you had consent

Withdrawal

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.

Proof

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.

Existing lists and the three-month window

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.

Adopted
12 Mar 2026
Published (JO)
14 Apr 2026
Window closed
14 Jul 2026

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.

Where this applies, and where it does not

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.

  • The EDPB guidelines are the EU-wide technical baseline. Pixels and tracking links fall under Article 5(3) of the ePrivacy Directive. The guidelines deliberately do not analyze the exemptions, which is left to national law and national regulators. That is exactly the gap CNIL filled.
  • The CNIL recommendation is French. It applies Article 82 of the French Data Protection Act and is not binding elsewhere.
  • Expect it to be read as a reference point anyway. It is the most detailed application any data protection authority has published, so other regulators and plenty of counsel will reach for it. They may still draw the deliverability line differently.

At a glance

Tracking pixel consent at a glance

  • A tracking pixel is a hyperlink to a remote image with no informational value to the reader, in practice a 1x1 transparent GIF.
  • Rendering a tracking pixel makes the recipient's device fetch it, sending back the pixel ID, the IP address, and often device and timing data.
  • EDPB Guidelines 2/2023 place tracking pixels within Article 5(3) of the ePrivacy Directive, so consent is the default position.
  • Article 5(3) covers information rather than only personal data, and access rather than only storage, which is why a pixel is in scope at all.
  • Tracking links carrying a per-recipient identifier fall under the same rules as image pixels.
  • The CNIL recommendation on tracking pixels in emails was adopted 12 March 2026 and published 14 April 2026 as Deliberation no. 2026-042.
  • Consent is required to analyze open rates for measuring or optimizing campaign performance.
  • Consent is required to personalize content, adapt send frequency, or switch communication channel for marketing reasons.
  • Consent is required to build recipient profiles used to target people outside email, on websites, in apps or on other channels.
  • Consent is required to detect and analyze suspected fraud from email open data.
  • Consent is not required for security measures contributing to user authentication, such as confirming an auth code email was opened on a known terminal.
  • Consent is not required for individual open measurement strictly limited to adjusting send frequency or suppressing inactive recipients.
  • Consent is not required to record that an email was opened where that evidences compliance with a legal obligation to inform the recipient.
  • Per-recipient links used to express or withdraw a preference count as a security measure and need no separate consent.
  • Deliverability tracking without consent should store only the date of the last known open, day only, overwritten on each new open.
  • The tracking exemptions apply only to emails the recipient explicitly requested, which covers transactional email and email the recipient consented to.
  • Consent to receive an email is a separate question from consent to track whether that email was opened.
  • Order confirmations, soft opt-in prospecting, charitable prospecting and B2B prospecting may be sent without consent while still requiring consent to track.
  • The sender is the controller for tracking pixels, even when tracker management is outsourced to an email service provider.
  • A mailbox provider such as Gmail or Outlook is neither controller nor processor for a sender's tracking pixels.
  • Consent must be collected per purpose, and a single global accept is acceptable only where a second level allows a choice per purpose.
  • Display advertising and marketing are two different purposes and cannot share one consent.
  • Withdrawal of consent must be as easy as giving it, and must stop trackers firing when a previously sent email is reopened.
  • The three-month window to inform lists collected before the CNIL recommendation closed on 14 July 2026.
  • The EDPB guidelines are the EU-wide baseline, while the CNIL recommendation applies Article 82 of the French Data Protection Act and is not binding elsewhere.

Questions

Tracking pixel questions

Do email tracking pixels need consent?

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.

What is an email tracking pixel?

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.

Does GDPR ban tracking pixels in email?

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.

Can I track email opens without consent?

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.

Do tracking links need consent as well as pixels?

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.

Does the CNIL recommendation apply outside France?

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.

If I am allowed to send the email, can I track it?

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.

Do transactional emails need tracking pixel consent?

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.

What open data can I keep without consent?

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.

Who is responsible for tracking pixel consent, the sender or the ESP?

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.

Can one consent cover both marketing and tracking pixels?

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.

How do I collect consent for email tracking pixels?

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.

Does a website cookie banner cover email tracking pixels?

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.

What about addresses I collected before the recommendation?

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

Working checklist

The lane markers show which side of the split each item belongs to.

  • List every pixel and tracking link in your sends, and the purpose each one serves.
  • Sort each purpose into the consent lane or the exempt lane. Ambiguous means consent. Consent Exempt
  • Confirm whether the exempt-lane emails are ones the recipient actually requested. Exempt
  • Cut deliverability tracking down to a last-open date, day only, overwritten each time. Exempt
  • Separate the deliverability signal from the campaign-performance signal in your stack, so the exempt lane stays genuinely narrow. Consent Exempt
  • Put tracker information and consent into the address collection form. Consent
  • Build the second-level, per-purpose consent screen. Consent
  • Add one-click withdrawal to the footer, and verify it stops trackers on re-opened old mail. Consent
  • Store per-person consent records, and fix the contracts where someone else collects consent for you. Consent

Sources

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.

Related guides

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.

  • Double opt-in, and how bots break it - how to build a consent record that holds up, and why an opt-in confirmation link that confirms on page load can be completed by the recipient's own security scanner.
  • The List-Unsubscribe header and RFC 8058 - the unsubscribe side, including why per-recipient preference links count as a security measure and therefore sit in the exempt lane above.
  • Non-Human Interactions (NHI) - the automated opens and clicks that make open-rate data a poor basis for anything beyond deliverability in the first place.