As detailed above, Gmail prefetching only occurs in a limited set of circumstances. Prefetching does not occur with other mail clients. Instead, this behavior is specific to when a Gmail user has the Gmail app open within their web browser or is actively using the mobile app. Our best guess is that it’s a security scan before showing the email to the user in their browser. This prefetching behavior also highlights why email file size optimization is important for faster loading and better user experience.

The full request headers for the image request are detailed below. A few things you will notice:

• The referer is set to http://mail.google.com. Interestingly, even though the user is on https://, Gmail still sets the referer to the http:// protocol when making the request. 

• The request comes from Gmail’s servers and not the user’s browser. The client IP always resolves to a Google-owned IP space.

• Unlike Google Image Cache, the user-agent string does not identify that the request is coming from one of Google’s bots. Instead, the user-agent string looks like an actual user image request. However, we have confirmed that this user-agent string does identify the Google prefetch bot.

• The open request happens within seconds of the email delivery. Further, the request occurs before the email appears in the user’s Gmail interface. This behavior leads us to believe the request is for security purposes.

• The prefetch seems to only happen once per unread Gmail email thread. In our extensive testing, once a message was read by the user, any future emails that went into that thread group did not initiate a prefetch request.

• This prefetch is separate from Google Image Cache. Our testing indicates that even after the image is prefetched, a separate Google Image Cache request is made when the user opens the email.

• If a user has the Gmail mobile app open, the prefetch will continue to happen for a short period of time, even after closing the mobile app.

Here is an example of what the request headers will look like when an image is requested from the Google Prefetch Bot:

  headers: {
    host: ‘{redacted}.m.pipedream.net’,
    ‘x-amzn-trace-id’: ‘Root={redacted}’,
    ‘accept-language’: ‘en-US’,
    referer: ‘http://mail.google.com/’,
    accept: ‘image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8’,
    from: ”,
    ‘user-agent’: ‘Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36 Edge/12.246 Mozilla/5.0’,
    ‘accept-encoding’: ‘gzip, deflate, br’
   },
   body: {},
   inferred_body_type: ‘FORM’,
   method: ‘GET’,
   url: ‘https://{redacted}.m.pipedream.net/header-1641a1.gif’,
   client_ip: ‘66.249.92.1’,
   query: {}

As is the case with Apple’s Mail Privacy Protection, senders should treat all open events with care. Focus on overall email quality, including preventing email address typos and maintaining clean lists for better deliverability metrics. Opens are just one, and often not the best one, of the many engagement metrics that senders should be monitoring and including when making determinations about user engagement.