Custom Tracking Domain Setup (CNAME) for Cold Email

You can do everything else right. Clean list, passing authentication, a warmed domain, and still watch placement sag for one reason nobody flags during setup: the links in your email resolve to a tracking domain you share with thousands of strangers, and some of them are spammers.

That shared domain is the default. When you connect a mailbox to a cold email tool and turn on open or click tracking, the tool rewrites your links to run through its own redirect host first. Every customer on that platform uses the same one. When a filter judges the reputation of the domains in your message body, it judges that shared host, not just your sending domain. Custom tracking domain setup is how you take that reputation back. This guide covers what the tracking domain actually does, why the shared default is a liability, and the exact CNAME steps to point a branded one at your own domain.

Key Takeaways

• A tracking domain is the redirect host your open pixel and click links route through. By default it's shared across an entire platform's user base.
• Spam filters inspect the domains inside your email body, not just the sending domain. A listed shared tracking host can drag down a clean sender.
• Custom tracking domain setup is one CNAME record pointing a branded subdomain at your ESP's tracking server, plus HTTPS so links don't throw browser warnings.
• Open tracking is increasingly unreliable thanks to Apple Mail Privacy Protection, but click reputation and brand consistency still make a custom domain worth the five minutes.

What a custom tracking domain actually is

Before you fix the shared domain, it helps to know exactly what your tracking host does. Two mechanisms run on it: open tracking and click tracking.

Open tracking works with a pixel. Your sending tool inserts a tiny transparent image, a 1x1 GIF, into the email body with a unique filename per message. When the recipient's mail client loads that image, the request hits the tracking server, and the tool records an open. Amazon's SES documentation describes the mechanism plainly: it "adds a 1 pixel by 1 pixel transparent GIF image in each email" and "when the image is downloaded, SES can tell exactly which message was opened and by whom."

Click tracking works by rewriting links. Instead of putting your real destination URL in the email, the tool swaps in a link that points at its tracking server. When the recipient clicks, the request lands on that server, the click gets logged, and the server immediately redirects the browser to the page you actually linked to. Again from SES: it "replaces the links in your emails with links to a server operated by SES. This immediately redirects the recipient to his or her intended destination."

Both of those mechanisms need a domain to host them. That domain is your tracking domain. By default it belongs to your sending platform, so your links look something like track.youresp.io/abc123 instead of anything connected to you. A custom tracking domain swaps that host for a subdomain you control, like email.yourdomain.com, so the redirect and pixel resolve under your name. SES frames the upside as cohesion: you can "use your own domains, rather than domains owned and operated by SES, to create a more cohesive experience for your recipients, meaning all SES indicators are removed."

One thing it is not: an authentication record. A tracking domain is a plain HTTP redirect host. It needs no SPF, no DKIM, no DMARC alignment, because it never sends mail. If you're still setting those up, that's a separate job covered in our SPF, DKIM, and DMARC guide. The tracking domain sits next to authentication, not inside it.

Why shared tracking domains hurt deliverability

Here's the part setup wizards skip. A spam filter doesn't only evaluate who sent the message. It evaluates the domains it finds inside the message, including the domains your links point to. If those links route through a shared tracking host that other people have abused, you inherit their problem.

The clearest example is Spamhaus, whose Domain Blocklist (DBL) is "a list of domain names with poor reputation." Spamhaus is explicit that the DBL is checked during content inspection "by looking up domains appearing in the mail headers and body e.g., URLs or contact email addresses." So a domain that appears purely as a link in your body, your tracking host, can be the thing that gets the message filtered, even when your sending domain is clean.

Now stack on how the DBL lists. It lists at the registered-domain level, and the listing covers every hostname and subdomain underneath it. On a shared platform, your tracking links usually sit on a subdomain of the platform's root domain. If enough bad actors on that platform get the root listed, the listing cascades to your subdomain too, through no fault of your own. With a custom tracking domain, only your domain's reputation is in play.

Gmail applies similar logic from the receiving side. Its advanced protection "can identify links behind shortened URLs," "scan linked images for malicious content," and "show a warning when you click a link to untrusted domains." A tracking redirect is, functionally, a link behind another link, exactly the kind of indirection these checks scrutinize. A tracking host with a thin or poor reputation gives Gmail one more reason to hesitate.

This is the same shared-neighborhood risk that drives the subdomain versus root domain decision, and the same tradeoff you weigh when choosing a dedicated IP over a shared pool: you want reputation that's isolated and yours. A shared tracking domain is the opposite. It pools your fate with everyone else on the platform, including the senders torching their lists this week. That's the short answer to why shared tracking domains hurt deliverability: their reputation is a shared liability you can't control or repair.

How much does this actually cost you in placement? Honestly, it varies. On a healthy platform with good abuse controls, the shared domain might be fine for months. On a crowded one, it can be the difference between primary and spam. The point isn't that a shared domain always burns you. It's that you're holding a risk you don't need to hold, for the price of one DNS record.

