Apple confirms Safari 27 blocks identity resolution vendors

If your email-based IDs, audience sizes or match rates dropped on Safari traffic this autumn, the cause may not be your campaigns. Apple said yesterday that Safari 27 blocks the third parties that turn an email typed into a form into a tracking ID.

What Apple said

A WebKit blog post on 19 October 2026, “Blocking Identity Resolution Infrastructure”, says that in the iOS, iPadOS, macOS and visionOS 27 releases, Safari and WebKit “block network access to identity resolution infrastructure”. The target is a specific pattern: a script on a login or newsletter form sends the email address to a third party, the third party creates an ID linked to that email, and sends the ID back to the page for later use. Apple calls this the “post-cookie” method of identity resolution.

Two details matter more than the headline:

1. The block is by domain. The request is not filtered by its shape. A vendor cannot rename a parameter or restructure a call to get through. If its domain is on the list, the browser does not connect to it.
2. Apple names no domain. The post lists no companies. The Safari 27 and 27.2 beta release notes, which we searched today, contain no entry about the block.

The list nobody published

The only public list comes from the other side. In WebKit bug 324771, filed on 21 September, an engineer at The Trade Desk listed nine domains that Safari 27 shipped in its block list: uidapi.com, adsrvr.org, id5-sync.com, eu-1-id5-sync.com, rlcdn.com, pippio.com, permutive.com, ad.gt and a test entry, tainted.example. The reporter argued that adsrvr.org is The Trade Desk’s ad delivery domain, not identity. Apple asked the reporter to test the 27.2 beta, and on 9 October wrote “Confirmed resolved”.

So the list has already changed once, in a beta, with no release note. It can change again the same way. The mechanism behind it, “Unconditionally block requests going to certain domains” (bug 307853), was committed in February.

The read: three things this changes

Email-based IDs go missing on Safari, and the report does not say why. A blocked request fails in the browser. The vendor’s server never sees it, so its dashboard shows fewer IDs, not errors. Any metric built on those IDs — addressable audience, ID match rate, frequency, cross-device reach — falls on Safari 27 traffic while the number of people who visited stays the same. Split those numbers by browser before you read a trend in them.

The block stops at the browser. Safari can only refuse requests that Safari makes. An email your own server hashes and uploads to an ad platform never passes through it. But Apple’s post goes further than the block. It says a central resolver is a tracking capability “that each first party does not have on their own”, even when the graph holds one company’s data. Moving the same call to your server gets past the block. It does not get past the objection Apple wrote down.

Hide My Email changes the key itself. The post points iCloud+ users to Hide My Email, which gives every site a different random address. For those users, an email is no longer the same value across sites, so it cannot join records across them, in the browser or on a server. That lowers the match rate of any email-based upload, wherever the hashing happens.

What to do

1. Load your signup, login and checkout pages in Safari 27 with Web Inspector open, and filter the network log for failed requests to third-party domains. That is the only reliable list for your site.
2. Ask each identity or audience vendor whether its domain is blocked in Safari 27 and what its Safari ID rate has done since the release.
3. Read email-based match rates by browser. A step down on Safari is the browser, not the audience.

What survives on Safari is the email you collect and send yourself. The next question is whether each ad platform reads that email the way you sent it — and they do not all normalise and hash it the same way.