Answer First
Definition: A custom tracking domain for email is a subdomain you own — trk.yourbrand.com, say — that your email service provider (ESP) uses for click tracking instead of the shared hostname it controls. When click tracking is on, the platform rewrites each campaign link to pass through a tracking host that logs the click, then forwards the recipient to the real destination.
Why: The rewrite puts your campaign URL on a domain you don’t manage. Click behavior is recorded inside the platform and only visible in its dashboard; every link you send shares a hostname with thousands of other senders; and when you change ESPs, links that live on the old platform’s domain stop being yours to control, re-point, or retire. A branded subdomain keeps the hostname in your hands, so links, statistics, and the DNS entry that powers them survive platform changes.
Example: You send a sale announcement pointing at yoursite.com/sale. With click tracking on, the link in the recipient’s inbox becomes a rewritten URL on the platform’s tracking host — sendgrid.net (SendGrid), hubspotlinks.com (HubSpot), or klclick1.klaviyo.com (Klaviyo) — a domain the recipient doesn’t recognize. With a branded subdomain, that same link reads trk.yoursite.com/sale, records the click, and forwards to the same landing page. Same campaign, same destination — different owner of the link.
Key Facts
- Every ESP with click tracking rewrites the links in your emails; rewritten links point at the platform’s servers unless you brand a subdomain of your own — Twilio SendGrid’s docs state this directly.
- Link branding is DNS work: add a CNAME pointing your subdomain at the ESP’s tracking host, get it verified, and make sure a TLS certificate covers the subdomain before links go live.
- Spam filters and inbox providers inspect the links inside a message and weigh the reputation of the root domain behind them; branding keeps your click path off a domain you don’t control.
- DNS verification and propagation are not instant — platforms commonly allow up to 48 hours before a branded subdomain is confirmed.
- A hostname carries one CNAME and no other records at the same name; TTL decides how long resolvers cache the old value — both matter when you re-point.
- Click statistics are noisy by design: mail clients, link previews, security scanners, and crawlers request the URL without a human ever clicking.
- Switching ESPs is a re-point, not a rebuild: the subdomain is yours, so you redirect it to the new platform, verify status, and log the change.
Expert Explanation
How the rewrite works. HTTP redirects are what link tracking runs on. The rewritten URL responds with a 3xx status code and a Location header pointing to the final destination, and the browser follows it. RFC 9110, which defines HTTP semantics, specifies the redirect codes: 301 Moved Permanently signals the old URL is permanently replaced, while 302 Found is the temporary variant. Click-through tracking is, semantically, a temporary hop: the tracking URL must keep working for future sends, which is why platforms use a temporary redirect. MDN’s redirect guide is a useful reminder that every redirect costs an extra round trip — keep the chain you control minimal — and that permanent redirects are the tool for “the old URL is gone, use this one”: exactly the situation when a landing page changes and the entry needs a deliberate redirect choice.
Why the shared domain hurts. Three costs stack up. First, analytics lock-in: clicks are attributed and stored inside the platform, and exported data still references a hostname you don’t own. Second, shared reputation: the platform’s tracking domain is used by every sender on that platform, and link-level trust is judged partly by the root domain — you inherit a hostname whose reputation you can’t influence. SendGrid’s link branding docs make the trade-off explicit: filters and providers look at the links inside messages. Third, link rot at migration: when you leave, the old tracking domain keeps resolving, but it’s the ESP’s — links in archived campaigns and forwarded emails keep pointing at a platform you’ve left.
The fix is a branded subdomain. Point a subdomain of your root domain at the tracking infrastructure — or at a forwarding entry you manage — and the links in your email become yours. The provider still records click events for its own dashboards; what changes is the hostname, the reputation context, and the fact that the entry is now part of your infrastructure. Most teams miss the last point: the subdomain is not a checkbox you set once. It is a forwarding entry with a lifecycle — decide, verify, send, read the statistics, log the change, and eventually re-point or retire it.
Decision Framework
The first decision is how the subdomain forwards. The two common approaches:
| Consideration | CNAME to your ESP | Managed forwarding entry |
|---|---|---|
| What it is | DNS CNAME from your subdomain to the ESP’s tracking host; the ESP serves the redirect | A forwarding entry you own that responds with its own redirect to the destination |
| Who runs the redirect | The ESP | You (via Console or API) |
| Click attribution | Full ESP per-recipient click stats | Access statistics on the entry — counts and timing, not per-recipient ESP attribution |
| Setup effort | DNS record + platform verification | Create the entry, verify status and TLS |
| When you switch ESPs | Update the CNAME target, reverify | Re-point the entry’s destination, no DNS change |
| Choose when | You want ESP-native click analytics and trust the platform | You want one hostname whose behavior, stats, and history you control |
The rest is a lifecycle, and it should be run as one:
- Decide the model. CNAME-to-ESP if per-recipient click analytics matters; managed forwarding if control and portability matter more. Some platforms gate link branding behind higher service tiers, and all require you to control the domain’s DNS.
- Verify before you send. Confirm the DNS record, wait out propagation (up to 48 hours is normal), check that the TLS certificate covers the subdomain, and click a test link end to end — including a mobile client if that’s where your audience reads.
- Send, then read the stats with noise in mind. Expect prefetches, previews, and security scanners in the numbers. Before concluding a link underperforms, check the entry itself — a spike at send time with no conversions is often a scanner, not a customer.
- Log the change. Record what the entry pointed at, when, why, and by whom — the same evidence trail compliance audits look for when someone asks who changed the link and when.
- Re-point or decommission safely. When you switch ESPs, keep the hostname and change where it forwards, then verify the new path before the next send. If a destination changes mid-campaign, update the entry instead of rewriting the creative. When you retire a subdomain, remove the entry only after old links are dead or redirected — and at acquisition scale, follow a consolidation playbook instead of improvising. Keep the record of what you removed.
Key Takeaways
- Every major ESP rewrites your email links onto a tracking host it controls; a custom tracking domain for email gives you the hostname.
- The branded subdomain is a forwarding entry: decide CNAME-to-ESP vs. managed entry, verify status and SSL, send, read noisy stats, log changes, and re-point or retire it deliberately.
- Link reputation follows the root domain, so links behind your own subdomain are links you can actually influence.
- Treat an ESP switch as a re-point with verification, not a rebuild — the subdomain is the asset that travels with you.
FAQ
Q: Is a custom tracking domain for email required? A: No platform requires it to send. Default tracking works out of the box on a shared domain. If click-through attribution, link trust, or the ability to migrate cleanly matters to you, a branded subdomain is the standard setup — it costs a DNS record, a certificate that covers the subdomain, and verification time (up to 48 hours is common).
Q: CNAME to my ESP or a managed forwarding entry — which should I choose? A: If you need the ESP’s per-recipient click analytics, use its CNAME-based link branding — the platform records every click. If what you want is a branded link whose behavior, statistics, and history you control and can re-point without touching platform config, use a forwarding entry you manage. Many teams do both: CNAME for deep ESP analytics, a managed entry for stable branded links that outlive the current platform.
Q: Why do my click statistics show more clicks than real people? A: Because not all requests come from humans. Mail clients prefetch links, preview services fetch them, and security scanners and link-checking bots request URLs to inspect them. Treat raw counts as upper bounds; look at timing, user agents, and conversion patterns before judging a campaign.
Q: What happens to my tracking subdomain when I switch ESPs? A: Because the subdomain is yours, you keep it and change what it points to. For a CNAME, update the target and reverify with the new platform. For a managed entry, change the destination. Export or log what you need first — click history held inside the old platform may not come with you — and keep the change log as your record.
Sources
- Twilio SendGrid Docs — Tracking settings: documents that click tracking rewrites all links and that they can point at your branded domain. https://www.twilio.com/docs/sendgrid/ui/account-and-settings/tracking
- Twilio SendGrid Docs — How to set up link branding: CNAME records, TLS prerequisites, root-domain reputation, and up-to-48-hour DNS verification. https://www.twilio.com/docs/sendgrid/ui/account-and-settings/how-to-set-up-link-branding
- RFC 9110, HTTP Semantics (IETF): defines the 301/302 redirect status codes behind link forwarding. https://www.rfc-editor.org/rfc/rfc9110
- MDN Web Docs — Redirections in HTTP: permanent vs. temporary redirects, round-trip cost, and domain-change use cases. https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirections
- Cloudflare Docs — DNS record types: CNAME behavior and TTL caching relevant to re-pointing. https://developers.cloudflare.com/dns/manage-dns-records/reference/dns-record-types/