What One Unsubscribe Link Revealed About Cross-Site Tracking

In early February 2026, I received a promotional email from rates.ca, a Canadian financial comparison site, and clicked the unsubscribe link at the bottom. Unexpectedly, my Brave browser displayed a full-page warning: "This site may attempt to track you across other sites." I was surprised because I had visited rates.ca before without any problems, and Brave never blocked anything on the main site. The unsubscribe link led to info.rates.ca, which seemed to be part of the same website. To investigate why that warning appeared, safely, I set up an isolated Docker environment and visited the link there. This lets me record every DNS lookup, HTTP request, redirect, cookie, and script involved.

Methodology

DNS analysis. I used dig and nslookup (standard DNS lookup tools) to trace where info.rates.ca actually resolves and why Brave treated it differently from rates.ca.

URL structure decoding. The unsubscribe link contained a structured URL with multiple parameters. Using Act-On's public developer documentation, I identified what each segment represents.

Isolated browser capture. I ran the link inside a Docker container using Chromium and Playwright, a browser automation tool. The container started fresh, with no cookies, browsing history, or user profile. I recorded every HTTP request, redirect, cookie, and script. Afterward, I deleted the container. If you want, I can share the Dockerfile and capture script.

This Docker setup only lets me see what happens on the client side and the network traffic. I can't see how Act-On handles data on their servers, and I don't have access to their source code or private documentation.

The DNS Trail

DNS (Domain Name System) works like the internet's address book: it converts domain names (like rates.ca) into the IP addresses that computers use to connect. When I looked up info.rates.ca, I expected it to resolve to the same servers as rates.ca, but it resolved to actonsoftware.com.

info.rates.ca
→ CNAME → a39960.actonsoftware.com
→ CNAME → aorpci6.actonsoftware.com
→ A record → 44.228.80.27

info.rates.ca is not hosted by rates.ca. It's an alias, a CNAME (Canonical Name) record, that points to servers operated by Act-On Software, a B2B marketing automation platform. The number 39960 appears to be rates.ca's customer account ID in Act-On's system, based on its consistent appearance in the CNAME record (a39960.actonsoftware.com) and throughout Act-On's URL structure for this client.

This method is known as CNAME cloaking. Browsers see subdomains like info.rates.ca as "first-party," so they trust them as part of the main site. Third-party content from outside companies is usually checked more carefully. By making Act-On's servers appear to be info.rates.ca, the tracking system gains first-party trust. Even if you block third-party cookies, it won't help here, because the browser treats cookies from info.rates.ca as first-party cookies.

This is not an edge case. Palo Alto Networks' Unit 42(opens in a new tab) detected CNAME cloaking across more than 38,000 domains in a single month of monitoring, spanning dozens of tracking providers. A study by Dao et al.(opens in a new tab) (summarized by RIPE Labs) found that Adobe alone accounted for 61% of CNAME-cloaked domains. Unit 42 identified Act-On's beacon cookie on 75 websites they analyzed. A 2021 study by Dao et al.(opens in a new tab) at Boston University found that 95% of websites using CNAME cloaking leak private data (including full names, email addresses, locations, and authentication cookies) to the tracking company.

In simple terms: The unsubscribe link appears to belong to rates.ca, but your request actually goes to a third-party marketing company. Your browser can't tell the difference.

The URL Structure

https://info.rates.ca/acton/rif/39960/s-103d-2602/-/l-03cc:CONTACT_ID/q-07f8/zout?sid=TV2:SESSION_TOKEN

The URL includes the CNAME-cloaked hostname (info.rates.ca), the Act-On account ID (39960, which matches the CNAME record), campaign and send identifiers, and a session token unique to this click. Two parts are especially important:

l-03cc:CONTACT_ID is a persistent contact record ID. Based on Act-On's developer documentation, this uniquely identifies a single individual in their database. Every interaction tied to this identifier builds a profile: which emails were opened, which links were clicked, when, and from where.
zout is the unsubscribe action. It's the only part of the URL that tells the user what they want. Its opposite, zin, means resubscribe.

Clicking "unsubscribe" creates one of the most detailed tracking events in the process. It confirms your email address is valid, logs your IP address, browser fingerprint, and the exact time, all linked to your contact record. This data is sent to Act-On's servers as soon as the HTTP request is made, before any page loads.

What the Browser Capture Revealed

