Apple confirms Safari 27 blocks email-based identity trackers

Apple has publicly explained why Safari 27 refuses to connect to a group of advertising identity domains. In a WebKit blog post published on October 19, 2026, the company said Safari and WebKit now block network access to third parties that collect email addresses at login or newsletter sign-up and convert them into persistent tracking IDs. The block covers iOS, iPadOS, macOS and visionOS 27.

What does Safari 27’s identity resolution block cover?

The block targets what Apple calls identity resolution infrastructure: invisible third parties on pages where people enter an email address, which are neither login providers nor newsletter services. As reported by PPC Land, the post by John Wilander, Charlie Wolfe and Matthew Finkel says the block works at the network layer and on whole domains, so no ID is ever created and changing the request format does not get around it.

• Apple names no companies and publishes no list. Earlier reporting tied the affected domains to identity services such as Unified ID 2.0, ID5, LiveRamp, Permutive and Audigent, based on a WebKit bug report filed by The Trade Desk’s Ian Meyers on September 21, 2026.
• The Trade Desk’s ad delivery domain, adsrvr.org, appeared to be restored in an iOS 27.2 beta; Apple has not explained why it was listed.
• WebKit draws a clear line: “First party personalization is not tracking, and is not what our technologies seek to prevent.”
• A report by AdExchanger of a remotely updated list covering hundreds of companies remains unconfirmed by Apple, according to PPC Land’s daily roundup.

Does the Safari 27 block affect ad targeting and measurement?

Yes. Any identifier minted by a blocked resolver through a client-side script simply does not exist for Safari 27 users, whether or not they log in. Bid requests go out without it, audience segments keyed to it stop matching, and advertisers buying those segments should expect lower Safari reach. Since Safari blocked third-party cookies in 2020, email-based IDs have been the industry’s main way to recognise the same person across sites on Apple devices, so this removes the most important workaround rather than a niche one.

Two details matter for planning. First, the post does not distinguish between raw and hashed emails, so hashing is not a defence in Apple’s framing. Second, WebKit says a central resolver remains a third party even when it only handles one company’s data. Moving the same calls server-side avoids a browser domain block technically, but WebKit’s policy reserves the right to add restrictions without notice against parties that circumvent its protections. Treat server-side identity as a moving target, not a safe harbour.

For SEO and content teams, the practical exposure sits in newsletter sign-ups, gated content and login forms: these are exactly the touchpoints where identity scripts tend to run.

How to audit your site for Safari 27 identity tracking

• Inventory scripts on email forms. List every third-party tag that fires on login, registration and newsletter pages, and flag identity vendors.
• Segment reporting by browser. Compare Safari 27 reach, match rates and conversions with Chrome to size the impact before budget conversations.
• Ask your vendors directly. Request their Safari 27 status, which domains they use and what fallback they offer.
• Strengthen first-party signals. Visible, user-initiated logins and your own CRM data remain inside Apple’s stated line.
• Monitor iOS 27.2 and future WebKit posts. Apple has not said how domains are chosen or updated, so the list can change.

Sources

• PPC Land: Safari 27 blocks identity firms that turn email addresses into tracking IDs
• PPC Land: Safari 27 blocks identity firms as search falls to 12% of publisher traffic