A Technical Take on iOS15 Mail Privacy Protection
By now the topic of Apple’s Mail Privacy Protection change for the upcoming iOS 15 is on everyone’s lips.
A Brief Overview
On June 7, during Apple’s WWDC21 conference, it announced Mail Privacy Protection for their Mail app on iOS 15, iPadOS 15, and macOS Monterey devices, set to launch between September and November of this year. According to Apple’s press release, “Mail Privacy Protection stops senders from using invisible pixels to collect information about the user. The new feature helps users prevent senders from knowing when they open an email and masks their IP address so it can’t be linked to other online activity or used to determine their location.”
This is not a default setting but something that a user will see when they first open an Apple Mail app, in which they’ll get a message prompting them to either “Protect Mail activity” or “Don’t protect Mail activity.”
The following are some of the technical details I’ve discovered while testing the Apple Mail app on iOS15 beta.
Observations
I downloaded the iOS15 beta onto my device and set up my own pixel. By the way, you can learn how to set up your own pixel here, so you can run your own experiments that way.
Also, take the following observations with a grain of salt as this is only the beta and Apple can always tweak their setup at any time.
- Images load as if the email is opened:
What I’ve found is that if you have desktop and mobile background images that are loaded using media queries, only the mobile background images are loaded. This is consistent with how the client would behave if an email is opened by a user. Unfortunately, this makes it harder to tell if an email is actually read or not by tinkering with media queries.Update: Apparently you can detect a real user open as of iOS Beta 5 by using an external CSS pixel.
- Interactive pixels can still gauge engagement:
One very interesting note is that interactive or kinetic background images loaded through :hover or :checked are not pre-fetched by the client. This means if you have pixels that detect interactive actions, they would detect real user actions. Once triggered, though these pixels are cached so you wouldn’t be able to detect subsequent actions. Now would Apple put the kibosh on this, too? Who knows! - It takes several minutes to several hours for images to begin downloading:
From my tests, once the emails are loaded into the email client on iOS15 beta, it takes the client anywhere from several minutes usually around 20 minutes to more than 8 hours to begin downloading images in the background.Update: Matthew Dunn mentioned in the comments that he noticed that the Mail client downloads images almost immediately for emails in accounts configured with push (ie. Exchange/iCloud) which happens when the messages arrive vs fetch (Gmail/IMAP) which happens when the client periodically checks for email (I ran my tests with the Mail client connected to Gmail/IMAP/POP accounts).
- Images in the Junk (spam) folder are not downloaded:
When an email lands in the Apple Mail’s Junk folder I did not notice the email client downloading images within these emails in the background. - Power and WiFi matters:
For the current version of the beta, it appears that the device tends to hold off on downloading images in the background if the device is not connected to a power source or not on Wifi. I’ve seen cases where images are not downloaded for 5 hours, and the moment I plug in the power cable and turn on Wifi, the images start downloading. .Most times, when the device is on WiFi and connected to a power source, the images of unread emails begin downloading in the background within the first 30 minutes after an email is downloaded.
- The client needs to be running:
If the Mail app is killed (not just put into the background), I’ve found that the client does not load images in the background. - Proxied IP and “Mozilla/5.0” User Agent:
As many have found out, the user agent for the request is masked to “Mozilla/5.0” and the requests come from a proxied IP address. Brian Sisolak also noticed that some of the IPs originate from Microsoft’s Azure as well as Cloudflare. According to Apple’s notes, these IP may be associated with a user’s general region as well. - Images are cached for 2-3 days:
Once the images are downloaded in an email, they are cached, and opening the email does not entail a load from the server. Also, it appears based on Brian’s observation that the caching does not respect the “Cache-Control” headers that specify when a cached image should expire – unlike Gmail, which honors the expiry.What this means is if you’re seeing multiple “opens” over several days from the same recipient from Apple Mail, its likely the subsequent ones were real opens – though it could be due to other factors as well such as the recipient connecting their other Apple devices (Mac/iPad) to the same email account and not downloading emails until later.
- Images are cached across emails:
If you have the same image across multiple emails (and emails across accounts on the same email client), the image is only fetched once. This may not be relevant to tracking pixels since they are unique per email, but it is something I’ve noticed.
Learnings
The first thing to note is that analytics providers and ESPs must now start segregating Apple Mail and non-Apple mail “opens” for the stats to make any sense. However, once you can segregate these stats, the Apple Mail stats can still be valuable.
Based on what I’ve found, here are some of my takeaways:
- One of the upshots is since the emails must be loaded into a Mail client for the images to be downloaded, you now can tell that these email addresses are live and not going to an inbox that has been abandoned.
- One of the worries of marketers is if the Mail client downloaded all images immediately after retrieving an email, that may result in a flood of image requests on their server potentially overwhelming their servers. Seeing that there is not only a delay in downloading images, but often a long delay when the device is not connected to a power source, this tsunami of requests may not materialize.
- You can still gain some signals of engagement (for now) by using interactive pixel tracking.
So what does this mean for you?
I think there are many pundits already giving their opinion and I’m not much of a marketer’s marketer, but here are some.
- Opens are still not dead.
At least not yet, since you still have about 50% of opens on Gmail and other providers. So you’re still getting a strong signal about opens, though you, your email service provider, or analytics provider need to segregate out the Apple pixel requests. Features like A/B testing based on opens can live to fight another day. - “Real-time content” will require fallbacks
Although Apple’s changes mean that real-time content (i.e. countdown timers) is no longer real-time in Apple Mail – there’s always Gmail. Just make sure you have an appropriate fallback content when the content is loaded in an Apple Mail client. - “Read time” (glanced vs skim vs read) analytics IS dead.
Analytics that tell how long a recipient spent reading your emails has never worked in Gmail due to proxying and they’ve ALWAYS been super inaccurate anyway, but with Apple now in the camp, the days of faux read-time analytics will be going away. - IP-based geo-located imagery IS dead.
Location-based imagery based on IP (i.e. weather) will no longer work on the majority of email clients – since it has never worked in Gmail, Yahoo, or Outlook.com. However, you can still target content based on “first-party” data (ie the address you have for your clients in your own database) - Time to reconsider open-based journey triggers.
Sending reminders in your marketing automation based on whether a recipient has opened your email? Well, they may no longer be accurate.
Other Resources
If you’re looking for more technical discussion about Apple’s upcoming changes, check out this webinar featuring PeakInbox‘s Brian Sisolak, Campaign Genius‘ Matthew Dunn, and Only Influencers‘ Jeanne Jennings.
Awesome detail here, Justin. One quick question. You mentioned that images are cached for 2-3 days in one of your list subheaders. Does that mean after that opens that occur 2-3 days after an email is sent would sort of look like a real open (ie, still downloaded through proxy but downloaded long enough after the original send to look less like the original download)?
Hey Gregg, yes if there are more than one downloads and its spread days apart it is likely a real open but also could be due to other causes as well such as the user having multiple Apple devices connected to the same account (updated the article – thanks!)
Gotcha. Makes sense. Thanks for the clarification, Justin!
Really useful findings, Justin, thanks for publishing.
On the current beta, we see different ‘fetch’ behavior from email accounts configured for Push (e.g. iCloud, Exchange) vs Fetch (e.g. Gmail, IMAP). Images/pixels aren’t loaded into the proxy until message open on fetched accounts; they’re loaded almost immediately on Push accounts. Have you seen this difference?
Matthew, that is a very good finding! I don’t have access to Push accounts but I’ve added your observation to the article. Thank you.
thanks Justin, very helpful.
Thank goodness for the interactive pixels!!
Dear Justin,
Tremendous work, thank you for writing this post.
So based on your findings, could it be that it is impossible to determine a “fake” open to a “human” open?
Since it seems like there are many factors influencing when an image gets downloaded by the client, it could be possible that a human has opened an email before the images got downloaded, right?
Again, thank you for your contribution on the matter.
Yes it is possible that an open was triggered by a user opening the email. Just unfortunately you can’t tell which are the real ones using the regular open pixel.
Though read the update, there’s a way to detect using external CSS pixels.