Pixels Were Just the Beginning

By William Weiner April 8, 2026

Back in March we published a breakdown of how email tracking has evolved beyond the pixel – per-recipient identifiers planted in multiple places at once so that blocking any single vector leaves the others intact. We said we were treating tracking removal as a first-class feature, non-optional, like virus scanning. And we said we’d announce when it shipped.

It shipped.

This post covers what changed, what it means for your members, and why some of these protections matter more than the pixel ever did.


What Changed

CSS-Based Tracking Is Now Blocked

The tracking pixel is the most visible technique, but it was never the only one. Email marketing guides have long recommended embedding tracking tokens in external CSS URLs precisely because image-blocking tools don’t catch them. When your email client loads a stylesheet, the sender’s server gets a confirmation signal – identical in effect to a tracking pixel, but invisible to the tools designed to stop pixels.

The coverage is intentionally broad rather than a named list of known techniques. Any CSS declaration that loads an external URL is stripped, regardless of which property carries it – background-image, list-style-image, border-image, content, and others. That includes CSS custom property declarations (--variable-name) that store external URLs as an indirection layer, a technique designed specifically to slip tracking tokens past property-specific filters.

Beyond CSS, the same pass now strips HTML presentation attributes – background=, poster=, data=, and similar – that trigger the same automatic network fetch as a tracking pixel but are not CSS and were not previously caught.

The protection is automatic and invisible. Most emails render exactly the same. A sender who embedded their tracking token in a font URL, a stylesheet reference, or an HTML attribute gets nothing. Members using Thunderbird will also notice fewer “blocked remote content” client-side warnings, since the attributes that triggered those warnings are now removed before delivery.

Your Replies Are Private Too

This is the most significant change in this release, and it is specific to relay-layer operation – no email client plugin can do it.

When a sender issues an email, they typically embed a unique identifier in the message’s technical headers. If a member replies or forwards that email, those identifiers travel with the reply. A sender who instruments their receiving infrastructure can recognize their own identifiers arriving back and map who is in your list, who communicates with whom, and which members forwarded content to people outside the group – all without ever seeing a single member address.

This is propagation tracking. It is more valuable to trackers than open tracking, because it builds a network graph rather than just confirming delivery.

EMail Parrot now replaces all sender-issued message identifiers in outbound reply headers with one-way hashed values under our own namespace. The sender cannot reverse the hash to recover the original token. Member-side threading continues to work correctly because the hash is consistent – the same original ID always produces the same hash.

The protection is automatic. Replies and threads behave exactly as before. The sender just gets nothing useful back.

Many senders now skip click-tracking redirects entirely and embed per-recipient tokens directly in the destination URL as query parameters. The link goes straight to the real site – but it carries the member’s identifier on every click. This is not caught by redirect unwrapping because there is nothing to unwrap.

EMail Parrot now strips all query parameters from links when tracking protection is active. The link in the email body points to the clean destination URL.

Because some legitimate action links – unsubscribe, feedback forms, account confirmations – use tokens for authentication rather than tracking, the original URLs are preserved in a plain-text attachment named emparrot-original-links.txt whenever non-standard parameters were present. Standard marketing parameters (utm_source, utm_campaign, and similar) are stripped silently with no attachment, since the destination always works without them.

Nothing Gets Silently Dropped

Aggressive tracking removal has always carried a risk: breaking functional email. The most common failure mode is a confirmation email that uses an image button – the image is a tracking pixel, the button wraps a confirmation link. Remove the image, and the button disappears with it. The member never sees the confirmation link and cannot complete the action.

This release introduces a link recovery appendix. When EMail Parrot’s processing causes a link’s visible content to be removed, the link itself is preserved and surfaced in a clearly labeled section at the bottom of the email: “Links recovered during tracking protection.” The member can see what was recovered, read a brief explanation, and decide whether to click based on their trust in the sender.

Nothing is ever silently lost. Members always have full access to what was removed and why.

This also changes how we think about the two classes of tracking:

  • Render-time threats (pixels, CSS loads) fire the moment the email is opened, without any member action. These are removed silently and completely. The member has no opportunity to consent, so we take no-action as the correct default.
  • Click-triggered links only fire when the member actively chooses to click. The member has agency. Silent removal is wrong here. We inform and preserve; the member decides.

Cleaner Notifications

Previous releases generated member-facing notices for routine hygiene operations that fire on virtually every HTML email – CSS class normalization, data attribute stripping. Because these ran so frequently, members were effectively trained to ignore all EMail Parrot notices.

These routine operations are now handled silently. Member notices are now reserved for events that are specific and meaningful:

  • External tracking resources removed
  • Click-tracking redirects unwrapped from links
  • Suspicious or deceptive links flagged
  • Hidden instruction characters detected

When a notice appears, it reflects a real privacy action taken on that specific email – not routine housekeeping.


What This Looks Like in Practice

We ran the April 2026 Nextdoor email through the updated processor. That email carried ct, ec, token, and auto_token parameters on every link, including the unsubscribe and feedback links. After processing:

  • The links in the email body point to clean Nextdoor URLs, with no tracking parameters.
  • The emparrot-original-links.txt attachment contains the original URLs with all parameters, labeled by their link text, so the member can reach the unsubscribe or feedback function if needed.
  • No pixel fires on open.
  • The reply chain is hashed – Nextdoor’s infrastructure cannot correlate a member’s reply back to the original send.

The sender’s tracking infrastructure gets nothing from the open. The member interacts with clean URLs. The action links still work.


The Structural Point

Client-side tools – email plugins, browser extensions, image-blocking settings – can only act on what the client sees. They cannot touch the reply chain. They cannot strip parameters from links without breaking the destination. They cannot know what was removed when they process a message for a single recipient.

EMail Parrot operates at the relay layer, before delivery, with full visibility into the message and full control over what leaves. That is a structural advantage that does not depend on keeping up with individual sender tactics.

The tracking arms race is real. We are watching it and we will keep closing gaps as new techniques emerge. Tracking content works against our members’ interests regardless of who sent it or why. Our job is to deliver clean, private communications.


Running EMail Parrot? These protections are active now. No configuration changes are needed. Existing list settings (tracking protection on/off) continue to control which protections apply.

Not running EMail Parrot? Start your free trial.

Questions? Email us at info@emparrot.com

Related reading: