A custom tracking domain is a subdomain you own, typically link.yoursendingdomain.com, published as a CNAME pointing at your vendor’s target. It replaces the shared hostname that would otherwise appear in every tracked link you send. Setup is one DNS record and a verification click.
Published by emailcampaign.ai, which provisions sending domains and writes their DNS. We have a commercial interest, so the recommendation at the end of this page argues against a feature we could equally have sold you.
What the shared default actually does
When tracking is on and you have not set a custom domain, every link in your email is rewritten to something like track.vendor.com/abc123, and the open pixel loads from the same place. That hostname is shared with every other customer on that platform.
Two consequences follow. First, the visible link in your message no longer matches your sending domain, which reads as a mismatch to both filters and recipients who hover. Second, and more seriously, if that shared hostname lands on a domain blocklist such as SURBL because of what somebody else sent, every message containing one of those links carries a listed domain in its body. Filters weight that heavily, and you have no control over it and no visibility into it.
The setup, in full
The DNS side is a single record:
| Type | Host | Value | Proxy / TTL |
|---|---|---|---|
| CNAME | link (or track, go, em) | the target your vendor gives you | DNS only, never proxied. TTL auto |
Then enter link.yoursendingdomain.com in the tool and let it verify. Propagation is usually minutes, occasionally an hour.
Four things go wrong often enough to list:
- Using the root domain. A CNAME cannot coexist with other records at the apex, and pointing your root at a tracking host will break your website and often your mail.
- Reusing the mail hostname. Do not use the same subdomain as your MX or your mail server. Keep tracking on its own name.
- Proxying it. If your DNS is behind a CDN proxy, turn the proxy off for this record. Proxying changes what the vendor sees and breaks verification.
- Leaving it on http. If the vendor issues a certificate for your subdomain, make sure links are https. A browser warning on your own tracked link is worse than no tracking.
Use a subdomain of the sending domain
The tracking domain should be a subdomain of whichever domain is in your From address for that campaign. That keeps the link visually consistent with the sender, which is what a recipient checks when they hover.
It should not be a subdomain of your main company domain. Cold outreach runs on separate registered domains precisely so that a reputation problem stays contained, and hanging a tracking hostname off your corporate domain reconnects the two.
The uncomfortable recommendation
Setting up a custom tracking domain is the right move if you are going to track. The better question is whether to track at all, and for cold email the honest answer is often no.
Open tracking adds a remote image to every message. A one by one pixel loading from an external host is a pattern filters have scored for twenty years. On a cold domain with no sending history, that is a cost you pay on every send.
The numbers it produces are not real. Apple Mail Privacy Protection has pre-loaded images on behalf of recipients since 2021, registering opens that never happened. A meaningful share of any B2B list is on Apple Mail. Judging campaigns on open rate now means judging them partly on Apple’s proxy fetches.
Link tracking rewrites your URLs. A recipient who hovers sees a redirect hostname rather than the destination, which is exactly what phishing looks like. A custom domain makes that less jarring but does not remove it.
The setup that consistently performs best on cold outbound is: open tracking off, link tracking off or limited to a single link, and campaigns measured on replies and meetings. If you need attribution, a UTM parameter on a plain unrewritten link gives you the analytics without the redirect or the pixel.
When tracking earns its place
Tracking is worth the cost on warm and opted-in traffic, where the domain has history, recipients expect the mail, and the open number is one input among many. The argument above is specific to cold outbound from young domains, where the signal you are buying is small and the risk you are taking is not.
Questions, answered straight
- What is a custom tracking domain?
- It is a hostname you own, usually something like link.yourdomain.com, that your sending tool uses to rewrite tracked links and the open pixel. Without one, those links point at a hostname shared by every customer of that vendor, so you inherit the reputation of everyone else using it.
- How do I set up a custom tracking domain?
- Publish a CNAME for a subdomain you choose, pointing at the target your vendor gives you, then enter that subdomain in the tool and wait for it to verify. It is a single DNS record. The mistakes are using your root domain, using the same subdomain as your mail host, or leaving it on http when the vendor supports https.
- Does a custom tracking domain improve deliverability?
- It removes a specific risk rather than improving anything by itself. A shared tracking domain can appear on domain blocklists such as SURBL because of what other customers send, and a link to a listed domain is a strong filtering signal. Your own tracking domain isolates you from that.
- Should I use a subdomain of my sending domain or a separate domain?
- A subdomain of the sending domain is the normal choice and keeps the link visually consistent with the sender. Use a different registered domain only if you are deliberately separating reputations. Never use your main company domain for cold outreach tracking.
- Is it better to turn open tracking off entirely?
- For cold email, frequently yes. Open tracking adds a remote image to every message, which is a classic spam signal, and since Apple Mail Privacy Protection began pre-loading images in 2021 the open numbers are not reliable anyway. Many teams get better placement by tracking nothing and measuring replies.
Published 20 September 2026. Updated 20 September 2026. Written by the team that runs the infrastructure; numbers come from the platform's own provisioning and sending, and from the providers' published documentation at the time of writing.