How Gmail and Apple Mail Image Proxies Work (And How to Bypass Caching)

Building a reliable email tracker in 2026 requires understanding the complex proxy and caching infrastructure operated by Google (GoogleImageProxy) and Apple (Mail Privacy Protection / MPP).

When an email recipient opens a message in Gmail or Apple Mail, their client does not request the tracking image directly from your server. Instead, Google or Apple servers request the image on behalf of the user and cache the response.

If your tracking endpoint returns standard or missing caching headers, the proxy will cache the 1x1 GIF for days or weeks. As a result, subsequent opens and re-reads will never hit your server.

How GoogleImageProxy Works

When Gmail loads an HTML email with an <img src="https://yourserver.com/track/token.gif" />, the Gmail client transforms the URL into:

https://ci3.googleusercontent.com/proxy/abc123xyz...#https://yourserver.com/track/token.gif

The Google proxy server contacts your server, retrieves the image, and serves it to the browser.

The Anti-Cache Defense Blueprint

To force Google and Apple proxies to re-validate requests every single time the email is viewed, MailBlinker implements a multi-layer HTTP response header defense:

Cache-Control: no-cache, no-store, must-revalidate, max-age=0, private, proxy-revalidate
Pragma: no-cache
Expires: 0
ETag: "token-1786732984"

Key Header Mechanics:

• no-store, no-cache: Instructs the proxy never to store the response body in persistent edge memory.
• proxy-revalidate: Explicitly commands intermediate proxy caches (like Google's CDN nodes) to revalidate with the origin server on each request.
• Dynamic ETag: By generating a dynamic ETag containing the tracking token and UNIX timestamp, every request is treated as unique, forcing the proxy to fetch a fresh verification ping.

Handling Apple Mail Privacy Protection (MPP)

Since iOS 15, Apple Mail pre-fetches all email images in the background via Apple proxy servers whenever the device is connected to Wi-Fi, even before the recipient opens the email.

MailBlinker solves this false-positive challenge using Latency and User-Agent Heuristics:

• Sub-3-Second Filter: Requests received within milliseconds of sending from Apple proxy ranges are categorized as automated background pre-fetches.
• Device Divergence Clues: When a real human interaction occurs later (e.g. on macOS or an unproxied browser), MailBlinker triggers the verified open alert.