Custom Tracking Domain: Definition, How It Is Measured, and Where It Breaks
A custom tracking domain is a hostname on a domain you own, pointed by CNAME at your sending platform, which hosts the click and open tracking inside your messages instead of the platform's shared tracking domain. It removes shared-domain blocklist exposure and starts with no reputation of its own.
Key takeaways
- Click tracking rewrites every URL in the body into a link to the tracking host, so the domain in your links is the one filters and URL blocklists actually read.
- A custom tracking domain buys isolation immediately and trust only with time, because a brand-new redirect host is unfamiliar to every filter that scores it.
- Google's sender guidelines state that Google does not track open rates and cannot verify open rates reported by third parties, so the pixel measures the recipient's mail client.
- Running no tracking at all is a coherent position: no redirect host to be listed, no remote image request, and the numbers you keep are sends, replies and meetings.
Custom Tracking Domain: Definition, How It Is Measured, and Where It Breaks
A custom tracking domain is a domain you control, pointed at your sending platform, used to host the click and open tracking inside your emails instead of the platform's shared tracking domain. Every tracked link in the body and every tracking pixel resolves through it, so the redirect infrastructure your messages depend on carries your name rather than a name shared with every other customer of the platform.
It is one DNS record and about ten minutes of work, which is part of why it is recommended so uniformly and examined so rarely.
What the setup actually does
You pick a hostname on a domain you own, typically a subdomain such as link.yourdomain.com or go.yourdomain.com. You publish a CNAME record pointing that hostname at whatever host your sending platform tells you to use. The platform then issues certificates for it and starts writing that hostname into the messages it sends for you.
The CNAME shape is doing more work than it looks. A CNAME hands resolution of that hostname to the platform, so the platform can move the underlying servers, change addresses and issue or renew a TLS certificate for your hostname without you touching DNS again. An A record pointing at an address you copied out of a setup page does none of that, and breaks silently the next time the platform reorganises its infrastructure. It also means the hostname is delegated: the content served at a name on your domain is chosen entirely by somebody else, which is fine and is the arrangement you asked for, and is worth being conscious of.
The part worth understanding is what tracking does to the body of a message, because it is more invasive than the phrase "add tracking" suggests.
A tracked link is no longer a link to the destination. When click tracking is on, the platform rewrites every URL in your body. What ships is a link to the tracking domain carrying an encoded identifier, and the destination is stored on the platform's side. A recipient who clicks lands on the tracking host first, which records the click and issues a redirect to the real page. Hovering over the link in a mail client shows the tracking host, not your website.
An open is measured with a remote image. A tracking pixel is a tiny image hosted on the tracking domain with a unique identifier per recipient. If the recipient's mail client loads remote images, the request reaches the tracking host and is recorded as an open. If it does not load them, nothing is recorded, and the message is counted as unopened whether it was read or not.
- Step 1You publish a CNAME
A hostname on your own domain points at the host your sending platform specifies.
- Step 2The platform rewrites the body
Every URL becomes a link to that hostname carrying an encoded identifier, and a pixel referencing it is added.
- Step 3The recipient's client resolves it
A loaded image, or a click, becomes an HTTP request to your hostname rather than to the platform's shared one.
- Step 4The platform records and redirects
The event is written against the recipient, then the browser is sent on to the real destination.
- Step 5Filters see your hostname
Anything a receiving system decides about the domains in your links now attaches to a name only you use.
The case for doing this is real and it is a case about isolation. A shared tracking domain is used by everyone on that platform, including senders whose lists and copy you would not want to be associated with. Domains that appear in the body of large volumes of unwanted mail get listed by URL blocklists, and a URL blocklist listing follows the link, not the sender. So a domain you have never heard of, hosting redirects for a campaign you had nothing to do with, can degrade the placement of your messages because your messages contain a link to it. Moving to a hostname nobody else uses removes that particular exposure completely. It is worth being clear about which exposure that is, because URL reputation and sender reputation are separate systems that people merge into one. Sender reputation is built from what your sending domain and its addresses do. URL reputation is built from where the links inside messages point, is evaluated by different services, and travels with the link even when the message is forwarded or pasted somewhere else entirely. A sending domain in perfect health can have its messages filtered because of a redirect host it shares with strangers, and no amount of authentication work on the sending side addresses that. If you are already dealing with a listing, the check and delisting process is the operational side of this and is not restated here.
Where the recommendation breaks
Setting one up trades a known problem for an unknown one, and almost nothing written about custom tracking domains says so.
A brand-new tracking hostname carries no reputation at all. The links in your body now point at a domain no filter has ever seen, no reputation service has scored, and no browser safe-browsing list has an opinion about. Some filtering systems weight an unknown redirect host worse than a well-known shared one with mixed history, because an unfamiliar domain used for redirection is a shape that phishing uses constantly, and a domain registered recently is one of the oldest heuristics in the field.
So the gain is a gain in isolation rather than a gain in trust, and only becomes a gain in trust with time and volume behind it. That distinction changes the advice. Standing a custom tracking domain up on the day you launch, on a domain registered the same week, is the worst version of the trade: you have given up whatever residual familiarity the shared host had and replaced it with something that looks new to everyone. The same domain a year later, having redirected steady traffic that nobody complained about, is straightforwardly better than the shared host. The recommendation is right about the destination and quiet about the journey.
- Reputation is pooled with every other sender on the platform
- A listing earned by somebody else reaches your messages
- Some familiarity with filters, of mixed quality
- Nothing to warm and nothing to maintain
- Nobody else can damage it
- Starts unknown to every filter and scoring service
- Reads as an unfamiliar redirect host until it has history
- Needs the same care as any other domain you own
- No redirect host to be listed anywhere
- No remote image request in the message
- Links point where they appear to point
- Open and click numbers stop existing
The second break: you are measuring something the receiver disowns
Half of what a tracking domain carries is open tracking, and open tracking is the weaker half by a distance.
Google's sender guidelines state it flatly: "Google doesn't track open rates. Google can't verify the accuracy of open rates reported by third parties." That is the largest receiving surface in B2B saying that the number is not one it produces, does not audit, and does not use.
The mechanism explains why. An open is inferred from a remote image request, so anything that changes image loading changes the number without changing reader behaviour at all. A client that blocks remote images by default suppresses opens on messages that were read. A privacy proxy that pre-fetches images on the recipient's behalf manufactures opens on messages nobody looked at. A security appliance that scans links and images before delivery can register both an open and a click for a person who never saw the message. None of that is measurement error in the ordinary sense, because there is no true value being approximated: the pixel measures image loading, and image loading is a property of the recipient's software.
The pixel is also not free on the deliverability side. A remote image request in a message is itself a signal filters look at, and a message that contains one invisible image and several rewritten redirect links has a shape that spam classification has been trained on for two decades. Click tracking is on firmer ground, because a click is an intentional act by a person, and click rate benchmarks are worth something as a result. Open tracking is measuring the recipient's mail client. What open rate benchmarks can honestly be used for is comparison against your own history on unchanged infrastructure, and very little else.
The version nobody proposes: no tracking
There is a third position, and it deserves to be stated as a real option rather than as an ascetic gesture.
A message with no tracked links has no tracking domain to be blocklisted and no rewritten URLs to look like redirection. A message with no pixel makes no remote image request. Every link points exactly where it appears to point, which is the arrangement least likely to be penalised by anything and the one a technically literate recipient is least likely to notice. For a cold programme whose messages carry one link or none at all, the entire tracking apparatus is being maintained to measure very little.
The cost is honest and worth stating plainly. You lose click data, so you lose the ability to tell whether copy that gets replies also gets people onto a page, and you lose open data, which was measuring the recipient's software anyway. You keep the numbers that survive all of this: sends, delivery failures, replies, and meetings booked. Those are also the numbers a programme is actually judged on, which is the argument for the position rather than a consolation for it.
The reasonable middle is to decide what a click would change. If a click rate would alter what you send next, track clicks on a hostname you own and give it time to acquire history. If it would not, the tracking domain is infrastructure carrying risk in exchange for a metric nobody acts on. Open tracking is a separate decision from click tracking in most platforms, and turning it off while keeping clicks removes the pixel, removes the disowned metric, and keeps the measurement that reflects a human decision.
How it shows up in a live programme
Two failure modes account for most of the trouble people have with this.
The first is a tracking domain published as a CNAME and then quietly broken: the platform's target host changes, the certificate lapses, or the DNS record is edited during unrelated work. What ships is a body full of links to a hostname that no longer resolves or throws a certificate warning, which is worse than either the shared host or no tracking, and which nothing in a campaign dashboard reports because the platform still records the send. Loading one of your own tracked links in a browser after any DNS change is a cheap habit.
The second is scale. A tracking hostname shared across many sending domains ties them together in the eyes of anything reading URLs, so a domain-level containment strategy can be undone by a single link host common to all of them. That is a design decision to make deliberately rather than to discover.
Volume discipline sits underneath all of it. One message per campaign, sent once on one premise, is a smaller footprint for any URL host to defend than a programme that returns to the same inbox repeatedly, and a later approach to the same person is a separate campaign with its own premise. The broader diagnostic order, when placement is the problem rather than the metric, is in the cold email deliverability guide, and the receiver-side numbers Google does publish and stand behind are read in Google Postmaster Tools for cold email.
For teams who would rather not adjudicate tracking tradeoffs at all, our pay-per-qualified-meeting outbound makes them our problem and leaves you the meetings.
Verified as of August 2026. Verify current terms with the vendor before relying on them.
Frequently asked questions.
Frequently asked questions- Do I need a custom tracking domain for cold email?
- You need one if you are tracking clicks at all, because the shared alternative pools your link reputation with every other sender on the platform. The prior question is whether the click data changes anything you do. If it does not, turning tracking off removes the redirect host and the pixel and costs you nothing you were acting on.
- Can a custom tracking domain hurt deliverability?
- Early on, yes. A newly published tracking hostname is unknown to every filter and scoring service, and an unfamiliar redirect host on a recently registered domain matches a shape that phishing uses heavily. The exposure fades as the hostname accumulates steady, uncomplained-about traffic, which is an argument for standing it up before launch rather than during.
- Should the tracking domain match my sending domain?
- It should be a domain you control and it is normally a subdomain of one you already send from. Sharing one tracking hostname across many sending domains ties them together for anything that reads URLs, which quietly undoes a containment strategy built on separate sending domains. Decide that deliberately rather than inheriting it from a setup guide.
- Why are my open rates unreliable?
- Because an open is inferred from a remote image loading. Clients that block images suppress opens on messages that were read, privacy proxies that pre-fetch images create opens nobody made, and security appliances that scan messages can register both an open and a click. Google's sender guidelines say plainly that Google does not track open rates.