Your server-side GTM setup uses ss.yoursite.com to bypass ad blockers. Brave users still see nothing. That’s because Brave doesn’t just check the domain name—it resolves the DNS to see where your subdomain actually points. If it’s a CNAME alias to stape.io, sgtm.eu, or any known tracking infrastructure, Brave blocks it anyway.

This is CNAME uncloaking, and it defeats the most common “first-party” tracking workaround. Brave introduced this in version 1.17.73 back in November 2020 (Brave Official), making it the first Chromium-based browser with native CNAME blocking. With 100+ million monthly active users, Brave represents a significant slice of privacy-conscious visitors who see right through the subdomain trick.

How CNAME Cloaking Is Supposed to Work#

The logic behind CNAME cloaking is simple: ad blockers maintain lists of known tracking domains. If your page loads a script from analytics.google.com or connect.facebook.net, blockers recognize these domains and kill the request.

The workaround? Create a subdomain on your own domain—measure.yoursite.com—and set it as a CNAME alias pointing to the tracking domain. Traditional ad blockers see the request going to “yoursite.com” and let it through. The DNS system quietly redirects it to the actual tracking infrastructure.

1,762 websites in the Alexa Top 300K were detected using CNAME cloaking (APNIC, 2020). This wasn’t a fringe technique—it was widespread enough that researchers published studies on its prevalence. Marketers adopted it because it worked. Past tense.

Why Brave Sees Through the Disguise#

Brave doesn’t stop at checking the request URL. It performs DNS resolution to identify what’s behind the CNAME alias.

Here’s what happens when a Brave user visits your site:

Your page requests ss.yoursite.com/analytics.js → Brave resolves the DNS → Finds CNAME record pointing to tracking.stape.io → Checks blocklist → Blocks the request.

“With CNAME uncloaking, Brave is able to detect the CNAME redirection and block the initial script before it can initiate requests to any other third-party trackers” (Brave Blog). The subdomain never loads. Your tracking never fires. The user is invisible to your analytics.

This is different from how most ad blockers work. uBlock Origin can also detect CNAME cloaking, but only in Firefox using the browser.dns API—it blocks 70% of CNAME-cloaked tracking there (APNIC Research, 2020). In Chrome, uBlock Origin can’t access DNS records, so the subdomain trick still works. Brave built CNAME uncloaking directly into the browser, enabling it by default for all users.

You may be interested in: Brave Blocks Adobe Analytics, GA4, and Meta Pixel: The Complete List of What Privacy Browsers Kill

The Server-Side GTM Subdomain Problem#

Server-side GTM hosting services like Stape and TAGGRS tell you to create a subdomain—ss.yoursite.com or gtm.yoursite.com—and point it to their infrastructure. This makes the tracking appear first-party while running on third-party servers.

The tracking flow looks like this:

Browser loads ss.yoursite.com/gtm.js → DNS resolves to Stape’s servers → GTM container executes → Events flow to GA4, Facebook, etc.

For most visitors, this works. For Brave’s 100+ million users, the chain breaks at step two. Brave resolves the DNS, sees the CNAME pointing to tracking infrastructure, and blocks the script load entirely.

Brave Shields blocks CNAME cloaking on approximately 50% of affected websites (APNIC Research, 2020). That’s half your CNAME-cloaked tracking gone for Brave users—and this research predates Brave’s user growth from 2020 to present.

What “True First-Party” Actually Means#

There’s a difference between appearing first-party (CNAME cloaking) and being first-party (same-origin requests).

CNAME cloaking: Your subdomain, their servers. The request looks like it’s going to yoursite.com, but DNS redirects it to third-party infrastructure. Brave sees through this.

True first-party: Your server, your requests. Your WordPress server captures events and sends them directly to destination APIs—GA4 Measurement Protocol, Facebook Conversions API, Google Ads Enhanced Conversions. The HTTP requests originate from your server’s IP address. There’s no CNAME alias involved. There’s nothing to uncloak.

When your server makes an API call to Google or Facebook, that’s server-to-server communication. Brave isn’t inspecting your server’s outbound HTTP requests—it only sees what happens in the browser. If no tracking script loads in the browser, there’s nothing for CNAME uncloaking to detect.

You may be interested in: Server-Side Tracking for WordPress Without Leaving WordPress: Why Plugin-Based Beats Container-Based

The Architecture That Bypasses CNAME Uncloaking#

The key is removing the browser from the tracking chain entirely for server-side events.

CNAME-based architecture (blocked by Brave):

Browser → ss.yoursite.com (CNAME to tracking host) → Tracking infrastructure → Destination APIs

True server-side architecture (bypasses Brave):

Browser → Your WordPress server (captures event via hooks) → Your server sends HTTP request → Destination APIs

In the second architecture, Brave never sees a request to a tracking domain because there isn’t one. The browser communicates with your WordPress server. Your server communicates with destination APIs. Two separate hops with no CNAME in between.

This is why WordPress-native server-side tracking doesn’t have the CNAME problem. Events are captured by PHP hooks when users take actions—page views, add to cart, purchases. Your server sends those events to GA4, Facebook, or Google Ads using their official server APIs. The browser is only talking to your WordPress site.

What This Means for Your Tracking Stack#

If you’re using a CNAME-based server-side GTM setup, understand what you’re losing:

Brave users (100+ million) see approximately 50% of your CNAME-cloaked tracking blocked. That’s not zero—some requests may still get through depending on blocklist completeness—but it’s significant data loss from a privacy-focused audience segment.

Firefox users with uBlock Origin (browser.dns API) see 70% blocked. This is a smaller but highly engaged segment.

The trend is toward more blocking, not less. Browser privacy features are expanding. What works today may not work next year. Building your tracking on a workaround that browsers are actively defeating is building on sand.

For WordPress stores needing reliable server-side tracking without the CNAME vulnerability, Transmute Engine™ sends events directly from your WordPress server to destination APIs. No subdomain pointing to third-party infrastructure. No CNAME to uncloak. Just your server talking to Google and Facebook the way they designed their APIs to be used.

Key Takeaways#

• Brave resolves CNAME records to detect when “first-party” subdomains actually point to third-party tracking domains
• If ss.yoursite.com is a CNAME alias to Stape or similar services, Brave blocks it just like it blocks the original tracking domain
• Brave Shields blocks CNAME cloaking on approximately 50% of affected websites—with 100+ million users, that’s significant data loss
• True server-side tracking bypasses CNAME uncloaking because your server sends API requests directly to destinations—no subdomain alias involved
• The subdomain trick worked against traditional ad blockers but fails against browsers that resolve DNS to verify the actual destination

Frequently Asked Questions#

Stop relying on tracking workarounds that browsers are actively defeating. See how true server-side tracking works for WordPress.