When you load a page, your browser draws a hard line between first-party and third-party requests. A request to the domain in the address bar is first-party. A request to tracker.example-analytics.net is third-party, and modern browsers treat third parties with suspicion: their cookies are partitioned or blocked, their storage is capped, and content blockers can match their domain against a filter list and refuse the connection outright.
CNAME cloaking erases that line. The publisher creates a subdomain on their own domain, say metrics.publisher.com, and points it at the tracking company using a DNS CNAME record. To the browser, every request to metrics.publisher.com looks like a same-site request to a sibling of the page you are reading. The browser sends first-party cookies along with it. The blocklist, which knows the tracker's real domain, never sees that name in the URL.
What a CNAME Actually Does
A CNAME (canonical name) record is a DNS alias. When a resolver looks up metrics.publisher.com and finds a CNAME pointing to publisher.tracking-vendor.net, it follows the alias and returns the tracker's IP address. The browser still believes it connected to metrics.publisher.com, because that is the name in the request, the TLS certificate (the vendor issues one for the publisher's subdomain), and the cookie scope.
The publisher delegates a slice of their own namespace to the tracker. The tracker operates infrastructure that answers as part of publisher.com. Cookies set on that subdomain are first-party cookies. Same-site protections do not engage. The arrangement is invisible at the URL layer and only shows up if something inspects the DNS resolution chain.
Filter lists like EasyPrivacy match request URLs against known tracker domains. A CNAME-cloaked request carries the publisher's own subdomain in the URL. The tracker's real domain appears only in the DNS answer, which the URL-matching layer never examines. The name on the envelope is clean; the forwarding address is the giveaway.
What the Tracker Gets
Because the request is first-party, the tracker collects more than it would as an obvious third party:
- First-party cookies that persist. On browsers that cap or wall off third-party cookies, a cloaked tracker sidesteps the cap by living in first-party scope.
- Other first-party cookies set by the site. A 2021 measurement study found cloaked trackers receiving cookies set by unrelated scripts on the same site, including session identifiers, leaking data the publisher never intended to share.
- Full request context. The page URL, referrer, and any first-party storage the script can reach from same-origin or same-site position.
That last point is the real cost. Cloaking does not just preserve one tracker's cookie. It can expose first-party state that other parts of the site rely on, because the browser cannot tell that metrics.publisher.com is operationally a different company.
How Defenders Unmask It
The fix is to resolve the CNAME chain and check the real target against the blocklist, not the URL. Different tools do this in different places:
| Defense | How it unmasks |
|---|---|
| uBlock Origin (Firefox) | Uses the browser DNS API to resolve the request hostname, then re-checks the canonical target against filter lists. Firefox exposes DNS resolution to extensions, which makes this possible. |
| Brave | Performs CNAME uncloaking in the network stack and applies adblock rules to the resolved target. |
| Safari (WebKit / ITP) | Caps the lifetime of cookies set in responses from CNAME-cloaked subdomains to seven days, blunting long-term identifiers without fully blocking the request. |
| Resolver-level (NextDNS, AdGuard DNS) | Follow the CNAME chain during resolution and refuse to return an answer when the target is a known tracker. Works for every device on the network, not just one browser. |
One notable gap: Chrome does not expose DNS resolution to extensions the way Firefox does, so extension-based uncloaking is much harder there. If you rely on a content blocker for this specific defense, the browser you run it in matters as much as the blocker.
What You Can Do
For a personal setup, the most reliable single move is resolver-level uncloaking. A DNS service that follows CNAME chains and blocks on the target protects every device that uses it, including phones and apps that never run a content blocker. Pair that with Firefox plus uBlock Origin, or with Brave, and the same request gets checked twice: once at the resolver and once in the browser.
This is also a useful reminder that DNS is not a neutral lookup service. It is a layer where identity, trust boundaries, and tracking all get negotiated. The same machinery that makes encrypting your DNS queries worthwhile is the machinery that CNAME cloaking abuses. If you have read about DNS leaks or QNAME minimization, this is the same surface, viewed from the tracking side.
The Broader Pattern
CNAME cloaking belongs to a family of techniques whose only purpose is to convert a third-party relationship into a first-party one so that privacy protections stop applying. Link decoration does it by smuggling identifiers through URLs. First-party data clean rooms do it at the server. Cloaking does it at DNS. In every case the defense is the same in spirit: judge a request by what it actually is and where it actually goes, not by the label it presents.
For a messaging and email service, the lesson sits underneath the product. The reason we run our own resolution and connection paths rather than pulling in third-party analytics is that every embedded measurement script is an invitation to exactly this kind of laundering. The cleanest way to not leak first-party state to a disguised third party is to not invite the third party in.