What are the technical details of what is happening here?

When a user receives an email at their mailbox provider, one of the Apple Mail apps pre-fetches the message without the user interacting with the message. This pre-fetching often does not happen immediately and occurs primarily when the user’s phone is plugged in and on wifi. Once the message is pre-fetched, the mail client then preloads and caches all of the images using Apple’s proxy service. This preloading of the images causes image pixels to fire, resulting in a false open.

What’s the difference between something opened behind a proxy and pre-fetched?

Descriptions for the different types of opens in this new world:

“Regular” Opens: These are emails that are opened by your intended recipient, and the open accurately conveys both that they opened the mail, as well as the device they used to view the mail and the IP that they accessed it from.

Proxied Opens: These are emails where the image open happens through a privacy proxy. The open was still initiated by your recipient, but the device and the IP/location information associated with the open are hidden from you.

Pre-fetched Opens: These are a new and special kind of open where the user's device opens the email and fetches (and caches) the image without them taking any action. For pre-fetched opens, it is impossible to tell if the actual recipient truly looked at your mail or if their device just pulled it and they never looked at it.

With all of these classifications, it is important to know that some small portion of emails (independent of the above types) are opened by and inspected by security services and may trigger “false opens.” These aren’t common, but when we say an open can be “trusted,” we really mean it can be relied on with high confidence.

Does a user have to actively use Mail.app for email to be impacted by MPP?

Let’s consider a common scenario: a user sets up their email account in Apple Mail.app, Gmail’s mobile app, and also routinely makes use of the Gmail web app. Even if the user rarely (or never) opens their email in Apple Mail.app, Mail Privacy Protection will still pre-load images because the email account was set up in Apple’s Mail.app. In this case, a sender will see opens from Apple’s image proxy and Gmail’s image proxy.

Is Apple pre-fetching all images now?

This is only seen when the user is on wifi and their device is plugged in.

How quickly is the pre-fetching happening?

According to our friends at Movable Ink, 85% of Apple Mail users who have clicked on a link saw the content rendered less than a minute prior to open.

Overall, given the manner in which MPP pre-fetches images, we are seeing open events happening anywhere between minutes to hours later. However, given the limitation that MPP only pre-fetches when on wifi and plugged in, the real-life impact to open-time optimization has been more limited than initially feared. It will be important to continue monitoring this as it could change at any time in the future.

Will MPP affect web tracking pixels that track web behavior?

Unless the user has blocked tracking via their browser, web tracking will work as it normally does. MPP will not affect web tracking.

How do we parse out the recipients that have MPP enabled? What should I be looking for?

Currently, the user-agent string that Apple’s proxy servers are sending when requesting images is Mozilla/5.0. As for how Bird will handle this specifically, on the sending side, we will be adding a field to both Webhooks and the Events API to indicate when an open has been pre-fetched.

These opens will still be included since they can be a valuable signal that an email address is valid. (Specifically, they indicate that the email address is linked to a powered-on Apple device, so it’s almost certainly associated with a “real” human being.) Nevertheless, the new flag will make it easy to see that these opens are different from actual engagement events and should be treated differently. This capability will be coming in a few weeks. We will also incorporate this distinction into our Analytics Report UI and Metrics API in Q4.

What user-agent string tells me that MPP is enabled?

Per Google, a browser’s user-agent string helps identify which browser is being used, what version, and on which operating system. Currently, the user-agent string that Apple’s proxy servers are sending when requesting images is Mozilla/5.0. While there is no direct indication that this belongs to Apple’s image proxies, our testing indicates that the string does accurately identify requests coming from Apple’s image proxies. This, in turn, may allow senders to filter out Apple proxy opens from their metrics or segment them differently. It is unknown whether Apple will change this in the future. As such, it will be important for senders to monitor for changes to this string and to adjust accordingly.

Is Apple cloaking IP addresses?

Click tracking IPs will only be obscured if people opt in to Apple Private Relay (a separate product and part of iCloud+, also only being released in beta – that was a walkback by Apple).

Unique clicks will still be accurate either way as Bird tracks clicks uniquely per email sent (each link in each mail to each recipient is uniquely identified).

Does MPP still work if the message lands in the spam folder?

So far, we have not seen MPP pre-fetching images for emails delivered to the spam folder.

Will Apple Mail proxy respect the image caching headers?

No, MPP does not respect image cache headers. Images are cached for a period of 2-3 days. If no image cache header is applied, images seem to be cached indefinitely.

Will Apple report multiple opens if they pre-fetch the email and then the user actually opens?

No. The image will be cached for a certain amount of time and additional opens inside that window will not be reported.

Is Apple applying the Mail Privacy Protection to just the classic 1x1 pixel, or are they blocking all image loading (à la Outlook circa 2005)? And given that a lot of other content will be images, is there a way around this by adding tracking data to the other content in the email?

Apple is not blocking pixels but instead has their devices aggressively pre-fetch and cache all images in emails. So you will get an open regardless of whether the user actually opened the mail.

Is it safe to assume that bounced email addresses will continue to report bounces and will not report back opens?

Yes.

We are concerned about the impact on our spam trap controls (e.g. spam traps reporting engagement). Is there a perspective you can share about the potential for pristine spam traps to report opens given the answer to the question above (i.e. would the spamtrap operator need to sync their monitored mailbox in the iOS app for an open to come through)?

Yes, a trap operator would need to have an Apple Mail client attached to the inbox in question, which seems highly unlikely. A major trap operator told us that Apple is not involved in their monitoring process. The bigger risk in the industry is people abandoning non-engaging as a way of filtering their lists.

I’ve heard rumblings about Apple only pre-fetching when the phone is on wifi and plugged in. Are you seeing this too?

We've seen confirmation for our early theories that preloading only happens when the user is on wifi and their phone is plugged into power. As of now, there is no indication that Apple is planning on changing this behavior.

Is there a technical hack or workaround to overcome the impacts of MPP?

History has shown us that any technical workarounds to bypassing privacy-related functionality are often short-lived, harm your reputation, and are quickly closed. Even though early testing indicates there are some workarounds to Apple’s preloading of images, we believe senders should not rely upon or use these workarounds.

The following Mail Privacy Protection limitations have been observed in early beta testing: into Mail Privacy Protection have explicitly said they do not want providers tracking them via email opens. Using these sort of workarounds betrays that user trust, is bad practice, and ultimately harms your brand’s reputation.

• Pre-fetching primarily happens when the user is on wifi and when plugged in. Early testing indicates that preloading only happens when the user is on wifi and their phone is plugged into power. This behavior is a little unexpected and will be interesting to observe as Apple moves to General Availability for iOS15. In practice, what this means is that the open events are even more random than initially thought. It seems open events can occur when the user actually opens the message, or when the user hasn’t opened the message but is on wifi and the phone is charging – or some other combination of events that Apple decides. All of this points to the same conclusion: open tracking on Apple devices can’t be trusted.

• User-initiated open events are triggered when the image is loaded via external CSS.

• Testing also indicates that user-initiated open events are triggered when the image is loaded via an external CSS file. While on the surface this might seem like good news,we strongly recommend against using this approach. It’s extremely likely that Apple, like HEY already did, will close this loophole. But there is a more fundamental reason not to use this approach: users who have opted