Safari 27 Blocks Email-to-ID Ad Trackers: Audit Your Stack

Safari 27 Blocks Email-to-ID Ad Trackers: Audit Your Stack
Safari 27 Blocks Email-to-ID Ad Trackers: Audit Your Stack
Affiliate disclosure: This post contains affiliate links. If you buy through them, I may earn a commission at no extra cost to you. Full disclosure

Apple’s WebKit team confirmed on October 19 that Safari 27 blocks network access to third-party services that turn email addresses into tracking IDs.

If you run a high-ticket store and pay an agency or vendor for programmatic retargeting, connected TV or audience matching, part of that spend may now reach Safari shoppers with no identifier attached. Safari held 46.38% of US mobile browser traffic in September 2026, per StatCounter, so this is no corner case. I track platform changes like this at Ecommerce Paradise because they hit ad budgets quietly: no error message, just worse numbers.

If your stack is Meta, Google and email you send yourself, you are probably not directly named. You should still confirm that before Black Friday traffic arrives. Below: what WebKit said, how the block surfaced, the rough math on a typical budget, and five checks for this week. If you are still learning the model, start with my guide on what high-ticket dropshipping is.

Rebuilding your ad stack? Build it on a properly formed LLC: form your LLC with Northwest Registered Agent, the best LLC formation service for ecommerce owners. It beats cheap formation sites that bury you in upsells because Northwest charges the same renewal price as year one. Start your LLC the right way →

Safari 27 Blocks Identity Resolvers That Turn Emails Into IDs

The WebKit post is titled “Blocking Identity Resolution Infrastructure.” It went up October 19 under the names John Wilander, Charlie Wolfe and Matthew Finkel, per the WebKit blog. It says the block ships in the iOS, iPadOS, macOS and visionOS 27 releases.

The post describes the mechanism this way. A third party sits on a page where a visitor types an email address, at login or newsletter signup, and mints an ID tied to that address. The WebKit authors wrote that “Logging out or unsubscribing from that newsletter does not remove the tracking ID.” They added that email addresses “almost always constitute Personally Identifiable Information.”

The fix is blunt. “Safari and WebKit block network access to identity resolution infrastructure to prevent cross-site tracking,” the post says. It also says “The blocking is done on the domain level,” which means a vendor cannot get around it by restructuring requests.

One carve-out matters for store owners. Per the post, “First party personalization is not tracking, and is not what our technologies seek to prevent.” The target is a central resolver that combines data across sites, devices and companies, something no single first party can do alone.

The post leaves several questions open. It names no companies and publishes no list of blocked domains. It does not mention hashing. It does not describe how server-side processing is treated. It does point iCloud+ users to Hide My Email, which generates a unique random address for each new site and forwards mail to the real inbox.

Which domains are on Apple’s list

Apple has not published the list. According to PPC Land’s September 30 report, a bug report on WebKit’s public tracker reproduced nine entries from it: uidapi.com, adsrvr.org, id5-sync.com, eu-1-id5-sync.com, rlcdn.com, pippio.com, permutive.com, ad.gt and a test domain. PPC Land noted that Apple has not confirmed the contents.

Per Relevant Audience, the identity providers tied to those entries include Unified ID 2.0, ID5, Audigent, LiveRamp and Permutive. Treat that mapping as press reporting, not an Apple statement. iOS 27 began rolling out September 14, so anyone who updated their iPhone since then is already browsing under these rules.

Trade Desk Bug Report to Public Policy: The Safari 27 Timeline

The block did not arrive in one piece. Per PPC Land, Charlie Wolfe merged an 11-line WebKit change on February 13, 2026, adding a hook for blocking requests unconditionally. In public code it defaults to off, so nobody noticed.

In July, source-code reviews of the Safari 27 beta found tracker restrictions already in place. According to PPC Land’s account of a TAGGRS review by Mariusz Brucki, dated July 6, Bing’s Universal Event Tracking endpoint resolved to a blocked Microsoft ad-infrastructure IP range. The same review put the LinkedIn Insight Tag on a fingerprinting-restriction list. Stape published a similar beta analysis on July 16. Both were source-code readings of a beta, not confirmed release behavior.

