What Safari 27's identity-resolution block means for DTC paid media

On the 19th October, Apple's WebKit team explained why Safari and WebKit in the iOS, iPadOS, macOS and visionOS 27 releases block network access to identity-resolution infrastructure. The block itself had been live since iOS 27 shipped on the 14th September. After third-party cookies, it's the next layer of cross-site tracking Safari has targeted.

That matters because identity resolution was the industry's answer to cookie loss. When cookies stopped following people across sites, the email address took over as the durable ID. Safari is now going after that too.

Here's what's changed, who it affects and what it could mean for the signal data your paid media depends on.

What is identity resolution?

Identity resolution turns an email address into a tracking ID that follows someone across websites and devices. It usually runs invisibly, through a third-party script on the forms where people hand over their email.

The flow looks like this:

1. A shopper logs in, creates an account or signs up to a newsletter.

2. A third-party script on that page picks up the email address and sends it to the vendor's servers.

3. The vendor creates a persistent ID linked to that email and sends it back to the site.

4. Any other site using the same vendor can match the same email to the same ID.

Over time, the vendor builds an identity graph: a profile that connects the same person across sites, sessions and devices. Logging out or unsubscribing doesn't break the link.

Email is a powerful key because people keep the same address for years, using it everywhere and on every device. After cookies, it became the closest thing the industry had to a universal ID.

What is Safari blocking?

Safari and WebKit now block network requests to identity-resolution vendors, so the email address never reaches their servers. The key details:

• It blocks at the domain level. Vendors can't get around it by changing the shape of their requests. If the domain is on the list, the request doesn't go out.

• It's aimed at third-party infrastructure. Apple describes the targets as companies that sit on login and signup pages without being the login provider or the newsletter service. Their only role on the page is tracking.

• First-party personalisation is not the target. Apple says explicitly that a brand using its own customer data for its own site experience isn't what it's trying to stop.

• There's no public vendor list. Apple hasn't said which companies are blocked, so treat any list you see as speculation until it's confirmed.

The closest thing to a confirmed list so far comes from a bug report The Trade Desk filed with WebKit. It shows Safari on iOS 27 blocking domains used by Unified ID 2.0, ID5, LiveRamp, Permutive and Audigent, plus adsrvr.org, the domain The Trade Desk uses to bid on and serve ads. In late September, that left the DSP unable to serve ads to Safari users on the new release. Apple took adsrvr.org off the list in the iOS 27.2 beta, and 27.2 shipped on 26 October, though its release notes don't mention the change. The identity vendors stay blocked. If you buy programmatic through The Trade Desk, check that Safari delivery recovers as people update.

The list may not stay this short. AdExchanger, citing unnamed sources, reports it could eventually cover hundreds of ad tech, martech and data companies. And because the block works by domain, it can reach further than the companies it's aimed at.

One line in the WebKit post matters more than it looks. Apple says a central resolver is still a third party even when it handles only one company's data — so the first-party carve-out doesn't cover it. In other words, Apple's objection isn't only to covert scripts. It's to any intermediary in a position to match the same person across brands.

Separately, Apple's Hide My Email lets iCloud+ subscribers create a random, unique address for any site that asks for one. Those addresses don't match across brands, so even where nothing is blocked, email is a less dependable key than it used to be.

Who's affected?

Any DTC brand with meaningful Safari traffic should check its exposure. In the UK, that's most of them: Apple is the most-used phone brand on the UK mobile web, with around 47% of mobile page views in September 2026, according to StatCounter. Adoption is still early. StatCounter put iOS 27 on around 2% of UK iOS page views in September. But that share will climb quickly, so the exposure grows week by week. Three groups are most directly in the line of fire:

• Brands running universal-ID or identity-resolution scripts on their forms. If a vendor's script collects email on your login, checkout or newsletter pages, it may now be blocked for Safari users — and nothing on your side will flag it.

• Brands whose match keys depend on those vendors. If IDs from an identity-resolution provider feed your audiences or conversion matching, Safari users will contribute fewer of them over time.

• Brands buying audiences or measurement built on cross-site identity graphs. Fewer Safari users being resolved means thinner audiences and less complete measurement from those providers.

The brands least exposed are those whose conversion data reaches ad platforms through consented, first-party routes they control. The blocklist applies to requests sent to other sites, so collection that runs on the brand's own domain isn't what it catches. That only holds if the setup really is first-party: Safari already treats subdomains that quietly point to a third-party tracker as disguised tracking, and cuts their cookies to seven days.

