Resources/Email Tracking
Email TrackingConsiderationadvanced

Inside the Gmail Image Proxy: How Google Inflates Your B2B Open Rate (And What To Do About It)

Google routes every image in Gmail through ggpht.com proxy servers. caching, refetching, sometimes pre-fetching before the recipient even opens the message. The mechanism, the inflation rate by audience profile, the User-Agent signatures, and the fix.

Nate Summers
Co-Founder, Outsolvi
Published May 31, 202612 min read
🔍
Quick Answer1,543 words · 12 min read

Google's Gmail image proxy routes every embedded image through ggpht.com servers. caching the image at delivery, refetching it on subsequent thread views, and (since approximately 2022) pre-fetching for security scanning before the recipient opens the message. The result is that a single Gmail recipient can generate 2 to 5 "opens" in an email tracker without the recipient performing 2 to 5 reads. On B2B lists where 30 to 40 percent of recipients use Gmail (Google Workspace), this adds roughly 4 to 12 percentage points of inflation on top of Apple Mail Privacy Protection's 25 to 35 percentage point baseline. The structural fix is to identify the Google Image Proxy User-Agent (containing 'GoogleImageProxy' or 'via ggpht.com') and the known proxy IP ranges, and classify those requests at request time as Tier 4 or 5 in a confidence-scoring framework rather than counting them as human reads.

Try Outsolvi Free$7/mo yearly · $12/mo monthly · 14-day free trial · no credit card
Topics:email trackingOutlook email trackingGmail email trackingAI email insightsfollow-up automationconsideration

Key takeaways

  • Google's Gmail image proxy was announced in December 2013 as a privacy and security feature. Behavior expanded materially in 2022-2024 to include more aggressive caching and security pre-fetching.
  • Every Gmail-rendered email image is fetched from Google's proxy IP space, not the recipient's device. The original tracking pixel never sees the recipient's true IP or device.
  • A single Gmail recipient can generate 2 to 5 'opens' for a tracker that does not deduplicate by sender + recipient + thread. refetches happen on subsequent thread views, search results, and proxy cache refreshes.
  • Gmail Image Proxy is identifiable by User-Agent (containing 'GoogleImageProxy' or 'via ggpht.com') and by IP range (66.249.x.x and 64.233.x.x blocks among others).
  • On B2B lists where 30 to 40 percent of recipients use Google Workspace, the cumulative inflation contribution is 4 to 12 percentage points. additive to Apple MPP's 25 to 35.
  • The fix is confidence-tier scoring at the HTTP request level. Tier 4 or 5 classification when User-Agent or IP matches Google Image Proxy, with the tier surfaced in the rep dashboard alongside non-proxy opens.

This article is the technical companion to [The State of B2B Email Tracking in 2026](/blog/state-of-email-tracking-2026) and [Email Tracking Confidence Scoring Framework](/blog/email-tracking-confidence-scoring-framework). The first documented what broke. The second documented the fix. This one documents the specific mechanism behind one of the four forces that did the breaking: Google's Gmail image proxy.

If you've ever looked at a Gmail recipient's open count in your tracker and seen the number climb without any reply or click pattern that justified it, this is why.

The 2013 announcement

Google Workspace announced the Gmail image proxy in December 2013[1]. The framing was privacy and security: instead of recipient browsers fetching email images directly from sender servers (which would leak the recipient's IP, browser identity, and read activity to the sender), Gmail would route every image fetch through Google's own CDN. The recipient sees the image. The sender sees only Google's proxy IP.

This was a clean trade for users. It removed a long-standing privacy leak. It also broke the sender-side tracking model that had been quietly working since the late 1990s.

The original 2013 behavior was straightforward[1]. When a Gmail user opened an email containing a tracking pixel:

  • Gmail's frontend triggered a proxy fetch of the pixel
  • The proxy server (in the ggpht.com infrastructure) fetched the pixel from the sender's server using Google's own IP
  • The proxy cached the result
  • The cached image was served to the recipient's browser

From the sender-side tracker's perspective, the pixel request arrived from a Google IP with a User-Agent identifying it as a Google image fetcher. The original tracker code at most email-tracking companies in 2013 was not prepared for this. it counted the proxy fetch as an open and recorded the Google IP as if it were the recipient's.

The structural problem was already visible to anyone paying attention. The 2014-2020 generation of trackers (Yesware, Mailtrack, Mixmax, Boomerang) handled it inconsistently. Some flagged the Google IP as a known proxy and excluded it from open counts. Some did not. Most reported raw counts including proxy fetches and let the rep mentally discount the inflation.

What changed in 2022-2024

The 2013 behavior was disruptive but bounded. A Gmail recipient who opened an email once generated one proxy fetch. The cache served the image on subsequent views without another fetch hitting the sender's pixel server. Trackers that detected the proxy could exclude its hits. The inflation contribution per recipient was 1.0 to 1.5. one proxy fetch per actual human view, occasionally a second on cache expiration.

Around 2022-2023, Google expanded the proxy behavior materially[5]. Three changes mattered:

Refetch on subsequent thread views. When the recipient reopens the thread (looking at the email a second or third time over a week), the proxy may refetch the pixel rather than serve the cache. This pushes the inflation contribution per Gmail recipient toward 2 to 4.

Refetch on viewer scroll and inline preview. Gmail's threaded view renders multiple emails in sequence. When the recipient scrolls through a long thread, individual emails come into the viewport and trigger proxy refetches. A long thread can generate 5 to 8 pixel fetches per included email.

Security pre-fetch. Google's image scanning infrastructure (similar to Microsoft Defender's pre-open behavior) fetches images on delivery for malware and phishing screening. This pre-fetch happens before the recipient opens the message and registers as a proxy fetch in the sender's tracker. The pre-fetch was not part of the 2013 design and was added quietly in the 2022-2024 expansion.