Step 1: The confirmation page

The URL loads a basic HTML page with a "Click to confirm opt-out" link. This link uses a JavaScript redirect instead of a normal hyperlink, which is why I needed Playwright to follow the entire process.

Step 2: The actual unsubscribe

Clicking "confirm" triggers the following chain:

JS redirect → info.rates.ca/acton/blocks/zoutNow.jsp?...
302 redirect → info.rates.ca/acton/blocks/showLandingPage.jsp?...
Page loads with resources from 4 external domains

The landing page shows "You've been unsubscribed." It also sets a cookie that wasn't there after Step 1.

The Docker environment started with a clean browser—no cookies or history. On a regular computer, this cookie might already exist from earlier visits to rates.ca if the main site uses Act-On's tracking beacon. The unsubscribe page might not be the first place this cookie is set, but it's where I found it during my test.

The cookie (wp39960) is scoped to .rates.ca (the parent domain, not just info.rates.ca), set with SameSite=None, readable by JavaScript (httpOnly=false), and expires in approximately one year.

SameSite=None means the cookie is sent even when other websites make requests to rates.ca. Normally, a cookie with SameSite=Lax is only sent when you visit the site directly. The None setting removes this restriction.

With httpOnly set to false, any JavaScript on the page can read the cookie's value. Usually, only the server can read cookies. This setting increases the risk if the site ever loads a compromised script.

The logo link. The RATESDOTCA logo at the top of the unsubscribe page links to:

info.rates.ca/acton/ct/39960/p-optout/Bct/l-03cc/l-03cc:CONTACT_ID/ct0_0/1/lu?sid=TV2:SESSION_2

/acton/ct/ is Act-On's click-through tracking endpoint, which is different from the /acton/rif/ used in the email. The session token (TV2:SESSION_2) differs from the one in the email (TV2:SESSION_1). Act-On creates a new tracking session at each step: one for clicking the unsubscribe link in the email and another for clicking the logo on the confirmation page. CNAME cloaking is used selectively. The logo image first loads from info.rates.ca/cdnr/… (which is cloaked), but then redirects to cdn-aorpci6.actonsoftware.com, showing Act-On's real identity. The resubscribe link at the bottom goes straight to a39960.actonsoftware.com without any cloaking. So, cloaking is used for tracking endpoints but not for CDN assets or resubscribe links.

In plain English: The page that says "you've been unsubscribed" sets a tracking cookie that can follow you across websites for about a year. The confirmation page also keeps tracking what you click next.

What Browser Engines Detect (and Miss)

The three major browser engines handle CNAME cloaking differently.

Chromium doesn't detect CNAME cloaking. It doesn't do recursive DNS checks on network requests or share DNS data with extensions(opens in a new tab). Privacy extensions in Chromium-based browsers like Chrome, Edge, Arc, or Opera can't spot CNAME cloaking in real time. They rely on a static list of about 6,000 known cloaked domains, which research shows only catches around 10%(opens in a new tab) of CNAME-cloaked subdomains.

Brave is based on Chromium but adds its own privacy layer(opens in a new tab). Brave's Shields feature does recursive DNS checks on every network request before Chromium handles it. When Brave checked info.rates.ca, it followed the CNAME chain to actonsoftware.com (which is on its blocklist) and blocked the connection before any data was sent. This protection is unique to Brave and isn't found in other Chromium-based browsers.

WebKit (used by Safari) limits cookies set through CNAME-cloaked subdomains to 7 days(opens in a new tab) instead of a year, but it doesn't warn the user. When Safari with AdGuard blocked the page, it just said: "Safari can't open this page because it was blocked by a content blocker." There was no mention of tracking, no domain name, and no explanation. Safari also offered a "Reload Without Content Blockers" button that let users bypass protection without any context.

Gecko (used by Firefox) doesn't detect CNAME cloaking by default, but it does provide a browser.dns.resolve API for extensions. That's why uBlock Origin(opens in a new tab) and AdGuard can detect CNAME cloaking on Firefox, but not on Chromium-based browsers. Mozilla considered blocking CNAME cloaking by default(opens in a new tab) but decided against it, saying their Total Cookie Protection already reduces the risk.

Network-level DNS tools like Pi-hole(opens in a new tab) (with Deep CNAME Inspection) or NextDNS(opens in a new tab) check the entire CNAME chain, compare it against blocklists, and block connections at the DNS level. This protects every device on your network, not just one browser.

