CNAME cloaking is one of the most sophisticated tracking evasion techniques in use today — and one of the most legally problematic under GDPR. It allows organisations to disguise third-party trackers as first-party cookies by using DNS delegation, making them invisible to ad blockers, browser privacy controls, and even most compliance scanners.
What is CNAME cloaking?
Normally, when a website loads a tracker from a third party — say, analytics.thirdparty.com — the browser identifies it as a cross-origin request and applies third-party cookie restrictions. Safari's Intelligent Tracking Prevention (ITP) blocks third-party cookies entirely. Firefox's Enhanced Tracking Protection does the same. Chrome is following suit.
CNAME cloaking works around this by creating a DNS CNAME record that points a subdomain of the first-party domain to the third-party tracker. Instead of loading analytics.thirdparty.com, the site loads metrics.yourcompany.com — which DNS resolves to the same third-party server. The browser sees a first-party request. The cookies are set as first-party cookies. The tracker operates with full access.
This technique was documented at scale in 2021 by Dimova et al. (KU Leuven, PETS 2021 — "The CNAME of the Game"), who found CNAME tracking on approximately 10% of the top 10,000 websites globally, with adoption rising 21% over the preceding 22 months. Enterprise organisations using Adobe Analytics, Eulerian, and Salesforce Marketing Cloud actively promote CNAME-based first-party data collection as a feature.
Why CNAME cloaking violates GDPR
The legal problem is not the DNS trick itself — it is what it enables. CNAME cloaking is almost always deployed to circumvent cookie consent mechanisms. When a user clicks 'Reject All' on a cookie banner, the consent management platform instructs the browser to block third-party tracking requests. But a CNAME-cloaked tracker appears to the CMP as a first-party resource. Many CMPs fail to block it.
This creates a direct violation of Article 5(1)(a) GDPR — the principle of transparency. The privacy policy discloses that the site uses, for example, Adobe Analytics. But it does not disclose that Adobe Analytics is being loaded as a first-party cookie via a CNAME delegation. The data subject's meaningful consent — even when given — is uninformed.
Article 5(3) of the ePrivacy Directive (implemented in Sweden as LEK 9 kap. §28) requires prior informed consent before storing or accessing information on a user's device. CNAME cloaking that bypasses consent rejection is a direct violation. The CJEU has consistently held that technical workarounds that circumvent consent do not retroactively gain legal basis — the consent was for a disclosed purpose, not an undisclosed technical mechanism.
EDPB Opinion 5/2019 on the interplay between the ePrivacy Directive and GDPR makes clear: the identity of the entity accessing a device is material to consent. A tracker disguised as first-party is not the same service the user consented to.
How to detect CNAME cloaking on your own site
Detection requires DNS-level inspection — you cannot see it in the browser's Network tab because the browser itself is deceived. Here are three methods, from easiest to most thorough.
Method 1: DNS lookup on your own subdomains
Open a terminal and run a CNAME lookup against every subdomain that appears in your site's network requests. For example: dig CNAME metrics.yourcompany.com. If the answer section shows a CNAME pointing to a third-party domain (e.g., metrics.yourcompany.com → client.tracker.net.akadns.net), you have CNAME cloaking in place. Cross-reference the target domain against known tracker databases such as Disconnect.me or EasyPrivacy.
Method 2: HAR file analysis
In Chrome DevTools, open the Network tab, reload the page with cache disabled, then export the HAR file (right-click → Save all as HAR). Open the HAR JSON and search for 'Set-Cookie' response headers. Any cookie set via a response from a subdomain of your own domain may be CNAME-cloaked — run a DNS lookup on each such subdomain to confirm.
Method 3: Automated compliance scanner
Vakteye's scanner automatically resolves CNAME chains for all network requests made during a page visit. It cross-references final destination hostnames against a tracker database of 1,000+ known tracking domains. Findings appear as CNAME_CLOAKING_DETECTED with FIRM confidence when the resolved destination matches a known tracker.
How to test whether consent blocks CNAME-cloaked trackers
Detecting the presence of CNAME cloaking is step one. Step two is determining whether your consent management platform actually blocks the tracker when a user rejects consent. Many CMPs fail this test silently.
To test manually: (1) Open an incognito browser window. (2) Visit your site and click 'Reject All' on the cookie banner. (3) In DevTools → Network tab, filter by the subdomain you identified above. (4) Check whether requests to that subdomain are still being made after rejection. (5) Check whether any cookies were set by responses from that subdomain after rejection.
If requests continue after rejection, your CMP is not blocking the CNAME-cloaked tracker. This is a live GDPR violation — not a theoretical risk.
Adobe Analytics, Eulerian, and Piano Analytics (formerly AT Internet) all offer CNAME-based deployment modes. If you use any of these, test explicitly — they are the most common source of CNAME cloaking findings in Vakteye scans.
Which consent management platforms handle CNAME correctly?
The landscape varies significantly. CMPs that use network-layer blocking (intercepting actual HTTP requests) can block CNAME-cloaked trackers regardless of how they appear to the browser. CMPs that rely solely on JavaScript tag blocking will miss CNAME-cloaked trackers, because the JavaScript sees a first-party URL.
- Usercentrics (with Cookiebot integration): supports network-layer blocking — can block CNAME-cloaked trackers if configured correctly
- OneTrust: depends on configuration; native tag blocking will miss CNAME cloaking; server-side enforcement handles it
- Cookiebot (standalone): uses DNS-based detection internally; can identify CNAME-cloaked domains but blocking depends on implementation
- Axeptio, CookieFirst, Complianz: JavaScript-based tag blocking only — will not block CNAME-cloaked trackers post-reject
The safest remediation is to remove the CNAME delegation entirely if the tracker can function without first-party cookie access. The second-best option is server-side tag management (e.g., Google Tag Manager server-side, Tealium EventStream), which allows consent signals to be enforced before requests leave your infrastructure.
Regulatory enforcement: what IMY and other DPAs have said
No DPA has yet issued a fine specifically naming CNAME cloaking by term. However, multiple enforcement decisions address the underlying conduct: trackers operating after consent rejection, and trackers not disclosed in privacy policies.
The French CNIL fined Google €150 million and Facebook €60 million in 2022 for cookie banner designs that made rejection more difficult than acceptance. The same reasoning extends to CNAME cloaking: if a user cannot meaningfully reject tracking because the CMP does not detect the tracker, the consent mechanism is non-compliant regardless of its visual design.
IMY's 2025 enforcement programme explicitly includes automated technical audits of cookie implementations. Vakteye's scanning data shows that sites using CNAME cloaking have a 100% failure rate on post-rejection tracker verification — meaning IMY's automated tools, which replicate this verification, would flag these sites.
Remediation checklist
- Run dig CNAME on all subdomains that appear in your site's network traffic
- Cross-reference CNAME targets against Disconnect.me, EasyPrivacy, or run through Vakteye scanner
- For each confirmed CNAME-cloaked tracker: test whether consent rejection blocks it in your CMP
- If not blocked: either remove the CNAME delegation or switch to server-side tag management with consent enforcement
- Update your privacy policy to explicitly disclose the first-party subdomain used for analytics
- Re-test after remediation using the HAR method above
- Schedule quarterly automated scans to catch regressions
Test your site for CNAME cloaking
Vakteye's scanner automatically resolves CNAME chains and cross-references them against 1,000+ tracker domains — including detection of whether post-reject consent actually blocks them.
Scan your site