How to Set Up a Custom Link Domain: CNAME, TLS, Pitfalls

Setting up a custom link domain is one DNS record and about fifteen minutes of work, and it is the single change that keeps roughly a quarter of your traffic — the Safari and iOS share — from silently dropping out of attribution.

A custom link domain is the go.yourbrand.com that your branded short links redirect through, and getting it right is mostly a matter of choosing the subdomain, adding a CNAME, and letting TLS provision.

Every tracked click is worth a median $3.80 in downstream revenue in our data, so the clicks a first-party domain keeps are money, not vanity (TrackRev platform data, Q2 2026).

A custom link domain is a subdomain you own, pointed at your link-tracking provider, that serves your short links so clicks are logged first-party on your own domain rather than on a shortener’s. This is a procedural guide: the subdomain choice, the DNS record, the certificate, and the pitfalls that trip people up — so every tracked link keeps tying clicks to the channel that earned the signup.

Why this matters for your revenue

The domain your links run on decides whether their clicks are logged first-party — and first-party is the difference between attribution that survives modern browsers and attribution that quietly loses the Safari and iOS share of your traffic.

A link on a shortener’s domain sets its cookie where you cannot use it and degrades under Safari’s tracking prevention; a link on your own domain, logged server-side, does neither.

That gap is revenue.

At a $3.80 median revenue per click, every click a first-party domain keeps in attribution is money that would otherwise vanish into the Direct bucket, and the loss falls hardest on Apple-heavy channels like email and iMessage that reach higher-value customers (TrackRev platform data, Q2 2026, at /data/saas-attribution-benchmarks).

A custom link domain is the fifteen-minute setup that closes the leak — the practical first step behind our guide to first-party link tracking after iOS 17.

Choosing the subdomain

The first decision is which subdomain to use, and it matters more than it looks.

Why go.yourbrand.com and not the apex

Use a subdomain — go., links., track. — rather than your root domain, so your link tracking runs independently of your main website and cannot interfere with it.

A subdomain also points cleanly at a provider with a CNAME, which the apex cannot do.

Keep the subdomain on the same root domain as your site, though, so the first-party cookie can be shared across your marketing site, app, and checkout.

Naming conventions that age well

Pick a short, neutral, permanent label. go and links age well because they describe the function without tying the subdomain to a campaign or a year.

Avoid anything you might regret — a product name that could change, a seasonal tag, an internal codename — because migrating a tracking domain later means re-issuing links and losing the clicks in flight.

Choose once, choose plainly, and keep it for good.

Apex vs subdomain: the CNAME rule

There is a hard technical reason to avoid the apex: DNS does not allow a CNAME record on a root domain that also has other records, such as the MX records for your email, so pointing yourbrand.com itself at a provider usually is not possible.

Subdomains have no such restriction — a CNAME on go.yourbrand.com is clean and standard. Some DNS providers offer ALIAS or ANAME records to work around apex limits, but a subdomain sidesteps the whole problem, which is why it is the convention.

Adding the DNS record

With the subdomain chosen, the setup is a single record in your DNS provider’s dashboard.

The CNAME record, step by step

In your DNS host — Cloudflare, Namecheap, Route 53, wherever your domain lives — add a CNAME record with the host set to your subdomain (go) and the target set to the value your link-tracking provider gives you.

That one record delegates answering requests for go.yourbrand.com to the provider, which is what lets it serve and log your links while the domain stays yours. Save it, and the DNS side is essentially done.

Propagation and TTL

After you save the record, it takes time to propagate across DNS resolvers — anywhere from a few minutes to, in the worst case, a day or two.

The TTL (time-to-live) on the record influences how quickly changes take effect; a lower TTL propagates faster but is queried more often.

For a new record on a fresh subdomain, propagation is usually quick because there is no old value cached anywhere to expire first.

Why propagation is usually minutes, not days

The scary 24-to-48-hour figure applies to changing an existing record, where old values sit cached in resolvers until their TTL expires. A brand-new subdomain has nothing cached, so most resolvers pick it up within minutes of the record going live.

If your custom domain is not resolving after an hour, the cause is almost always a typo in the record or the wrong target value — not slow propagation — so check the record before you wait.

The DNS record at a glance

The whole DNS footprint of a custom link domain is a single row that looks like this.

TLS and verification

A link domain has to serve over HTTPS, so a certificate is the next step — and with most providers it is automatic.

Automatic certificate issuance

Once your CNAME is verified, most link-tracking providers issue and renew a TLS certificate for the subdomain automatically, so your links load over HTTPS with no warnings and you never touch a certificate file.

TrackRev provisions TLS for custom tracking domains automatically after the DNS check passes. If your provider does not, you would use a service like Let’s Encrypt, but automatic issuance is now the norm and worth expecting.

The verification wait

There is usually a short wait between saving the DNS record and the provider confirming the domain and issuing the certificate, because the provider has to see the CNAME resolve before it can validate ownership.

This is normal and typically resolves in minutes once DNS has propagated. If verification stalls for longer, it almost always traces back to the DNS record rather than the certificate — recheck the host and target values first.

Mixed-content and HTTPS-only

Make sure the destinations your links point to are themselves HTTPS.

A branded link served over HTTPS that redirects to an http:// destination can trigger a mixed-content warning or an insecure hop, undermining the trust the branded domain was meant to build.

Since virtually every legitimate destination supports HTTPS today, the fix is simply to always use the https:// version of the target URL when you create the link.

Common pitfalls

Most custom-domain problems are one of a small handful of mistakes. Knowing them in advance turns a support ticket into a thirty-second fix.

When a provider-hosted domain is fine

You do not always need your own custom domain immediately. Two cases can wait.

Testing and staging

While you are evaluating a tool or building a campaign you have not launched, the provider’s default short domain is fine for testing the flow end to end.

You get working links and real click logs without touching DNS, which is ideal for a trial.

Move to your own custom domain before the links go in front of customers, so the branding and first-party tracking are in place for the traffic that counts.

No brand domain yet

If you have not registered a domain at all — a very early project — there is nothing to point a CNAME from, and the provider’s shared domain is your only option.

Register a domain as soon as the project is real, then set up the tracking subdomain; it is a fifteen-minute job and the attribution gains begin immediately.

When to use your own custom domain

The moment links go to real customers and their clicks are worth measuring, your own domain is the default.

Parity first, then the shared model

TrackRev handles custom tracking domains the way a dedicated shortener does — one CNAME, automatic TLS, custom slugs — then adds what a pure shortener cannot: the clicks on that domain are joined to Stripe revenue, and because link tracking, attribution, and the affiliate programme share one data model, the same domain serves your marketing links and your affiliates’ referral links on one definition of a sale.

Parity on the domain setup, then the revenue join on top. See custom tracking domains and first-party tracking.

The stack math

A custom domain plus attribution should be one subscription.

Teams often run a link tracker like Bitly Growth (~$35/mo) beside an affiliate tool like Rewardful Starter (~$49/mo) — about $84/mo for two tools with two definitions of a conversion and two separate cookie domains that each lose iOS attribution their own way.

TrackRev is $39/mo for link tracking, revenue attribution, and affiliates on one shared model and one first-party domain, with a free tier at 1,000 events/mo. Pricing is on the pricing page.

When NOT to use TrackRev

If you are only testing, or have no domain to brand yet, the provider’s default short domain — or a free shortener — is enough for now, and a custom domain is a step you can defer.

TrackRev is also not a DNS host or a certificate authority; it consumes the CNAME you create and provisions TLS, but you still manage the domain at your registrar.

It is built for SaaS and subscription teams that want branded, first-party link domains whose clicks connect to real revenue.