How to set up a custom domain for your short links

A custom domain is a hostname you own — usually a short subdomain such as go.example.com — pointed at Trizlink so that your short links read as your own rather than as ours. The link still behaves identically; only the name in front of the slug changes.

Choose the hostname first

Pick a subdomain rather than your apex domain. Using example.com itself means every short link shares a hostname with your website, which constrains both and makes a mistake in either far more expensive. A dedicated subdomain — go, link, l, or your brand — keeps the two independent. It is also the difference a shared shortener domain makes to whether your links survive a mail filter.

• Short matters: the whole point is a compact URL, and every character of the hostname is spent before the slug starts.
• Memorable matters more than clever. People retype these from screenshots and printed material.
• Do not reuse a hostname that has served something else. Old links, caches and bookmarks will collide with your new ones.
• Decide once. Changing the hostname later means every link already published now points at a name you no longer serve.

Add the DNS records

1. In Trizlink, add the domain in the workspace’s domain settings. You are shown the exact records to create, generated for that hostname.
2. In your DNS provider, create the CNAME record for the hostname, pointing at the target Trizlink shows you.
3. Create the verification TXT record alongside it. This is what proves you control the name; without it a CNAME alone is not enough.
4. Save, and come back to Trizlink to run the check.

Two things about the records are worth knowing in advance. Many DNS interfaces append the zone automatically, so entering "go.example.com" as the host can silently create go.example.com.example.com — enter just "go" if the provider shows the zone beside the field. And a CNAME cannot coexist with other records on the same name, which is another reason not to reuse a hostname.

What verification is checking

Verification is two questions, not one. Does the TXT record prove you control this hostname, and does the CNAME actually resolve to us? A domain can pass the first and fail the second — usually because the CNAME was created on the apex instead of the subdomain, or because a proxying setting is intercepting it.

Propagation is the usual reason a correct setup fails on the first attempt. DNS changes take effect on a schedule set by the record’s TTL, so a change made against a one-hour TTL can take up to that long to be visible everywhere. Re-running the check is safe and costs nothing; changing the records again while waiting is what turns a five-minute job into an afternoon.

When it does not verify

1. Check the hostname for a doubled zone (go.example.com.example.com) — the single most common cause.
2. Confirm the CNAME is on the subdomain, not the apex.
3. If your DNS provider offers a proxy or CDN toggle on the record, turn it off for this hostname; a proxy answers instead of us.
4. Look for a conflicting record on the same name — an old A record or an existing CNAME will win.
5. Wait for the TTL and re-check before changing anything. Most "it is broken" reports are propagation.

What a custom domain actually buys

• Reputation you control. Links on a shared domain inherit the behaviour of everyone else on it, and shared shortener domains do get blocked by mail filters and corporate networks. Your own hostname carries only your history.
• Click-through. A recognisable domain in a link is the difference between "this is from them" and "this is from somewhere", particularly in email and in print.
• Portability. If you ever move tools, the links people saved point at a name you own, so the migration is a DNS change rather than a broken archive.
• Consistency across surfaces. The same domain serves your short links and your bio page, so everything you publish reads as one thing.

The reputation point is the one most often discovered too late. A link that works perfectly when you test it can still be stripped by a recipient’s mail filter, and the sender never finds out — the message simply performs badly for reasons that look like content.

After it is live

New links in that workspace can use the domain immediately. Links you created earlier keep serving from the domain they were made on — deliberately, because rewriting a published link is the one thing a link platform must never do. Point new work at the new domain and let the old links live out their usefulness.

A custom domain also carries into your bio pages, so the link-in-bio page you publish serves from your name too. That is usually the moment the setup pays for itself, because a bio link is the one URL people see most often.