Combined, the per-recipient inflation contribution went from 1.0 to 1.5 (2013 era) to 2.5 to 5.0 (2024 era). On a B2B list where 30 to 40 percent of recipients use Gmail, the cumulative inflation rose from roughly 1 to 3 percentage points to 4 to 12 percentage points.

The cumulative B2B impact

Apple Mail Privacy Protection contributes 25 to 35 percentage points of B2B open-rate inflation (documented in the [State of B2B Email Tracking 2026](/blog/state-of-email-tracking-2026)). Gmail's image proxy adds another 4 to 12 percentage points on top. Corporate scanners (Microsoft Defender for Office 365, Proofpoint, Mimecast) add 8 to 16 percentage points. The sender's own self-opens add 2 to 4 percentage points.

Summed: 30 to 50 percentage points of inflation on a typical B2B list. A reported 70 percent open rate is usually a real 30 to 40 percent human-read rate.

The inflation contribution by industry mix:

Audience profileApple share[^3]Gmail share[^3]Total noise (typical)
Tech / SaaS60-70%35-45%40-50pp
Financial services45-55%20-30%35-45pp (scanner-heavy)
Healthcare45-55%25-35%35-45pp (scanner-heavy)
Enterprise mixed50-60%25-35%35-50pp
SMB mixed55-65%35-45%30-45pp

Note that Apple share and Gmail share overlap. many recipients have Apple Mail set up against a Google Workspace account, so the email routes through both Apple's pre-fetch AND Google's proxy. The inflation contributions compound rather than substitute.

Identifying Gmail Image Proxy at request level

Three signals combine to classify a request as Gmail proxy with high confidence.

Signal 1: User-Agent header

Google's Image Proxy fetcher sends a User-Agent containing one of:

  • The substring `GoogleImageProxy` (most common)
  • The substring `via ggpht.com` (older proxy nodes)
  • Pattern `Mozilla/4.0 (compatible; ggpht; +http://...)` (transitional UA from 2018-2021)

The User-Agent signal is deterministic. A request with any of these strings is Gmail proxy with effectively 100 percent confidence[4]. No human browser sends these UAs.

Signal 2: IP range

Google's image-proxy infrastructure runs from a known set of IP blocks[2]. The primary ranges:

  • 66.249.x.x (broadly, Google CDN. also serves Googlebot, so disambiguation by UA is necessary)
  • 64.233.x.x (Google general-purpose CDN)
  • 209.85.x.x (Google subsidiary CDN)
  • Additional adjacent /16 blocks that rotate periodically

The IP signal is necessary but not sufficient on its own. the same IP blocks serve Googlebot, Google Analytics, and other Google services. IP alone gives 60-70 percent confidence; combined with the UA signal, it's effectively 100 percent.

Signal 3: Request timing

A Gmail proxy fetch arrives within seconds of the recipient opening the message. The proxy refetches on subsequent thread views arrive in the same fast-second timeframe. A pure timing signal alone is weak (corporate scanners also fetch within seconds), but combined with UA and IP, timing helps disambiguate the proxy from human reads on Gmail clients that may also be on Google IPs (rare but possible).

How a confidence-scoring framework handles it