Custom tracking domain setup: the CNAME steps

The whole job is one CNAME record plus a toggle in your sending tool. The exact target depends on your platform, but the shape is identical everywhere.

1. Pick a subdomain. Choose something short and on-brand, like email.yourdomain.com, links.yourdomain.com, or go.yourdomain.com. Use a subdomain of the same root brand your links already reference so the redirect looks native to recipients. SES recommends the subdomain be "specifically dedicated to handling these links."

1. Get the CNAME target from your tool. In your outreach platform's tracking settings, it will give you a hostname to point at, the address of its tracking server. This is the open and click tracking CNAME record's destination.

1. Add the CNAME at your DNS provider. In the DNS zone for your domain (Cloudflare, GoDaddy, Namecheap, Route 53, wherever you manage records), create a CNAME with the host set to your chosen subdomain and the value set to the platform's target. SES describes this step as adding "a new CNAME record to your subdomain's DNS settings that redirects requests to the SES tracking domain."

1. Wait for propagation, then verify in the tool. DNS changes can take anywhere from a few minutes to a few hours. Once the record resolves, flip the switch in your platform that enables the custom tracking domain. Most tools run an automatic check and confirm it's live.

A clean CNAME looks like this:

That's the entire mechanical setup. The nuance is in two choices: which subdomain you use, and whether the links run over HTTPS. The next two sections handle both.

Choosing the branded link domain for email

Three small decisions about the subdomain are worth getting right, because changing them later means rewriting links across live campaigns.

Use a subdomain, not your root. Point email.yourdomain.com at the tracking host, not yourdomain.com itself. A subdomain keeps tracking on its own DNS label, easy to change or retire without touching anything else, and it reads as a normal branded link domain for email rather than your bare domain doing something unexpected.

Match the brand, but it doesn't have to match the sending domain exactly. If you send cold email from a separate outreach domain (a common pattern for protecting your primary brand), your tracking subdomain should live on that same outreach domain so the links feel consistent with the From address. There's no authentication requirement forcing them to align, since the tracking domain sends no mail, but visual consistency matters to a recipient deciding whether a link is safe to click.

Keep it dedicated. Don't reuse a subdomain that already serves a website or app for tracking redirects. Give tracking its own label so its reputation, and any future change, stays cleanly separated. This is the same isolation logic our cold email infrastructure guide applies to mailboxes and domains, extended to the tracking layer.

One more honest note: a custom tracking domain is new. It starts with no reputation rather than a bad one, which is a strict improvement over a listed shared host but still means filters have nothing positive on file yet. It earns trust the same way your sending domain does, through consistent, low-complaint sending over time.

HTTPS and SSL: don't ship an HTTP tracking domain

This is the step most rushed setups skip, and it bites. If your tracking domain serves links over plain HTTP while your actual destination URLs use HTTPS, recipients can get a browser security warning when they click. SES is direct about it: with an HTTP custom domain, "if you send an email that contains links that use the HTTPS protocol, your customers may see a warning message when they click the links." A scary warning on a cold email link is conversion poison.

So your tracking domain needs a valid SSL certificate. How you get one depends on your tool:

• Most modern outreach platforms provision the certificate for you. Once your CNAME resolves, they automatically issue and renew an SSL certificate for the subdomain. You do nothing beyond adding the record. This is the common case, and it's why the whole job feels like one step.
• Raw infrastructure (like SES directly) makes you do it. There, an HTTPS tracking domain means putting a CDN in front of the tracking server and uploading a certificate. SES spells out the path: configure a CDN such as CloudFront pointing at the regional tracking origin, then "acquire an SSL certificate from a trusted Certificate Authority" that covers both your subdomain and the CDN, and upload it.

Either way, confirm the links actually load over HTTPS before you trust them. The simplest check is to send yourself a tracked email and click a link. If the address bar shows your branded subdomain with a valid padlock and no warning, you're done. SES even documents a one-line check, curl --head https://yourdomain.example/favicon.ico, that should return a clean 200 OK with HTTPS headers.

Is a custom tracking domain worth the trouble?

Short answer: yes, but for narrower reasons than the setup guides imply. The honest case rests on click reputation and brand consistency, not on open-rate accuracy, because open tracking is half-broken now anyway.

Apple's Mail Privacy Protection (MPP) is the reason. When it's on, Apple Mail "downloads remote content in the background by default, regardless of whether you engage with the email," and routes that content "through two separate relays operated by different entities" so the sender never sees a real IP or open event. In plain terms: Apple loads your tracking pixel for every Apple Mail recipient whether they opened the message or not. For a list with heavy Apple usage, your open rate can read close to 100% and mean almost nothing. We get into what that does to your numbers in the cold email metrics guide.

So if open tracking is unreliable, why bother with a custom domain at all? Three reasons that survive MPP:

1. Click reputation is real and it's yours. Clicks require an actual human action, which Apple's proxy can't fake. The domain those clicks route through is judged by filters on every send. Keeping it clean and under your control is the core deliverability win.
2. Brand consistency. Recipients see your subdomain on hover, not a stranger's tracking host. On a cold email, where trust is already thin, a link that matches the sender is one less reason to hesitate.
3. You stop sharing risk. Even if you turned off open tracking entirely, click tracking still rewrites links, and those still need a host. Better yours than a shared one.

If you don't need any tracking, there's a cleaner option: turn it off. No pixel, no link rewriting, no tracking domain, and your links point straight at their real destinations, which some senders argue is the most deliverability-safe choice of all. That's a legitimate stance. But if you're going to track clicks (and most outreach operators want to), do it on a domain you own.

How to verify your setup is working

Don't assume a green checkmark in the tool means everything's correct. Run three quick checks.

• DNS resolves. Look up the CNAME with dig email.yourdomain.com CNAME or any online DNS checker. It should return your platform's tracking target, not an error.
• Links rewrite to your domain. Send a tracked test email to yourself and hover over a link. The URL should show your branded subdomain, not the platform default.
• HTTPS is clean. Click that link. You should land on the real destination with no certificate warning and a valid padlock on the redirect.

If all three pass, your custom tracking domain setup is live and your link reputation is now isolated from the shared pool. From there, the tracking domain becomes one more thing to watch on your reputation dashboard. Folding it into ongoing domain health monitoring means you'll catch a problem with the tracking host the same way you'd catch one with the sending domain.

Common mistakes to avoid

A few errors show up again and again:

• Leaving the shared domain in place. The most common one. The tool defaults to its shared host, the setup screen is optional, and people skip it. Treat the custom domain as part of standard infrastructure, not an extra.
• Shipping HTTP-only links. Skipping the SSL step produces clickable links that trigger browser warnings. Always confirm HTTPS resolves.
• Reusing a busy subdomain. Pointing your main website's subdomain at a tracking host muddies reputation and complicates future changes. Dedicate a fresh label.
• Treating it like an auth record. A tracking domain needs no SPF, DKIM, or DMARC. Adding those does nothing useful here. Keep the authentication work where it belongs, on the sending domain.
• Trusting open rates after setup. A custom domain doesn't fix Apple MPP. Judge campaigns on replies and clicks, and link reputation, not on inflated open percentages. The broader case for de-emphasizing opens lives in our guide to avoiding spam filters.

Common questions about custom tracking domains

Do I need a custom tracking domain if I only track clicks?

Yes, arguably more so. Click tracking is the part that rewrites links and routes them through a redirect host, and that host's reputation is evaluated by filters on every send. If you track clicks at all, those links should run through a domain you control rather than a shared one. Open tracking is the part Apple MPP has made unreliable.

Does a custom tracking domain need SPF, DKIM, or DMARC?

No. A tracking domain is a plain HTTP redirect host. It never sends email, so email authentication records don't apply to it. Set up SPF, DKIM, and DMARC on your actual sending domain, which is covered in our authentication guide, and leave the tracking subdomain to its single CNAME.

Should the tracking domain match my sending domain?

It should share the same root brand for visual consistency, so a recipient sees a link that matches your From address. It does not have to be identical, and there's no authentication rule forcing alignment. If you send cold email from a separate outreach domain, put the tracking subdomain on that same outreach domain.

Will a custom tracking domain fix my deliverability?

It removes one specific risk: inheriting a shared tracking host's poor or blocklisted reputation. That's real, but it's one factor among many. If your list is dirty, your authentication is broken, or your domain is already burned, the tracking domain won't save you. Work the full deliverability audit and treat the tracking domain as one line on the checklist.

How long does setup take to go live?

The DNS record itself takes seconds to add. Propagation usually completes within minutes to a few hours depending on your provider's TTL. SSL provisioning, if your tool handles it automatically, typically finishes shortly after the CNAME resolves. Plan for it to be fully live the same day.

The bottom line

A custom tracking domain is the cheapest deliverability fix you'll ever make. One CNAME record pointing a branded subdomain at your ESP's tracking server, HTTPS confirmed, and your open pixel and click links stop resolving to a host you share with every spammer on the platform.

The setup takes five minutes. The reason it matters takes a sentence: spam filters judge the domains inside your email, not just the one in your From line, and a shared tracking host you can't control is a borrowed liability. Take it back. Then point your attention at the things that move the needle more, list quality, authentication, and a sending domain you've warmed and watch.

MailBeast supports custom tracking domains alongside warmup and reputation monitoring, so the tracking layer, the sending layer, and the watching layer all live in one place. Set the CNAME once, verify HTTPS, and forget about it. That's exactly how infrastructure should behave.

Sources

• AWS, Configuring custom domains to handle open and click tracking
• Spamhaus, Domain Blocklist (DBL)
• Google, Advanced phishing and malware protection
• Apple, Mail Privacy Protection