My inbox pinged at 7:42 AM. Another newsletter, pristine in Apple Mail, already ratting me out via CSS.
Tracking propagation attacks in email traffic? They’re everywhere, if you squint. I dug into production flows after that viral post on per-recipient IDs popping up in pixels, redirects, headers. Folks chimed in: CSS queries, data attrs, MIME tricks. So I chased ‘em down. What I found — in live emails — made my skin crawl.
Pixels? Old news. Blockers nuke ‘em. But CSS tracking? That’s the fresh hell image tools ignore. External stylesheets first, the lazy one:
Email client slurps it up. Server logs the ‘open.’ You see zilch. Apple Mail’s MPP pre-fetches images — not stylesheets. Boom, it survives.
But wait. @imports in style blocks:
@import url(‘https://tracker.esp.com/t/PERRECIPIENTTOKEN.css’);
Or any URL-swallowing property — list-style-image, border-image, cursor even. Not just backgrounds. Filters scanning background-image? Useless.
Then the ninja move: custom properties. Store the tracker URL in a var, reference later.
:root { –emp-track: url(‘https://tracker.esp.com/PERRECIPIENTTOKEN’); } p.hero::before { content: var(–emp-track); }
Looks innocent. No direct url() in a property value. Gotta chase the chain. I haven’t spotted this in emails yet — but 2025-2026 papers document it. Dead simple to deploy.
Why Do Email Trackers Love CSS So Much?
CSS fetches network requests silently. No visual cue. Email clients parse styles for layout, even if blocked. And variety — oh boy. Trackers mix it up, dodge regex filters.
Here’s the kicker. This ain’t CSS-only. HTML’s got presentation attributes, fossils from HTML4. They trigger fetches too, outside style blocks.
Found that in real traffic. Visually same as CSS background. But lives in markup — CSS scanners miss it. Loads poster image upfront, video or not. for good measure. These? Pure evasion. Filters tuned for stylesheets skip 'em. Propagation attacks crank it up. Not just opens or clicks — replies. Senders bake tokens into Message-IDs: . You reply? Client stuffs it into References and In-Reply-To headers. Sender parses inbound replies. Spots their campaign token. Links reply to original recipient. Knows who engaged. Worse for relays like mine. User gets tracked email via relay, replies. Outbound carries sender's Message-ID. Sender learns: reply came through relay, pins the user. Privacy service? Now a tracking booster. Fix? Hash those IDs outbound. Irreversible, consistent for threading, your namespace. References become . Sender's blind. ## Can Your Replies Really Betray You? Damn right. Most folks don't think replies leak. But headers chain forever — threading demands it. Senders instrument inbound mail servers, harvest tokens effortlessly. Real-world hit: Nextdoor emails (April 2026) with click wrappers everywhere. But propagation? Silent killer. And click redirects? Simpler now. No full redirect — just trackers in the URL path, like https://nextdoor.com/news_feed/?tk=PERRECIPIENTTOKEN. Destination sees it too. Double dip. Look, this echoes the 2000s web beacon wars. Back then, sites hid trackers in iframes, Flash. Browsers caught up — AdBlock lists, Do Not Track. Email? Lagging hard. Clients block images, sure. But CSS, HTML attrs, headers? Crickets. My unique take: ESPs won't fix this. Too profitable. Open rates, reply graphs fuel their pitches. "95% deliverability, precise engagement!" Privacy relays must rewrite aggressively — headers, URLs, everything. Or become accomplices. Bold prediction: By 2027, we'll see client-side header hashing. Apple Mail adds it. Gmail follows. Trackers pivot to WebPushes or AI summaries phoning home. But today? You're exposed. Test your inbox. Tools like my relay hash IDs now. Others? Patch up. Corporate spin calls it "analytics." Bull. It's surveillance. ESPS brag about "hygiene" while stuffing trackers. Skeptical? Run tcpdump on your email port. Watch the begs. Short fix list: - Block external stylesheets. - Strip presentation attrs. - Hash References/In-Reply-To. - Rewrite click URLs. Harder than expected. CSS vars chain deep. Attrs scatter. Headers nest. One-paragraph rant: Relays amplify if sloppy — user's reply carries sender token outbound, sender correlates across sends. Single user, multiple campaigns? Profile city. Don't run a relay without this. ## Email Relay Owners: Are You Amplifying Trackers? If not hashing headers, yes. Propagation turns your service into a spy bridge. Sender never touches your users — till replies flow back. Seen in traffic: Marketing blasts with table backgrounds. CSS imports. All logged before you blink. Dry humor break: Trackers evolve faster than Darwin's finches. Email clients? Still on stone tools. ** --- ### 🧬 Related Insights - **Read more:** [HCP Crushes Governance Bottlenecks with Multi-Owner Magic](https://theaicatchup.com/article/modernizing-governance-on-hcp-with-multi-owner-and-global-automation/) - **Read more:** [Ant Media's Secret to Scaling WebRTC: Separate Ingest, Conquer Latency](https://theaicatchup.com/article/were-at-nab-2026-and-heres-what-weve-been-building-for-live-streaming-at-scale/) Frequently Asked Questions** What are tracking propagation attacks in email? They chain identifiers across sends, opens, clicks, replies — letting senders link actions without direct contact. How do you stop CSS