The public fight began September 21. Ian Meyers, senior director of engineering at The Trade Desk, filed a WebKit bug saying adsrvr.org is the company’s “core ad request and delivery domain, not identity,” per PPC Land. Wilander replied September 22: “We’re investigating.” On September 28 he said he would report back “if and when any changes are available for you to test.” AdExchanger reported the block on September 29. I covered that first wave in my post on iOS 27 blocking Trade Desk ads in Safari.

Per Relevant Audience, Wilander asked The Trade Desk on October 5 to test an iOS 27.2 beta, and IAB Tech Lab’s Rowena Lam said on October 13 that the block had shipped on macOS 27. PPC Land reported October 20 that adsrvr.org was removed from the block in a beta build without explanation. That leaves two separate questions: whether ad delivery domains stay blocked, and whether identity resolvers stay blocked. The WebKit post answers only the second.

The counterpoint from ad tech

Apple has not said whether the adsrvr.org block was deliberate, and the vendors argue the stakes are real. Permutive’s own August figure, a vendor claim reported by PPC Land, puts the CPM penalty for lacking an identity signal at 41%. WebKit’s answer is that this is the point. Safari began blocking all third-party cookies on March 24, 2020, and the authors wrote, “We fully blocked cross-site cookies six years ago.” Identity resolution, in their framing, is the workaround that cookie blocking left standing.

What Safari 27’s Identity Block Does to Your Ad Budget

Everything from here is my analysis, not reporting.

My read is that most Shopify stores are not directly exposed. If your paid traffic is Meta, Google Shopping and search, and your email goes out through your own list, no named identity provider sits in that path. Exposure comes through intermediaries: an agency running programmatic retargeting, a connected TV buy, an audience-onboarding vendor, or a retargeting app that quietly depends on an email-based ID. You might not know which of those you pay for until you ask.

Safari’s weight is what makes asking worthwhile. StatCounter put Safari at 46.38% of US mobile browser share in September 2026, against 47.44% for Chrome. Your own mix will differ, and for a high-ticket store it often leans toward whatever device your older, affluent buyers carry. Check it rather than assuming.

Hypothetical math on a $10,000 budget

This is a hypothetical, not a reported figure. Say you spend $10,000 a month on ads and $3,000 of it goes to programmatic or connected TV retargeting through a vendor that relies on email-based IDs. If 46% of those impressions land on Safari mobile, about $1,390 a month is aimed at shoppers where the ID may never mint. That money is not necessarily lost. It may still show ads. What you lose is matching, frequency control and attribution, and you pay full price for impressions you can no longer tie to a buyer.

That is the quiet failure mode. Your platform dashboard keeps reporting spend, and your cost per sale on Safari drifts up for weeks before anyone connects it to an operating system update. The same pattern showed up when Shopify retired checkout scripts, which I flagged in Shopify Kills Checkout Scripts Aug. 26.

Three scenarios, with thresholds

These thresholds are rules of thumb I would use, not industry standards.

Scenario one: no programmatic, no audience onboarding. Nothing changes. Confirm it in writing with every vendor, then move on. Your open tracking questions are the ones in my write-up on Google’s tag gateway. The related Google Tag Manager gtag change belongs on the same list.

Scenario two: programmatic is under 10% of ad spend. Watch it. Compare Safari and Chrome cost per sale monthly and act only if the gap grows.

Scenario three: programmatic is over 25% of spend and Safari is over 40% of your sessions. Treat it as a live problem. Ask the vendor for Safari-only delivery and match-rate reporting this week, and cap the budget until they provide it.

What nobody has confirmed

Three things stay unconfirmed in everything I reviewed. WebKit does not say how it treats hashed emails. It does not say how it treats server-side uploads such as Meta’s Conversions API or Google’s enhanced conversions. And it names no vendor. Per Relevant Audience’s analysis, the post neither exempts nor addresses hashed emails, and an email sent to a third-party resolver from a server would not become first party under the post’s own reasoning. I would not assume Meta or Google are affected, and I would not assume they are safe. Where I have seen specifics, they point at identity providers and ad delivery domains, not at the big platforms.

