Safari 27 Blocks Email-Based Tracking IDs: What to Do

On October 19, Apple's WebKit team published a policy post called Blocking Identity Resolution Infrastructure. In plain terms, Safari 27 now blocks network access to third parties that collect email addresses at login or newsletter sign-up and turn them into persistent tracking IDs. If your ads, audiences or reporting lean on that kind of identifier, a slice of your traffic may have just gone dark.

What Safari Is Blocking

The block is applied at the domain level and covers iOS, iPadOS, macOS and visionOS 27. iOS 27 began rolling out on September 14, 2026. WebKit's post names no companies and publishes no domain list, though earlier reporting tied the change to identity vendors including The Trade Desk, ID5, Audigent, LiveRamp and Permutive. WebKit also says its Tracking Prevention Policy grants no exceptions to specific parties.

It draws a line you should note: first-party personalization is not the target. A central identity resolver is still treated as a third party even when its data comes from a single company.

What It Means for Marketers

Per the analysis in PPC Land's coverage, Safari 27 sessions produce no identifier from blocked resolvers, whether or not the user logs in. Audience segments keyed to those IDs may fail to match, which can make measured Safari reach look smaller than it is. Server-side routing is not an obvious workaround: based on WebKit's stated framework, it does not change how a resolver is classified, and the policy reserves the right to restrict circumvention.

Consent is a separate question. Compliance vendor iubenda's guidance, updated in September, says moving tracking to the server does not remove the consent requirement under EU rules, because the obligation attaches to reading from or writing to the visitor's device, not to where the data is later sent. US rules such as the CCPA work differently, but the practical point carries over: shifting tracking server-side does not change what is collected about the visitor.

What to Do This Week

• Check your Safari share. In your analytics, segment by browser and compare Safari conversions and audience match rates before and after September 14.
• Audit your vendors. Ask anyone running audiences or retargeting for you whether they depend on email-based IDs, and what their fallback is.
• Invest in first-party data. Collect emails and consent directly, with clear value in exchange, and use platform tools that send your own conversion data rather than relying on third-party IDs.
• Test your consent banner. If you recently added a cookie consent tool, confirm in a private window that rejecting cookies really stops the tags you expect to stop.

Frequently Asked Questions

Does this break Google Analytics or Meta ads on Safari?

Not directly. The block targets third-party identity resolution infrastructure. Standard tags are a separate matter, but audience matching that depends on those IDs can degrade.

Can server-side tracking get around it?

Per WebKit's stated framework, you should not count on it. Treat server-side tracking as a way to improve data quality, not to avoid blocking or consent.

Is there a version of this that helps small businesses?

Yes. Businesses with strong first-party data, such as a real email list, customer records and consented conversion tracking, are least exposed.

This sits alongside the shift we described in our post on AI Overviews and zero-click search: measurement is getting thinner, so your own data matters more. Our email marketing and paid media teams can help you build a first-party plan.

Sources: PPC Land on Safari 27, iubenda on server-side tracking and consent.