What it means for your paid media

Much of the coverage focused on The Trade Desk, and that turned out to be the smallest part of the story: one domain, caught in the net and since taken off the list. The bigger change is the one that's staying. Apple's target is third-party identity resolution as a whole, the vendors whose job is to recognise the same person across websites. That workaround isn't coming back. So your own tracking has to work as well as it possibly can, because the conversion data you collect first-hand, with consent, is now carrying more of the load.

Apple hasn't said Meta's or Google's own matching is affected, and there's no evidence yet that it is: none of the domains in The Trade Desk's bug report belongs to Meta or Google. The risk sits wherever your match keys, audiences or measurement depend on identity-resolution vendors. And there, the biggest risk isn't that something breaks. It's that nothing visibly breaks, and the quality of your signal data degrades without anyone noticing.

Where that dependency exists (mainly in programmatic, audience and CDP tools, and wherever vendor-derived IDs feed Meta or Google), the chain looks like this:

1. Weaker match keys. Fewer Safari users arrive at ad platforms with an identifier the platform can match.

2. Lower match rates. Meta and Google can tie fewer conversions back to the people who saw or clicked the ad.

3. Worse inputs for automated bidding. Advantage+ and Performance Max optimise on the conversions they can see. When fewer conversions match, the algorithm learns from a smaller, more skewed sample.

4. Noisier CAC and ROAS. Reported performance on Safari-heavy audiences becomes less reliable. Budget decisions then rest on numbers that look precise but aren't.

None of this triggers an error message. Your pixel still fires and your dashboards still fill up. You just get a gradually blurrier view of who's buying, and so does the algorithm spending your budget.

Early buy-side data fits this: PMG reports no aggregate collapse in iOS and Safari programmatic delivery so far. That's exactly why it's easy to miss: where the damage happens, it shows up in your decisions, not your error logs.

What to do now

You don't need to panic, but you do need to look. Six checks worth running this month:

1. List what's on your forms. Go through every login, signup, checkout and newsletter page. Note each third-party script that can read the email field, what it's there to do and whether any of your audiences or match keys depend on it.

2. Check match quality and watch the trend. Check event match quality in Meta Events Manager and Enhanced Conversions diagnostics in Google Ads. These views don't split cleanly by browser, so use GA4 or your server logs to see how much of your converting traffic comes from Safari. Then watch how match quality moves over the coming weeks as Safari 27 adoption grows.

3. Enrich from your own customers, not third-party fillers. The strongest match keys are the ones customers give you directly, with consent: the email at checkout, the account login, the order history. Third-party data that adds or guesses identities you never collected can send platforms loose or wrong matches, and automated bidding will learn from them as if they were real. It also leaves you with a compliance question you can't fully answer: did that person agree to their data being used this way? Under UK GDPR and PECR, a vendor's assurance doesn't take the responsibility off you.

4. Make sure conversions reach platforms through consented routes you own. Server-side connections such as Meta's Conversions API and the Google Ads Enhanced Conversions API send first-party conversion data from your own systems, under your customers' consent. Apple's post doesn't say how it treats server-side uploads, so don't assume they're exempt. What they give you is a route you own and govern, instead of one that depends on a third-party script on your forms. They won't restore identifiers Safari now blocks. And don't use them to pass the same email to a blocked vendor from your server: by Apple's own reasoning, that wouldn't make the vendor first-party.

5. Make sure consent governs every route. Server-side doesn't mean consent-free. Check that your consent management platform controls server-side events as well as browser tags.

6. Monitor, don't fix once. Browsers, platforms and consent rules keep moving, so a setup that's sound today can drift next release. Track event volumes and match quality continuously, not just at implementation.

The bigger lesson isn't about Safari. Third-party cookies went first, and now the email-based workaround is going too. Each round removes another way of borrowing identity from someone else. What lasts is data your customers gave you directly, collected on your own domain, with their consent. As targeting and bidding become more automated, that data is one of the few performance levers you still control. Brands that treat it as infrastructure — owned, consented and monitored — will feel changes like this the least.

Find out what Safari is doing to your signal

Most of the time, nobody notices a tracking change until performance dips. Our free tracking audit looks at your conversion tracking and cookie compliance setup, flags anything that may be affecting your paid media performance and gives you clear next steps. If it finds gaps, Leaf Signal implements consented server-side routes and Watcher monitors them continuously. Book your audit now.