A custom tracking domain for cold email is the infrastructure fix almost nobody sets up, because the default works silently against you. Turn on click tracking in any sending tool and your links get rewritten through a tracking domain that tool owns and every customer shares, which means your inbox placement is partly decided by the worst spammer on the same platform. The fix is one CNAME record, about 15 minutes of work, and this guide walks through it generically so it applies to whatever tool you send from.
We have set this up more times than we can count. Our parent agency, Referral Program Pros, has run more than 4,000 outbound campaigns and booked over 7,000 meetings, and GTM Bud is built on that agency’s playbook, down to a guarantee of 5 percent positive replies on LinkedIn or 1.5 percent on email, with a full refund if a campaign misses it. You do not underwrite reply rates while letting a shared domain you have never audited ride inside every message.
One boundary note so this article stays scoped. Whether you should track opens at all is settled in our verdict on open tracking in cold email, and it is a no. How many links belong in a cold email, and why shorteners are poison, is covered in our guide to whether links in cold emails hurt deliverability. This piece owns the layer underneath both: the tracking domain itself, why the shared default is a liability, and how to replace it.
What is a custom tracking domain?
A custom tracking domain is a subdomain you own, such as track.yourdomain.com, that handles the open and click tracking for your cold email instead of the shared domain your sending tool provides by default. When a tool tracks a click, it rewrites each link in your email to point at a tracking server first, logs the click, then redirects the reader to the real destination. By default, that rewritten link points at a domain the tool owns and every customer shares. With a custom tracking domain, you publish one CNAME record that points your subdomain at the tool’s tracking server, and from then on the rewritten links carry your domain instead. The tracking mechanics do not change at all. What changes is whose reputation the link carries: yours, built by your sending behavior alone, rather than a pooled reputation built by every stranger on the same platform.
That pooled reputation is the entire problem, so it deserves its own section.
Why does the shared default tracking domain drag placement down?
The shared default tracking domain hurts you through two mechanisms: inherited reputation and domain mismatch. Inherited reputation first. A shared tracking domain appears in the mail of thousands of senders at once, and spam filters score the domains inside a message body, not just the domain that sent it. When other customers of your tool run sloppy campaigns, complaints and spam-folder placements accumulate against the shared domain, and your clean campaigns carry that same domain in every rewritten link. Instantly, itself a cold email platform, concedes this openly in its deliverability guidance: shared tracking domains tie your sender reputation to every other customer using the same infrastructure, so one bad actor on the platform can drag your campaigns into spam with them. Saleshandy’s help documentation says the same thing about its own shared domain: many senders use it, so there is always a chance your reputation gets affected, while a custom domain is associated solely with your sending practices.
The second mechanism is mismatch. Your message is sent from and authenticated for your domain, but the links inside it point somewhere unrelated. MailReach’s guide to custom tracking domains describes the consequence directly: sending from your domain while tracking through a shared domain breaks that alignment, and inbox providers treat the mismatch as a spam signal. Google’s sender guidelines set the expectation filters enforce: links should be visible and easy to understand, and recipients should know what to expect when they click. A link whose visible text implies your company but whose underlying domain belongs to a sending platform is precisely the shape those systems are built to distrust.
The failure mode has a worst case with a name: the blocklist. Spamhaus documents that its Domain Blocklist is used during content inspection to look up domains appearing in mail headers and bodies, including URLs, and that receiving servers can reject mail outright when the message body contains a URL on the list. Read that against the shared-domain math: if a tracker domain used by thousands of senders gets listed because of behavior you had nothing to do with, every email carrying that domain inherits the rejection. GMass, another cold email vendor, takes the threat seriously enough that its tracking-domain guide describes monitoring URIBL, SURBL, and the Spamhaus DBL for tracking domain listings. Hunter’s help documentation states the defensive logic in one line: a custom tracking domain lowers the risk of getting blocklisted by separating your mail from other users of the same tool.
Here is the whole comparison in one place:
| Dimension | Shared default tracking domain | Custom tracking domain |
|---|---|---|
| Reputation owner | Every customer of the tool, pooled | You alone |
| Worst-case exposure | A stranger’s spam gets the domain filtered or listed | Only your own behavior can damage it |
| Domain alignment | Link domain unrelated to sending domain | Link domain is a subdomain of your sending domain |
| Blocklist blast radius | One listing hits thousands of senders at once | A listing affects only you, and you control the fix |
| What the recipient sees | A vendor’s domain behind your links | Your own domain, consistent with the sender |
| Setup cost | None | One CNAME record, about 15 minutes |
Custom tracking domain, or no tracking at all?
For most first-touch cold campaigns, the honest answer is neither domain: turn tracking off and send clean. Our position on opens is already on record in the open tracking verdict: the open rate is corrupted by automated pixel fires and now carries a consent problem in parts of Europe, so the pixel should be off regardless of which domain would host it. Clicks are only slightly better. A first touch should contain zero or one link, per the source consensus in our links and deliverability breakdown, which leaves click tracking very little to measure, and every tracked link adds a rewrite that filters scrutinize. The metric that decides campaigns is replies, and replies need no tracking domain at all.
So the decision tree is short:
| Your situation | What to do |
|---|---|
| First-touch cold email, reply as the call to action | No tracking, no links, no tracking domain needed |
| One link per email, no click data needed | Tracking off; the link goes out unrewritten and clean |
| You genuinely use click data for decisions | Custom tracking domain, never the shared default |
| Later-sequence or warm segments where clicks guide routing | Custom tracking domain, with SSL verified |
| Any volume of tracking on the shared default domain | Stop; that is the one configuration with no defensible case |
Notice the last row. Between tracking off and tracking through your own domain there are reasonable trade-offs: data versus scrutiny, measurement versus minimalism. Tracking through the shared default is different, because you take on all the scrutiny of rewritten links plus a reputation you cannot see, audit, or fix. If a campaign is worth tracking, it is worth the CNAME record. The one thing the tracking domain will never fix is bad copy: click data on a message nobody wants to click is just a well-measured zero, which is why we put more weight on reply-first drafting with an AI cold email writer grounded in real prospect research than on any tracking configuration.
How to set up a custom tracking domain in about 15 minutes
Setup is the same shape in every tool, because it is a DNS pattern, not a product feature. Across the campaigns our agency runs, the actual work is about 15 minutes per domain; the waiting is DNS propagation. If you have already published authentication records, this is easier than any step in our SPF, DKIM, and DMARC setup guide, and it happens in the same DNS panel.
Step 1: Pick a subdomain on your sending domain
Convention is a short, neutral prefix on the secondary domain you send from: track, link, or go. If you send from getacme.com, the tracking domain becomes track.getacme.com. Keep it on the sending domain, not your primary business domain, for the isolation reasons covered in our cold email deliverability guide.
Step 2: Find your tool’s tracking host
Every tool that supports custom tracking domains publishes a hostname to point at, usually in settings under a name like custom tracking domain or CNAME setup. It looks like a subdomain of the vendor, for example lemlist’s documented target is custom.lemlist.com.
Step 3: Add one CNAME record at your DNS host
In the DNS panel for the sending domain, create a CNAME with the subdomain as the host and the tool’s tracking host as the value:
Type: CNAME
Host: track
Value: open.tracker-tool.comWhich resolves to the record track.getacme.com CNAME open.tracker-tool.com. That is the entire DNS work: requests to your subdomain now land on the tool’s tracking server, which answers on your domain’s behalf.
Step 4: Wait for propagation, then verify in the tool
lemlist’s support documentation, citing Cloudflare, puts propagation at a few minutes to 48 hours, with most setups live within hours. Enter the subdomain in your tool’s settings and run its verification check rather than assuming. A second check that costs nothing: load the tracking subdomain in a browser; most tools serve a confirmation page when the record resolves correctly.
Step 5: Enable it and confirm the links
Switch the tool’s tracking over to the custom domain, send a test message to yourself, and hover the links. Every rewritten URL should now show your subdomain. While you are at it, run the message through the pre-send checks in our guide to testing email deliverability, because a tracking change is exactly the kind of infrastructure edit that warrants a fresh placement test.
The one step that trips people up is not DNS at all. It is SSL.
Do not skip SSL on the tracking domain
A tracking domain without a valid SSL certificate produces links that load over plain HTTP or throw a browser security warning, and both outcomes are worse than the problem you were fixing. The prospect who clicks a link and hits a certificate warning does not read your case study; they close the tab and remember the warning. Filters read the same signal. GMass’s guide to SSL for tracking domains argues that serving tracking links and pixels over HTTPS sends a positive trust signal to mailbox providers, and the industry has moved in that direction: Amazon SES added HTTPS support for open tracking on custom domains in September 2024, closing one of the last mainstream gaps.
Practically, SSL on a tracking domain is handled one of two ways. Most modern sending tools provision a certificate for your subdomain automatically once the CNAME verifies, which is why step 4 above matters: verification is usually what triggers issuance. Where the tool does not, the standard pattern is putting the subdomain behind a proxy such as Cloudflare that terminates SSL for you. Either way, the acceptance test is the same: load https plus your tracking subdomain in a browser and confirm it resolves without a warning. If it does not, keep tracking off until it does. An unencrypted tracking domain with your name on it is your problem in a way the shared domain never was, which is the price of owning the reputation.
Frequently asked questions about custom tracking domains for cold email
Does a custom tracking domain replace SPF, DKIM, and DMARC?
No. SPF, DKIM, and DMARC authenticate the domain sending the message, while a tracking domain only changes which domain appears inside the rewritten links. They are separate layers and both get evaluated. A custom tracking domain on top of broken authentication fixes the smaller problem while leaving the bigger one, so work through our SPF, DKIM, and DMARC setup for cold email first, then add the tracking domain.
Can one custom tracking domain cover multiple sending domains?
Most tools allow it, but the safer pattern is one tracking subdomain per sending domain. The argument for a custom tracking domain is that the link domain matches the sending domain, and pointing links at a subdomain of a different domain reintroduces a mismatch, just one you happen to own. It also re-couples reputations across domains you deliberately separated. The CNAME takes minutes per domain, so repeat it per domain.
Should the tracking subdomain live on your primary domain or your sending domain?
On the secondary sending domain, never your primary business domain. Cold email should already run on secondary domains so reputation damage cannot touch the domain your client email depends on, and the tracking subdomain follows the same isolation logic. Putting it on your primary domain ties that domain to cold email link behavior, which is exactly the exposure the secondary-domain structure exists to prevent.
How long does a custom tracking domain take to start working?
The DNS edit takes minutes; propagation is the wait. lemlist’s support documentation, citing Cloudflare, puts DNS changes at a few minutes to 48 hours to propagate globally, with most setups live within a few hours. Add the CNAME, wait at least half an hour, then run your tool’s verification before enabling tracking on live sends, so no tracked mail goes out pointing at a subdomain that does not resolve yet.
Will a custom tracking domain make open tracking accurate again?
No. A custom tracking domain changes which domain hosts the pixel, not how the pixel gets triggered. Apple Mail Privacy Protection still fires it automatically whether or not a human reads the message, so open rates stay corrupted no matter whose domain serves the image. The tracking domain fixes a reputation problem, not a measurement problem. Disable open tracking on cold campaigns and judge them on replies.
Do you need a custom tracking domain if you send zero-link emails?
No. If your first touches carry no links and open tracking is off, nothing gets rewritten and no tracking domain appears in your mail, which is the cleanest deliverability position there is. Set one up anyway if you expect to track clicks later, since it costs minutes and removes the temptation to flip tracking on against a shared domain. If you would rather not own any of these calls, a done-for-you outbound service makes them per campaign as part of the engagement.
Own every domain your emails carry
The custom tracking domain question reduces to one principle: nothing in your cold email should carry a reputation you cannot see and did not earn. Your sending domain is yours, your authentication records are yours, and if links get rewritten at all, the domain doing the rewriting should be yours too. One CNAME record and an SSL check buy you out of the shared pool where a stranger’s spam becomes your placement problem. And where tracking buys you nothing, which is most first touches, the strongest configuration is no tracking at all and the reply as the only metric.
That is exactly how GTM Bud runs campaigns: plain-text sends judged on replies, tracking off by default, and infrastructure decisions like this one made once, correctly, at setup. Our cold email automation tool applies the same discipline behind the 7,000+ meetings our agency playbook has produced, with the same written guarantee of 1.5 percent positive replies on email or a full refund. Spend the 15 minutes on the CNAME if you track, or skip tracking and spend those minutes on a sharper first line. Either way, every domain in the message stays yours.