My read on direction is simpler. WebKit’s two stated principles are that email is personal data and that first-party personalization is fine. Owned audiences sit on the right side of both. An email list you built, a phone number you answer and a quote request you log in your own CRM do not depend on a resolver that Apple can block with an 11-line change. I made a similar argument about consent and data rules in my post on California’s SB 690 pixel lawsuits. The same logic applies to the EU Council cookie consent draft.

The operator problem here is that none of this is visible from inside Shopify. You need someone who reads WebKit bug trackers, audits vendor contracts and watches Safari conversion rates. If you would rather have a team own the tracking, the ad stack and the store while you run the business, that is what my turnkey done-for-you service is built for.

Want 1-on-1 coaching to audit your tracking and ad spend before Black Friday? Get the coaching details →

Run These Five Safari Tracking Checks This Week

Five checks, in the order I would run them:

  1. Email every agency, freelancer and ad vendor and ask in writing whether they use Unified ID 2.0, ID5, LiveRamp, Permutive or any email-based identifier, and what changes on Safari 27. Ask for Safari-only delivery and match-rate numbers. If a vendor cannot answer within a week, treat that as an answer.
  2. Open Google Analytics 4, go to Reports, then Tech, then Tech details, and set the primary dimension to browser. Note Safari’s share of sessions and orders for the last 30 days. Anything over 40% puts you in scenario three if programmatic is a big line item.
  3. Compare Safari and Chrome conversion rate and cost per sale on each paid channel for the same 30 days. Flag any channel where Safari cost per sale runs more than 25% above Chrome. Then check what your Shopify customer events and pixels are sending, since a broken event looks identical to a blocked one in the numbers.
  4. Move no more than 20% of any exposed programmatic budget into Google Shopping and search for two weeks, then compare. My notes on turning Google Shopping clicks into sales on high-ticket products cover the setup.
  5. Strengthen what you own. Build signup, abandoned-cart and post-purchase flows in Klaviyo or Omnisend, clean the list with ZeroBounce, set consent properly with Termly, and log phone and quote leads in a CRM such as HubSpot so they count even when browser tracking misses them.

If you want a second set of eyes on your numbers, book a free call through my discovery page. Pair this work with my Black Friday checklist for stress-testing your store so the tracking fix lands before the traffic does.

Frequently Asked Questions

Does Safari 27 block the Meta Pixel or Google tags?
The WebKit post names no companies. In July source reviews, per PPC Land, the Bing Universal Event Tracking endpoint and the LinkedIn Insight Tag were restricted in the Safari 27 beta. I found no sourced evidence that Meta or Google tags are blocked, and I would test rather than assume. My notes on Meta’s per-creative audience change cover another recent Meta shift.

Does this stop me from emailing my customers?
No. The block covers network access to third-party identity resolvers, not email you send to your own list. WebKit says first-party personalization is not what it is trying to prevent.

Is a hashed email exempt?
Unknown. The WebKit post does not mention hashing, and Relevant Audience reports that it neither exempts nor addresses hashed emails. Ask any vendor that depends on hashed emails how they tested Safari 27.

Who is affected, and since when?
People on iOS, iPadOS, macOS or visionOS 27. iOS 27 began rolling out September 14, per PPC Land. Shoppers still on older versions are not covered by this block, so your exposure grows as people update.

What is an identity resolution service?
A third party that matches an email address typed at login or newsletter signup to a persistent ID, then uses that ID to recognize the person across sites and devices. Most stores never contract with one directly. Their ad vendors do.

I’m still planning my store. Does this change what I should build?
It is another reason to build an owned audience from day one. My high-ticket niches list is a good place to start picking a category. The free beginner guide then walks through the setup.

Want my team to scale the store you already have, tracking and ad spend included? See the scaling service →

Apple can change these rules without warning, and I will keep watching the WebKit tracker. Subscribe to the YouTube channel for daily breakdowns. More breaking news coming through the day.

Related Articles

If this was useful, these go deeper: