By William Weiner July 20, 2026
The guidance this blog covered earlier in July treats an email tracking pixel like a cookie and requires consent for it in most cases. It also carves out an exemption for one specific use: measuring whether an email was opened, for the narrow purpose of keeping a mailing list’s deliverability healthy. That exemption is real, and read in full it is narrower than most summaries of it suggest. It is also written loosely enough, in one specific place, that a sender inclined to stretch it has room to do so. This post is about that one place, and about how it should eventually be closed.
The exemption is not a bad-faith invention. Mailbox providers punish senders in aggregate for mailing addresses nobody reads, and finding those addresses without reading anyone’s mail is a real, unsolved technical problem, not a hypothetical one. That is exactly why an unconsented pixel should be a bridge, not a destination: the pieces of a less invasive fix already sit inside infrastructure the industry controls, and what has been missing is a deadline forcing someone to put them together.
What the exemption actually covers
CNIL’s recommendation separates pixel purposes into two lists. Section 3.1 requires consent for four things: measuring open rates to optimize campaigns, building recipient profiles to target people outside of email, detecting fraud, and measuring open rates for deliverability when that measurement falls outside the exemption. Section 3.2 is the exemption itself, and it covers exactly two purposes: pixels tied to authentication security, and the individual measurement of open rate for deliverability.
The deliverability half of that exemption comes with real conditions attached, not a blank check. The controller has to show the operation is limited to what is strictly necessary to adjust sending frequency or stop sending to recipients who have gone inactive, what the text calls database cleaning. Data minimization is specific and unusually concrete for a regulatory document: only the date of the last known opening should be kept, at the day level with no time recorded, and that single value gets overwritten at every new opening with the previous one deleted. No history. No timestamp. One field, always current, never accumulated.
Profiling sits nowhere near this exemption. It is its own listed purpose under section 3.1, defined as the creation of recipient profiles based on preferences and interests in order to target people in contexts other than email. A sender using open data to build an interest profile or feed an advertising audience cannot borrow the deliverability exemption to cover it. The two purposes are kept structurally separate in the text, and CNIL was careful enough to add a note most companies will not expect: consent for a tracking pixel is independent of consent for the email carrying it. The recommendation states this directly, giving its own example of an order confirmation as a message that needs no consent to send but can still need separate consent for the pixel riding inside it. That is a deliberate design choice, not an oversight.
The loose seam
Where the exemption gets genuinely loose is in how it decides which emails qualify in the first place. Article 82 of the Data Protection Act, which the exemption is built on, only reaches emails requested by the recipient or tied to a service the recipient requested. CNIL’s text operationalizes that with a category it calls transactional email, and defines it as a message triggered by a specific action or event of a user, sent to provide important information about a requested service, account, or transaction, and states plainly that it is not a promotional message but an informative or functional one, necessary for the contractual relationship or the requested service.
Read that definition alone, and it is tight. Read the examples CNIL gives right underneath it, and the seam opens up. The list includes welcome emails, account alerts, notifications related to events such as shipping a package, order confirmations and purchase invoices, reminders and password resets, responses to requests sent to customer service, reminders of appointments or reservations, payment notifications, and breach notification emails. Password resets, shipping notices, and payment notifications are unambiguous. A welcome email is not. A welcome email is functionally adjacent to onboarding marketing, and CNIL’s recommendation does not draw a hard line preventing a sender from labeling an email as transactional welcome content when its actual substance leans promotional.
The seam does not stop at welcome emails. An abandoned-cart reminder, triggered by a user adding an item and leaving before paying, satisfies the definition’s own test on its face, but its purpose is converting a browsing signal into a sale, a marketing function by any ordinary reading of the term. It does not appear anywhere in CNIL’s own example list, so a sender relying on it is reasoning by analogy, not pointing to text that actually names it.
A second version of the problem does not require mislabeling anything at all. An order confirmation or shipping notice is squarely transactional, no argument needed. Nothing in the recommendation says whether that changes when the sender adds a people-who-bought-this-also-liked module underneath the tracking number, genuinely promotional content riding inside a genuinely transactional message. The text gives no answer for whether mixed content forfeits the exemption, or whether a paragraph of transactional content anywhere in the email is enough to cover the pixel and the upsell alike.
That gray zone, in all three shapes, is the real loophole, not a blanket deliverability carve-out any sender can claim for any list. It sits in the classification step upstream of the exemption: whether a given message, or a given piece of one, is the transactional content the exemption was written for, or promotional material riding under that label, whole message or just the part a sender points to. CNIL wrote a careful rule, then gated it with an example list that does not hold its own opening sentence’s line, and says nothing about what happens when transactional and promotional content share one message.
The exemption also assumes something it never verifies: that the sender’s own classification is honest. Nothing requires a sender to prove a message is transactional before using the exemption, only to demonstrate it later if CNIL asks. That is reasonable for senders who intend to comply, and a much weaker constraint on one who never planned to. A rule enforced by trusting the classification behind the scenes protects careful senders and does close to nothing, by design, about a sender willing to lie about what kind of email it sent. Most consent carve-outs work this way, but it is worth stating plainly here: the transactional label is exactly the self-serving classification a bad-faith sender has every incentive to reach for, with very little risk of getting caught.
A signal, not a delivery receipt
Even in the narrowest, most legitimate reading of the exemption, used exactly as CNIL specifies, the resulting signal is still meaningfully more than a delivery receipt. A date-only, single-value, always-overwritten open record tells a sender that a specific person opened a specific message on a specific day. That is a fact about a person’s behavior, not a fact about whether mail reached a mailbox.
It is worth being precise about what actual delivery infrastructure tells a sender, because it is genuinely less than that. SMTP bounce codes and DMARC, SPF, and DKIM aggregate reports confirm whether mail arrived at a mailbox that exists. They say nothing about whether a human being read anything. The exemption’s own data, collected exactly within its own limits, crosses that line. It is behavioral engagement data, narrowly scoped and tightly minimized, but behavioral engagement data all the same. That distinction deserves a plain statement rather than a footnote: an exempted pixel is not a bounce report with better manners. It is a smaller, more disciplined version of the same signal the rest of section 3.1 requires consent for.
For a sense of what email tracking looks like in practice, a corpus read of 1,500 real emails examined every tracking mechanism in a month of mail, not pixels alone: open-tracking images, rewritten click-tracking links, and the query-string parameters carried inside them. It found a tracking pixel on 51.2 percent of messages to the address used daily for personal correspondence, and 92.6 percent to the older address, which has picked up a wider base of newsletter and promotional subscriptions over its longer life; the same recent month was examined for both, so the difference is in how many senders each address has accumulated, not how far back the analysis reached. Across all three mechanisms, well over half of the tracking parameters seen often enough to classify reset to a new value on nearly every message, a per-recipient identifier rather than a campaign counter. That corpus was not built to isolate exempted deliverability pixels from everything else it found, and none of these figures are a claim about what an exempted pixel specifically does; they show what the broader tracking ecosystem the exemption sits inside actually looks like.
Where the need actually came from
The exemption did not appear because CNIL decided deliverability data was harmless. It appeared because senders have a real, external reason to need it, one that has almost nothing to do with marketing. Major mailbox providers score sender reputation in aggregate, at the level of the sending domain and IP address, not recipient by recipient, and engagement is a standard input into that score, not just spam complaints: a provider’s filtering systems watch how a domain’s recipients treat its mail as a whole, and a domain whose messages are piling up unread across a meaningful share of its recipient base looks the same to those systems as a domain sending mail nobody wants. That domain can see delivery throttled or routed to spam across its entire recipient base, including the people who open and read every message it sends. This is standard, widely documented practice across major mailbox providers, not a Gmail-specific quirk, though Gmail’s own sender guidelines confirm the related piece that is officially documented: spam complaints “over time” lower a domain’s reputation, and on a shared IP, one sender’s activity affects every other sender using it.
The mailboxes that make this concrete are the ones commonly called ghost or zombie addresses: accounts that still accept mail without bouncing or complaining, but where nobody has actually read anything in months or years. Nothing about a ghost address looks broken from the outside, so a sender has no way to see the risk coming from bounce codes or authentication reports. What a provider does see, watching in aggregate, is a growing share of a domain’s mail going unopened, and that is exactly the pattern its filtering systems read as a domain sending mail nobody wants, dragging delivery down for the addresses that are still read right alongside the ones that are not. A fully abandoned address, not just an ignored one, carries a second risk on top of that: providers are known to eventually recycle long-dormant addresses into spam-trap honeypots, and continuing to mail a formerly real address straight through that transition is one of the more reliable ways to trigger a hard reputation hit. Identifying and pruning ghost addresses before either outcome happens is precisely the purpose CNIL’s own text names for the exemption: limited to what is strictly necessary to adjust frequency or stop sending to so-called inactive recipients, what it calls database cleaning. Read that way, the exemption is a defensive response to a reputation system senders do not fully control and cannot fully see, and it is genuinely in the interest of engaged recipients too: a clean list is a domain more likely to stay out of the spam folder for the people who are still reading.
That is a real need, and it is not the same question as whether a given email is transactional or promotional, which is where CNIL’s exemption loses the thread. Reputation risk from dead addresses is not concentrated in transactional mail; if anything it runs the other way, since a bulk marketing list accumulates ghost recipients faster than a transactional stream ever does. The transactional boundary is not there because CNIL concluded reputation protection matters most for transactional senders. It is there because Article 82’s separate “express request” requirement only lets an unconsented exemption attach to email the recipient asked for, and transactional mail was the available category that fit. The scope of the exemption was set by a different piece of statutory text than the technical problem it was built to solve, and that mismatch, not bad faith anywhere in the chain, is what leaves the transactional-email label as the loose seam described above.
A real need is not a reason for a permanent exemption
None of this argues CNIL should have refused senders any tool here. Providers built reputation systems that punish good senders alongside careless ones, and finding and pruning genuinely dead addresses is a legitimate response to that, not a smokescreen. But a real need does not require an unconsented, individual-level tracking mechanism to be a permanent fixture of email, and the exemption is not even solving the reputation problem well on its own terms: scoped to transactional mail for reasons unrelated to reputation, it withholds the tool from exactly the bulk marketing traffic where dead-address accumulation is worst.
It is also a problem the sender should not have to solve alone. One-click unsubscribe, the direction mailbox providers are already pushing senders toward to cut spam complaints, does not reach the addresses that actually damage reputation: a recipient has to open a message and choose to click before an unsubscribe link does anything, and a ghost address is a ghost address precisely because nobody opens anything there at all. That signal is worth having, but it solves a different, real problem, a recipient engaged enough to be annoyed, not the one this exemption is named for.
For the ghost account case, an address that never bounces and never complains but nobody reads, the honest version of a fix looks like what providers already do for delivery status, not what a pixel does for opens: an occasional, low-resolution rejection returned through the same bounce channel senders already parse, fired on a sample of messages to an address a provider’s own systems judge stale, rather than a precise per-message record of who read what and when. Google’s own Postmaster Tools, notably, reports spam rate, domain and IP reputation, authentication, and delivery errors today, not opens or engagement; the raw signal exists somewhere inside these systems, a standardized, coarse version of it for senders does not. This is not a proposal for what the mechanism should look like in detail; that engineering decision belongs to the parties who run the infrastructure, not to a blog post. It is an existence proof that a coarser, non-behavioral path is possible with tools these systems already have, which is exactly why an unconsented, per-message pixel does not need to be the permanent answer, only the bridge until a proper one exists.
The open signal itself is also thinning out on its own, for reasons that have nothing to do with consent law. Apple’s Mail Privacy Protection, by Apple’s own description, downloads remote content in a message automatically in the background, whether or not the recipient ever engages with it. For a recipient with that protection on, the deliverability pixel fires the moment Apple’s relay touches the message, not when a human opens it, so the one date field the exemption’s minimization rule is built around can no longer tell a message that was read from one that never was. That is not a gap CNIL created and not one a tighter transactional-email boundary would close. It is independent evidence that the signal underneath this exemption is already eroding before regulation touches it at all.
CNIL’s recommendation is guidance, not statute, so it can build in its own expiration without waiting on legislation, and it should: the gap this exemption stands in for, providers turning what they already know into a usable signal, is a technical problem, not a regulatory one, and a technical problem gets solved on a deadline or it tends not to get solved at all. A review clause with no expiration lets the exemption run indefinitely while everyone waits for someone else to do the work. A dated sunset, three to five years out, after which the unconsented deliverability exemption simply lapses. This gives the industry a real deadline instead of an open-ended grace period it has every incentive to let run forever. A stopgap needs an expiration date to stay a stopgap; without one it is just a permanent carve-out nobody ever had to justify twice.
How EMail Parrot removes the pixel, not just the exemption
None of the classification questions above have to get answered correctly on a list running through EMail Parrot with tracking-content removal on, which is the default. Tracking pixels and remote content are stripped before delivery regardless of what purpose a sender claims for them or whether their transactional label would survive a close read of CNIL’s own text.
That is a real difference on both ends of the delivery. A sender running a list through EMail Parrot never has to get the transactional-versus- promotional call right, or worry that a mislabeled abandoned-cart reminder or an upsell module riding under a shipping notice creates consent exposure, because the pixel a sender might otherwise rely on for deliverability data is not doing that job here. A recipient gets more protection than the exemption would deliver even if every sender using it were scrupulously honest: not just the pixels section 3.1 requires consent for, or the ones section 3.2 exempts, but every tracking pixel, remote image, and click-tracking link in the message, regardless of which purpose a sender would have claimed for any piece of it.
Where this leaves you
The exemption CNIL wrote is tighter than a quick read suggests, responds to a real problem senders did not invent, and is still looser than it should be in one specific place: a transactional-versus-promotional line that ended up where it did because of unrelated statutory wording, not because that is where the reputation problem actually lives. That is a narrow, precise gap, not a general failure of the rule, and it should come with a deadline attached, not a promise to look again someday.
None of this is theoretical about how the industry behaves once a boundary is this loosely drawn. One compliance guide written for marketers puts it plainly: the moment a deliverability pixel starts feeding behavioral analytics, lead scoring, or automation triggers, it is back inside the consent requirement, and in that piece’s own assessment, most marketing stacks are already on the wrong side of that line. A boundary enforced by trusting a sender’s own classification is exactly the kind of gap a consulting specialty grows up around: there are already ad-tech professionals publicly building a practice on tracking, consent, and data flow, the pitch being systems built, inspected, and rebuilt to survive exactly this kind of review. That is not evidence of bad faith by any one of them; it is what predictably happens when a rule’s enforcement depends entirely on the honesty of the party it regulates.
If you would rather the question not apply to your list at all, EMail Parrot strips tracking pixels and remote content before delivery, refuses to deliver a message it cannot fully clean, protects member addresses by default, and offers a 30-day free trial so you can see the difference before you commit to it.
Questions about migrating? Email us at info@emparrot.com.