Email tracking works by hiding a 1×1 pixel in the message. When the recipient's mail client loads that image, my server sees the request — so I know the email was opened. That's the whole trick, and it worked for a decade.
Then Apple Mail Privacy Protection changed the rules. On Apple Mail, the pixel gets fetched by Apple's servers, ahead of time, whether or not a human ever looks at the email. From my server's side, a pre-load and a real open look almost identical: both are just an HTTP request for the pixel.
So here's the uncomfortable truth every tracker has to face: a huge chunk of "opens" are now machines. And most tools just... keep counting them as human reads. The green checkmark stayed; the meaning left.
I decided EmailKnow would rather admit uncertainty than manufacture confidence. Two things make that possible:
1/ I fingerprint the request without storing anything creepy. Apple's pre-load fetches come from Apple's IP ranges. I keep a cached list of those ranges (with a built-in fallback), and when a pixel hit comes from one, I label it ⚠️ Apple/proxy pre-load — not a human read.
2/ I stopped trusting the pixel alone. A link click is a far stronger signal than an image load: pre-loaders fetch images, they don't click through. So a 🔥 click outranks everything.
The result is four honest states instead of one lie:
🔥 clicked · ✓✓ human open · ⚠️ Apple/proxy pre-load · ⧗ unknown
And a detail I'm weirdly proud of: EmailKnow also detects when the SENDER opens their own email (checking against a salted hash of the send-time IP) and marks it "self" — excluded from your real-open count. Your own inbox refresh shouldn't inflate your stats.
None of this makes tracking perfect. Nothing can — that's the honest headline. What it does is stop the tool from confidently telling you a robot read your pitch.
If you do outreach: how much of your "open rate" do you think is actually Apple pre-loading? My guess is it's higher than anyone wants to admit.
— building EmailKnow in public, #2
Top comments (0)