Private browsing doesn't stop this. Incognito mode starts with no cookies and deletes them when you close the window, but it doesn't block CNAME cloaking, doesn't stop the cookie from being set during your session, doesn't hide your IP address, and doesn't prevent tracking data in the URL from reaching Act-On's servers. Tracking still occurs during your session.

Neither the confirmation page nor the landing page had a cookie consent banner, consent management script, or any way for users to accept or reject cookies. The wp39960 cookie was set without any notice.

Even if there had been a consent banner, it would fail for three separate reasons:

The cookie was set via an HTTP Set-Cookie response header at the network level, before any JavaScript runs, before the page loads, and before any consent banner could appear. By the time a banner could ask for permission, the cookie is already stored.
CNAME cloaking gets around how consent platforms categorize cookies. Consent tools usually allow first-party cookies (from the site you're visiting) as "necessary" and flag third-party cookies as "marketing." Because of CNAME cloaking, the wp39960 cookie comes from info.rates.ca, so a consent platform would see it as first-party. It can't tell that info.rates.ca actually points to actonsoftware.com.
URL-based tracking happens before you can interact with any consent banner. The contact ID, campaign ID, and session token are sent to Act-On's servers as soon as the HTTP request is made. No cookie consent tool can stop data in the URL from reaching the server.

Cookie leakage makes things worse. Since info.rates.ca is CNAME-cloaked to Act-On's servers, all first-party cookies set for .rates.ca are sent to Act-On with every request to info.rates.ca. This includes cookies that weren't meant for Act-On, like Google Analytics cookies (_ga, _gid), session tokens, and anything else rates.ca sets on its main domain. The 95% leakage rate found by Dao et al.(opens in a new tab) even included authentication cookies.

Functional Necessity vs. Tracking Capabilities

Email marketing platforms need some data to function. The distinction is between what's necessary for the requested operation and what goes beyond it.

Every function rates.ca needs (processing the unsubscribe, measuring email performance, managing subscriber lists) would work with a cookie limited to info.rates.ca, using SameSite=Lax and httpOnly=true. Instead, the cookie is scoped to all of .rates.ca, sent with cross-site requests (SameSite=None), and readable by any JavaScript running on rates.ca pages. Campaign IDs and contact IDs in the URL are standard; most email platforms use similar identifiers.

Here's what I saw that goes beyond normal email marketing:

The SameSite=None flag isn't needed for unsubscribe processing. SameSite=Lax would be enough for the email-to-website process. The None flag allows the cookie to be sent with cross-site requests, which is what enables cross-site tracking.

With httpOnly set to false, JavaScript can read the cookie, which is a privacy and security risk. Setting httpOnly to true would block JavaScript access without affecting the cookie's marketing use.

The cookie is set for .rates.ca (the main domain), not just info.rates.ca. So if you visit www.rates.ca to compare mortgage rates, the Act-On tracking cookie is sent too, linking your website visit to your email subscriber identity.

Act-On's privacy policy(opens in a new tab) (as of February 2026) states they "will not utilize, sell, or rent your Customer Content." Whether they read the leaked first-party cookies is a policy question, not a technical one. The architecture permits access; the policy promises restraint. GDPR Article 25(opens in a new tab) favors architectural prevention of data leakage over policy promises.

What I Found

Rates.ca is a financial comparison site that uses a marketing platform. The CNAME cloaking setup is standard for Act-On customers and might have been set up automatically during onboarding. Act-On's system is described in academic research because it's common for marketing automation platforms, not because it's unusual.

This setup works without users knowing. CNAME cloaking gets around browser and extension privacy protections. The SameSite=None cookie enables cross-site tracking, and the httpOnly=false flag allows JavaScript to read the cookie. Each of these is a configuration choice, but none were explained to the person clicking "unsubscribe."

Cookie consent tools are bypassed in three ways: timing (the cookie is set before you can give consent), classification (CNAME cloaking tricks consent tools), and medium (data in the URL is sent before any page loads).

Brave detected the CNAME cloaking before any data was sent. Chrome and Edge didn't show any warning. Safari shortened the cookie's lifespan but didn't warn the user. Firefox's DNS API lets extensions detect CNAME cloaking, but Chrome's extension sandbox does not. Network-level tools like Pi-hole and NextDNS can catch it for every device on your network.