The [Email Tracking Confidence Scoring Framework](/blog/email-tracking-confidence-scoring-framework) describes the 5-tier classification system. Gmail proxy hits classify as Tier 4 or Tier 5 depending on the confidence of the disambiguation:

  • Tier 5 (known machine, 0-20% human confidence): Request UA contains `GoogleImageProxy` or `via ggpht.com`. Hard-classify, no further evaluation needed.
  • Tier 4 (likely proxy, 20-40% human confidence): Request IP is in known Google proxy range AND UA is generic/ambiguous AND timing is within first 90 seconds of delivery. Inferred classification with one signal of softness.

Tier 4 and Tier 5 are excluded from the rep dashboard's open count by default. They appear in the diagnostic view tagged as "Google proxy" so the team can monitor the inflation contribution per list and verify the framework is filtering as expected.

The non-proxy Gmail opens. actual human reads where the recipient's browser executes the JavaScript fingerprint callback and the request reveals device and screen data. classify as Tier 1 or Tier 2. These are the opens reps act on.

The edge cases that trip up naive implementations

A few specific scenarios break trackers that handle Gmail proxy with a single signal rather than the combined three.

The corporate VPN routing a Gmail recipient through Google's IP. Rare but possible. large enterprises that proxy outbound web traffic through Google's CDN. A pure-IP detection would classify the human read as Tier 4. Combined with UA disambiguation (the human browser doesn't send `GoogleImageProxy`), the framework correctly classifies the request as Tier 1.

The Gmail Workspace tenant with image rendering disabled. Some IT admins disable image rendering at the Workspace level for security policy. The recipient never sees the image and the proxy never fires. The tracker sees no open at all. neither human nor proxy. This is correct behavior, not a miss.

The recipient who reads the email in Gmail Mobile, then later in Gmail Web. Gmail Mobile and Gmail Web both route through the same proxy infrastructure, so both fetches generate proxy hits with identical UA. Deduplicating by recipient + send + first-fetch-within-1h cleanly counts this as one human read across the two views. Trackers that don't dedupe count it as two.

The proxy refetch six months later from a search hit. When a Gmail user searches their inbox and the search result includes the historical email with the tracking pixel, the proxy refetches. This is months after the original send. Naive trackers count it as a fresh open. Confidence-scoring frameworks classify based on timing. anything more than 30 days after send is excluded by default from human-read counts and surfaced as "archive re-render" in diagnostics.

What this means for reply rate as a primary metric

Reply rate has emerged as the cleanest single signal in 2026 because no proxy generates a reply[6]. The reply rate is unaffected by Apple MPP, Gmail proxy, corporate scanners, or self-opens. A reply is a human typing a response and clicking send.

For AE teams operating in environments where open-rate noise is heaviest (financial services, healthcare, enterprise), shifting the primary engagement metric from open rate to reply rate (with click rate as a secondary tier-clean signal) is the structural answer. Tracking still matters for per-prospect engagement signal (which prospects re-opened the proposal, which contacts on a deal are most engaged), but the aggregate rate metric should be the reply rate.

The takeaway

Google's Gmail image proxy is a privacy feature that does its job correctly. The structural impact on sender-side tracking. inflated open counts that don't reflect human reads. is a side effect of the proxy design, not a bug.

The right response is not to abandon image tracking. It's to grade every image fetch by signal quality at the HTTP request level and filter the proxy noise instead of counting it. The five-tier confidence framework handles this. Combined with the [State of B2B Email Tracking](/blog/state-of-email-tracking-2026)'s coverage of Apple MPP and the [Confidence Scoring Framework](/blog/email-tracking-confidence-scoring-framework)'s coverage of the full classification mechanism, this article completes the documentation of why and how the 30 to 50 percent open-rate inflation in 2026 is structural rather than tooling-specific.

Teams that adopt this framing measure cleaner pipeline. Teams that don't continue to be surprised that their dashboards show "high engagement" while their reply rates stay flat. The metric was never going to fix itself.

If you want to see your own list's inflation breakdown by source (Apple, Google, scanners, self-opens), [try Outsolvi free for 14 days](https://my.outsolvi.com/signup). The diagnostic view exposes the per-source breakdown by default during the trial.

Sources

Primary sources cited in this article. Numbers correspond to superscript markers in the body.

  1. [1]
    Google Workspace. "Images now showing." Gmail image-proxy infrastructure announcement, December 12, 2013. https://workspace.google.com/blog/product-announcements/images-now-showing
  2. [2]
    Google. "Gmail image-proxy IP ranges and security model." Google Workspace Admin Help. https://support.google.com/a/answer/6378010
  3. [3]
    Litmus. "Email Client Market Share. 2024." Gmail share of B2B opens. https://www.litmus.com/email-client-market-share
  4. [4]
    Mozilla MDN Web Docs. "User-Agent string composition and detection." https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent
  5. [5]
    Google Workspace Updates. "Gmail image rendering and proxy behavior changes." 2022-2024 release notes. https://workspaceupdates.googleblog.com/search/label/Gmail
  6. [6]
    Microsoft. "What's new in Microsoft Sales Copilot." Verified vs preview open distinction shipped in 2025. applies to Gmail-routed mail as well. https://learn.microsoft.com/en-us/microsoft-sales-copilot/whats-new

Frequently asked questions

Direct answers to the questions readers of this article most often ask.

How is Gmail's image proxy different from Apple Mail Privacy Protection?+

Both are mailbox-provider features that route image fetches through provider infrastructure. The difference: Apple MPP pre-fetches images on email delivery for every recipient with MPP enabled, regardless of whether the message is ever opened. Gmail's proxy primarily fires when the message IS viewed in Gmail, but caches the result and may refetch on subsequent views. Apple MPP creates 'phantom opens' (no human ever read), Gmail proxy creates 'inflated opens' (one human read counted multiple times). Both break naive open-rate tracking. Both are solvable with confidence scoring at request level.

What percentage of B2B email opens go through Google's proxy?+

Per Litmus 2024 client share data, Gmail accounts for roughly 30 to 40 percent of B2B email opens in 2026, with the exact share depending on industry mix. Tech and SaaS audiences skew higher (40-50 percent Gmail). Financial services and enterprise audiences skew lower (20-30 percent). Every one of those opens routes through Google's image proxy infrastructure unless the recipient's IT has disabled image rendering at the Workspace tenant level (rare).

What is ggpht.com and why does it appear in tracker logs?+

ggpht.com is the domain Google uses for its image-serving CDN. Image-proxy fetches typically include 'via ggpht.com' in either the User-Agent string or the originating-host metadata. Trackers that log full request headers will see ggpht.com references on Gmail-rendered email opens. Trackers that only log the IP and basic request data may miss the ggpht.com signal and miss-classify the request as a human read.

Does Gmail's proxy refetch images aggressively?+

Yes, more so since 2022. The original 2013 behavior was a simple cache-and-serve. fetch the image once on first view, cache it, serve the cache on subsequent views. The 2022-2024 expansion added refetch triggers on cache expiration, on viewer scroll, on thread reopen, and on security re-scan. Empirically, a Gmail recipient who opens a thread three times over a week can generate 5 to 8 pixel fetches in a tracker without anything having changed in the underlying email.

How do I detect Gmail's proxy in my own tracker logs?+

Three signals to combine. (1) User-Agent: requests with 'GoogleImageProxy' or 'via ggpht.com' in the UA string are Gmail proxy. (2) IP range: the 66.249.x.x and 64.233.x.x blocks (Google's primary CDN ranges) plus several adjacent blocks. (3) Request timing: Gmail proxy fetches arrive within seconds of the recipient opening the message, with refetches on later thread views. Combine all three for high-confidence classification.

Does this affect every tracker the same way?+

No. Trackers that classify at the HTTP request level (Outsolvi's Tier 1-5 framework, Microsoft Sales Copilot's verified-vs-preview distinction) handle Gmail proxy correctly out of the box. Trackers that only classify post-hoc (Yesware, HubSpot bot-detection layer) flag the proxy hits but still count them in raw open totals. Trackers that don't classify at all (Mailtrack, Vocus.io, most legacy trackers) report the inflated numbers without any flag.

What's the cumulative B2B open-rate inflation across Apple + Google + scanners?+

On a typical mixed-audience B2B list: Apple MPP 25-35 percentage points, Gmail proxy 4-12 percentage points, corporate scanners (Microsoft Defender / Proofpoint / Mimecast) 8-16 percentage points, self-opens 2-4 percentage points. Combined: 30 to 50 percentage points typical, occasionally up to 75 on Apple-heavy lists or scanner-heavy enterprise lists. A reported 70 percent open rate is usually a real 30-40 percent human-read rate.

Will Google's image proxy behavior keep changing?+

Yes. The 2022-2024 expansion to more aggressive caching and security pre-fetching suggests Google continues to evolve the system. The next expected change is per-organization configuration in Google Workspace Admin (some early signals in 2025 release notes). The structural answer for trackers is the same regardless: confidence-tier classification at request level adapts to behavior changes because it grades the request, not the count.

Nate SummersCo-Founder, Outsolvi

Writing about email tracking, follow-up timing, and AI signals for sales teams who hit send on real pipelines. Outsolvi is built natively for Outlook and Gmail, with AI follow-up insights from $7/mo billed yearly.

Share this article

Put what you just read into practice

See every open, click, and reply across Outlook and Gmail, with AI signals telling you when to follow up. $7/mo billed yearly, free for 14 days.

No credit card. Cancel anytime.