# Gmail image proxy and email tracking > Learn how Gmail’s image proxy, scanning, and caching affect open tracking, IP and device data, repeat opens, dynamic images, and reliable email metrics. - **Category:** Email analytics - **Published:** August 5, 2026 - **Reading time:** 17 min read - **Author:** Maya Chen, Email infrastructure - **Canonical page:** [https://emailbump.com/blog/gmail-image-proxy-email-tracking](https://emailbump.com/blog/gmail-image-proxy-email-tracking) Gmail’s image proxy stands between the recipient and many remote images in an email. Instead of the reader’s browser or app requesting an image directly from the sender’s server, Gmail can scan, retrieve, and serve the image through Google infrastructure. The sender may observe a Google-mediated request rather than the recipient’s IP address, location, browser, or device. That does not make every Gmail open invisible. Google’s current Gmail help page says senders may sometimes know whether an image-containing email was opened. The accurate interpretation is narrower: an image request may support an open-like event, but proxying and caching weaken IP, device, location, timing, and repeat-open claims. Other clients, scanners, and forwarding paths add more uncertainty. > **Gmail proxying is not Apple MPP** > > Apple says Protect Mail Activity downloads remote content in the background by default regardless of engagement. Gmail’s published user guidance instead focuses on scanning images and preventing image loading from revealing computer or location information or using browser cookies. Do not apply Apple’s behavior model, timing assumptions, or labels to every Gmail request. ## What is the Gmail image proxy? An HTML email normally references images by URL. Those can include a logo, product photograph, social icon, animated GIF, or invisible one-pixel image. When the client renders the message, it needs the image bytes. Gmail can obtain those bytes through its infrastructure and deliver the result to the reader without a direct reader-to-sender image connection. ### Direct and Gmail-proxied image paths ```text DIRECT IMAGE LOAD recipient device → sender image host origin may observe recipient IP, user agent, time, and unique URL GMAIL-PROXIED LOAD recipient uses Gmail → Google image infrastructure → sender image host ↘ scanned/cached image → recipient origin observes a Google-mediated request rather than a direct device request CACHED DELIVERY recipient views again → Gmail may serve an existing image representation sender origin may receive no equivalent second request Exact retrieval and cache behavior can change and vary by context. Your origin logs show requests received—not every time a person looked at an image. ``` Google says it scans images for suspicious content before the user receives them. Its help page says these protections stop senders from using image loading to learn about the reader’s computer or location and stop an image from setting or reading cookies in the browser. Gmail may withhold images and ask the reader whether to display them when a sender or message appears suspicious. ## What an email pixel can still reveal in Gmail ### Gmail pixel evidence ```text MORE DEFENSIBLE a particular remote-image URL was requested from sender infrastructure the request arrived at a recorded time the request came through infrastructure that appears Google-mediated a unique URL can still associate the request with a recipient or message NOT DEFENSIBLE FROM THAT REQUEST ALONE the recipient’s actual public IP address exact location physical device or browser that displayed the message number of times the person viewed the message duration, attention, comprehension, or intent whether an unusually fast request was definitely human or automated ``` Proxying protects network and device details, but a sender-generated unique image URL can still identify which message or recipient record the request belongs to. This is why Gmail can protect location while Google still warns that a sender may sometimes learn that an image-containing message was opened. Privacy protection is not the same as making every source URL anonymous. > **Name the event you actually observed** > > Use image request or observed remote-content load for the raw server event. If an ESP labels a Gmail proxy open, document how it classifies that request. Do not rename unclassified or non-proxy requests verified human opens; image blocking, other proxies, previews, forwarding, caching, and scanners still exist. ## Gmail proxying versus Apple Mail Privacy Protection ### Gmail and Apple comparison ```text GMAIL IMAGE HANDLING APPLE PROTECT MAIL ACTIVITY PUBLISHED EMPHASIS image safety and privacy Mail activity privacy ORIGINAL IP hidden from image sender hidden through separate relays COMPUTER / LOCATION not exposed by image load actual IP and exact location hidden BROWSER IMAGE COOKIES cannot be set or read not the central published mechanism BACKGROUND BY DEFAULT do not assume universally Apple explicitly says yes OPEN MAY BE INFERRED Google says sometimes Apple says sender cannot see if opened CACHE / PROXY EFFECT origin requests may differ privacy fetch breaks engagement timing This is a comparison of published behavior, not a permanent packet-level promise. Clients and services evolve; verify current documentation and your own data path. ``` Mailbox domain alone cannot classify the behavior. A @gmail.com account opened through Apple Mail may be affected by Apple’s protection. A company address hosted on Google Workspace and read in Gmail may use Gmail’s image handling. A forwarded message, mobile notification, delegated mailbox, or another client can create yet another path. ## How caching changes repeat opens When a proxy caches an image, a later display can be satisfied without another request reaching the sender’s origin. That makes total opens, repeat opens, last-open timestamps, and open-duration sequences especially fragile. A single request is not a complete display history, and several requests are not necessarily several human reads. ### Why request count is not view count ```text ORIGIN SEES 1 REQUEST could represent one display could later support multiple displays from cache could be a scan or preview without a human view ORIGIN SEES 3 REQUESTS could represent three displays could involve different cache contexts or clients could include forwarding, retries, scanning, or automated fetches ORIGIN SEES 0 REQUESTS could mean no view could mean a human read with remote images blocked could mean a plain-text client or an inaccessible image request_count ≠ human_view_count ``` Cache behavior is an implementation detail, not a stable analytics contract. Do not promise that Gmail always fetches exactly once, caches forever, keys solely by URL, or requests only after a human open. Google can change scanning and delivery behavior, and multiple Gmail surfaces can behave differently. Build metrics that remain useful when those details shift. ## Why some Gmail opens appear unusually fast A request seconds after send may come from a person, Gmail’s processing path, a security product, a preview generator, or another automated system. Timing alone cannot identify the actor. Recent search results contain conflicting claims about Gmail prefetch behavior, which is another reason not to publish a universal rule from vendor observations. ### Fast-open investigation ```text 1 preserve raw event time, message ID, URL, headers, and routing context 2 compare send, provider acceptance, receiver acceptance, and request timestamps 3 group by receiving domain, client classification, network, and campaign 4 check whether clicks or first-party outcomes also occurred 5 compare a controlled seed set across Gmail web, Gmail apps, and other clients 6 record provider classifier and pipeline changes 7 label likely automation, likely proxy, and unknown separately Do not infer “human” merely because a request misses a known-bot list. Unknown is a valid—and often more accurate—classification. ``` ## Metrics most affected by the Gmail image proxy ### LOCATION **City or precise location from the image-request IP** The origin sees proxy infrastructure rather than a reliable recipient location. ### DEVICE **Phone, browser, or operating system from image headers** The request describes the intermediary path, not necessarily the display device. ### REPEATS **How many times this person reopened the message** Cache hits may not reach the origin, while automated and multi-context requests can add events. ### LAST OPEN **The exact last time the recipient read an email** A later cached display may be invisible and a recorded request may not be human. ### DURATION **Reading time inferred from request sequences** Proxies and caches break the assumed relationship between resource timing and attention. ### AUTOMATION **Trigger a sales or lifecycle action on an open** The business action can run on an ambiguous infrastructure event. ## Do not use Gmail opens for consequential automation ### Open-trigger replacement map ```text FRAGILE RULE STRONGER SIGNAL alert sales on first open qualified reply or expected booking branch onboarding after open completed setup step or elapsed time resend to non-openers transparent reminder based on eligibility sunset after no opens relationship evidence + reconfirmation score every repeat open validated product or account action optimize send hour per last open experiment with downstream outcomes show city-specific offer from pixel IP explicit preference or valid account region A click can also be automated. Confirm consequential outcomes at a secure first-party destination instead of treating a redirect request as intent. ``` ## Dynamic images may become stale or context-poor A dynamic image changes according to request time, stock, location, account state, or another input. Gmail’s retrieval and caching layer can capture a representation that no longer matches a later view. IP-based localization can reflect Google infrastructure rather than the reader, while images that depend on browser cookies or a logged-in session will not receive that context through the proxy. - Put deadlines, price, eligibility, and material terms in accessible text, not only inside an image. - Treat countdowns as decorative and validate the real deadline at the destination. - Do not personalize sensitive or regulated content from the image-request IP. - Provide a useful static fallback for cached, blocked, expired, unsupported, or inaccessible content. - Use alt text and meaningful surrounding copy so the message works before images load. - Never rely on an image request to authorize an account action or disclose private data. ## Build images that work through a proxy ### Remote image delivery checklist ```text URL public HTTPS URL; no private network, localhost, or login dependency TLS valid certificate and complete chain RESPONSE 200 status with the correct image Content-Type REDIRECTS few, stable, HTTPS destinations; no loops or arbitrary redirects FORMAT broadly supported PNG, JPEG, GIF, or appropriate modern fallback SIZE compressed dimensions and bytes appropriate for email AUTH no browser cookie, Authorization header, or recipient session required CACHE assume intermediaries can cache; do not depend on origin request count FALLBACK descriptive alt text, dimensions, background, and surrounding copy PRIVACY no personal data or secret in filename, path, query, or metadata OBSERVABILITY log availability and errors without retaining excess recipient data ``` If a Gmail image fails, test the exact received message rather than only the template preview. Confirm the final source URL is public, the response succeeds without cookies, the TLS chain is valid, the MIME type matches the bytes, redirects terminate safely, and the host is not blocking Google infrastructure. Avoid solving delivery by broadly allowlisting unknown networks or weakening authentication on private assets. ## Do cache-busting parameters restore accurate tracking? A unique URL can let the sender associate a request with a recipient or message and may create separate cache objects. It does not restore the recipient’s real IP, device, location, repeat-view history, or human intent. Adding ever-changing parameters to force more origin requests increases data collection and infrastructure load without turning requests into verified reads. ### URL design choices ```text CONTENT IMAGE https://img.example.com/campaign/product-card.png shared, non-identifying, cache-friendly CAMPAIGN IMAGE https://img.example.com/c/august-launch/header.png shared campaign context; useful for versioning and operations UNIQUE TRACKING IMAGE https://img.example.com/o/.gif creates a person-level lookup even when the visible image is identical UNSAFE https://img.example.com/pixel.gif?email=person@example.com identity enters URLs, logs, proxy requests, screenshots, and diagnostics Do not put email addresses, customer IDs, stable hashes, order details, or secrets in image URLs. An opaque lookup token remains linkable inside the sender’s system. ``` ## Measure email without depending on Gmail opens ### Proxy-resistant evidence ladder ```text 1 APPLICATION SUBMISSION app handed the message to the provider 2 PROVIDER ACCEPTANCE provider accepted responsibility for the request 3 RECEIVER ACCEPTANCE destination server accepted the message 4 DELIVERY EXCEPTION deferral, bounce, block, or policy response 5 RECIPIENT FEEDBACK complaint, unsubscribe, preference, or reply 6 CAMPAIGN VISIT aggregate link traffic; scanner uncertainty remains 7 FIRST-PARTY OUTCOME activation, purchase, renewal, or completed task 8 INCREMENTAL OUTCOME treatment beats a randomized holdout REMOTE-IMAGE REQUEST optional supporting evidence with proxy qualification ``` No single metric replaces open rate because open rate was asked to answer unrelated questions. Use receiver responses for transport health, complaints and unsubscribes for negative feedback, replies for conversation, product or account outcomes for success, and holdouts for causal impact. Use aggregate campaign links when source attribution is necessary and individual identity is not. ## An honest Gmail-aware dashboard ### Dashboard definitions ```text OUTCOMES eligible, conversions, holdout lift, effect uncertainty DELIVERY submitted, provider accepted, receiver accepted, deferred, failed Gmail and Google Workspace responses by documented domain grouping FEEDBACK complaints, unsubscribes, replies, preference changes TRAFFIC — IF USED campaign visits, suspected security scanners, confirmed outcomes REMOTE CONTENT — OPTIONAL unique URLs requested, total origin requests, likely proxy classification no “verified human open” field derived from pixels DATA QUALITY image-host failures, cache ambiguity, webhook gaps, classifier version changes ``` Keep Gmail-specific operational slices, but do not use them as a proxy for a person’s mailbox provider or client with perfect certainty. Domains can forward, organizations can route through gateways, and users can read the same account in several apps. Document grouping logic and allow an unknown category. ## Privacy and compliance still apply Google’s proxy does not provide the sender with a legal basis, valid consent, an ePrivacy exception, or an anonymous dataset. A unique image URL can still let the sender single out a recipient and record behavior. Review the message permission and the tracking operation separately, then apply transparency, purpose limitation, minimization, security, vendor, retention, objection, and deletion requirements to the actual data path. - Inventory identifiers in every image URL and the internal table that resolves them. - Document what the CDN, WAF, image host, ESP, analytics vendor, and logs retain. - Disable person-level pixels where they are unnecessary or unsupported by the applicable rules. - Do not infer sensitive traits, precise location, or device identity from proxy requests. - Keep consent, objection, suppression, and retention controls synchronized across raw and derived events. - Explain proxy limitations anywhere stakeholders see an open-like metric. ## Separate remote-content loads from customer outcomes Email Bump keeps delivery activity, image observations, campaign context, replies, consent, suppressions, and first-party outcomes distinguishable. - Delivery and feedback evidence - Explicit measurement definitions - First-party outcome context [Learn more](https://emailbump.com/features/analytics) ## Frequently asked questions ## Does Gmail block email tracking pixels? Not universally. Gmail can retrieve images through Google infrastructure, which hides the recipient’s direct computer and location information and prevents the image from setting or reading browser cookies. Google still says a sender may sometimes know whether an image-containing email was opened, especially when the source URL is unique. ## Does Gmail prefetch images before an email is opened? Do not assume a universal prefetch rule from sender logs alone. Google documents scanning and proxy protections, while observed retrieval timing can vary by Gmail surface, security processing, message risk, cache state, and other infrastructure. Classify unusually fast requests as ambiguous unless a current, authoritative signal supports a narrower conclusion. ## Can Gmail senders see the recipient’s IP address? Google says senders cannot use image loading to obtain information about the reader’s computer or location. A sender’s image server generally sees Google-mediated infrastructure rather than a reliable recipient IP. Other actions, such as visiting a sender-controlled website, create a separate request path and privacy analysis. ## Does Gmail cache tracking pixels? Gmail can serve proxied and cached image content, which means later displays may not create equivalent requests at the sender’s origin. Exact cache behavior is not a dependable analytics contract. Unique URLs can remain linkable but do not make request count equal human view count. ## Why are Gmail open locations inaccurate? The image request can come through Google infrastructure, so its IP location describes an intermediary rather than the recipient. VPNs, corporate gateways, mobile networks, forwarding, and other proxies add similar errors. Do not use an image request for precise location targeting or sensitive inference. ## What should replace Gmail open tracking? Use delivery and receiver responses for transport health, complaints and unsubscribes for negative feedback, replies for conversation, shared campaign links for lower-data source attribution, validated first-party actions for success, and randomized holdouts for incremental impact. Match the metric to the decision instead of searching for one universal open substitute. ## Continue the privacy-aware measurement series - [Apple Mail Privacy Protection](https://emailbump.com/blog/apple-mail-privacy-protection) — Understand background image fetches, privacy relays, open-rate distortion, and stronger replacement metrics. - [Email tracking pixels](https://emailbump.com/blog/email-tracking-pixel) — Understand pixel mechanics, accuracy limits, proxies, caching, privacy, and safer implementation. - [Analytics without tracking pixels](https://emailbump.com/blog/email-analytics-without-tracking-pixels) — Measure delivery, replies, first-party outcomes, aggregate traffic, and incremental lift without individual opens. - [Email link tracking and privacy](https://emailbump.com/blog/email-link-tracking-privacy) — Compare campaign UTMs, unique redirects, action tokens, scanner traffic, and lower-data attribution. - [UK PECR email pixel rules](https://emailbump.com/blog/email-tracking-pixels-uk-pecr) — Separate message permission from storage-and-access consent, exceptions, B2B, and UK GDPR duties. - [CNIL email pixel rules](https://emailbump.com/blog/cnil-email-tracking-pixels) — Apply France’s purposes, consent, exemptions, transition, evidence, and withdrawal guidance. ## Sources - [Google Gmail Help: turn images on or off in Gmail and how Gmail makes images safe](https://support.google.com/mail/answer/145919?hl=en) - [Apple: Mail Privacy Protection and privacy](https://www.apple.com/legal/privacy/data/en/mail-privacy-protection/) - [Litmus: Gmail image caching and email analytics](https://www.litmus.com/blog/gmail-adds-image-caching-what-you-need-to-know)