Email Tracking Has Outgrown the Pixel (2026)

The tracking pixel is the part everyone knows about: a one pixel image that loads from the sender's server when you open a message, reporting your open, your approximate location, your device, and the time. Image blocking and proxies like Gmail's image cache were built to blunt exactly that. But the pixel was only ever the cheapest tracking channel, not the only one. In 2026, treating "images blocked" as "tracking blocked" leaves several doors wide open.

Key Takeaways

• The tracking pixel is one channel among several; blocking remote images does not stop the rest.
• CSS can phone home through the background image property and @font-face, and Apple Mail Privacy Protection prefetches images but not stylesheets, so CSS tracking survives it.
• Click tracking through redirect links is completely unaffected by Gmail's image proxy or Apple's protection.
• AMP for email, reply detection, and engagement scoring let senders build a profile without a single pixel firing.
• The durable defense is blocking the outbound request itself in the browser, regardless of whether it comes from an image, a stylesheet, or a font.

How Does CSS Track You Without an Image?

CSS, the language that styles an email, is allowed to fetch external resources, and that is the loophole. Several CSS properties accept a remote URL, most notably the background image property and the @font-face rule that loads a custom font. When your mail client renders a message that sets a background image or a downloadable font pointing at the sender's server, it makes a request, and that request is a tracking beacon every bit as good as a pixel.

This matters because image blocking and CSS handling are separate switches. Apple Mail Privacy Protection, which is supposed to neutralize tracking by prefetching all images through Apple's proxy, prefetches images but not stylesheets. Security researchers documenting CSS evasion through 2025 and 2026 describe an even sneakier variant: custom property indirection, where the tracking URL is stashed in a CSS variable and referenced indirectly so naive filters that scan for obvious image URLs never see it. The result is a tracking channel that image based defenses simply do not cover.

Why Click Tracking Survives Every Image Block

Open tracking and click tracking are different mechanisms, and the protections that exist mostly address the first. A tracked link does not rely on loading anything when you open the message. Instead the visible link is rewritten to route through the sender's redirect server, which logs the click, your device, and your address before bouncing you to the real destination.

Gmail's image proxy and Apple Mail Privacy Protection do nothing about this. The moment you click, the redirect fires from your real connection. We unpack the difference in detail in open tracking versus click tracking, but the short version is that a sender who only cares about clicks barely notices that you blocked their pixel.

What About AMP, Reply Detection, and Engagement Scoring?

AMP for email lets senders ship interactive content, carousels, forms, live updating prices, that talk to their servers as you interact. Every interaction is a data point, gathered without a tracking pixel in sight. It is a smaller slice of mail today, but it is a tracking surface that did not exist a decade ago.

Then there are the inferential methods that need no remote loading at all. Reply detection simply notes whether you wrote back. Engagement scoring pools your behavior across many messages, when you tend to open, which subject lines pull a response, how fast you reply, into a profile that gets sharper over time. None of this trips an image filter, because none of it depends on you loading a resource. It is built from the metadata your normal use of email gives away. We looked at how much that metadata reveals in what your email metadata exposes.

What Actually Stops It?

If the problem is that tracking spreads across images, stylesheets, fonts, and links, then the defense has to operate one level lower than "should I show this image." It has to govern the outbound request itself, no matter which element triggered it. That is the design choice behind a browser level blocker.

Gblock works inside the browser where Gmail runs and intercepts requests headed for known tracking and beacon endpoints, whether the request originates from a pixel, a CSS background, a remote font, or a rewritten redirect. Because it matches the destination rather than the type of element, a stylesheet beacon is no more invisible to it than a pixel is. Its blocklist updates automatically as new tracking domains appear, which matters precisely because the techniques in this article keep multiplying.

No tool catches purely inferential signals like "did you reply," and no honest one should claim to, that is a function of how you use email, not a request that can be blocked. But the loaded resource channels, which are where the bulk of commercial tracking still lives, are exactly what request blocking shuts down. For a side by side of the approaches, see how to block email tracking in Gmail.

The Bottom Line

"Block images" was good advice in 2015. In 2026 it is the floor, not the ceiling. Tracking now hides in CSS that survives Apple's protection, in links that ignore every image block, and in AMP and behavioral profiling that never load a pixel at all. Defending your inbox means thinking in terms of requests, not images, and keeping a blocklist that moves as fast as the trackers do.