Branded Link Shortener: Setup, Custom Domains, and DNS

Setting up a branded link shortener is a smaller technical project than it sounds like, mostly because the shortener service does the actual redirect logic — what you're doing is pointing a piece of your own domain at that service and proving you own it. The whole process usually comes down to one DNS record and one verification step, but each of those has a couple of ways to get it slightly wrong, and those small mistakes are what turn a five-minute setup into a support ticket.

Choosing the subdomain

The first decision is which subdomain to use, and it's worth more thought than it usually gets. go.yourdomain.com, share.yourdomain.com, and links.yourdomain.com are the common patterns, and any of them works technically — the choice is really about brand fit and memorability. Shorter reads cleaner in a text message or on a printed flyer, but the actual constraint is just picking something you'll use consistently, since every link created under it inherits the same domain automatically. It's worth avoiding a subdomain you're already using for something else — a go. subdomain already pointed at an internal tool, for instance — since DNS records for a hostname can conflict.

The DNS record itself

Most branded shortener setups use a CNAME record: the subdomain you chose points to a hostname the shortener service gives you, rather than to a raw IP address. A CNAME is preferred over an A record here because it lets the service move or scale its underlying infrastructure without you having to update anything on your end — the service's hostname stays constant even if the IP addresses behind it change. Setting this up means logging into whatever registrar or DNS host manages your domain (not necessarily where the site itself is hosted — those are often different providers) and adding a record roughly in the shape of: host go, type CNAME, value pointing at the address the shortener platform provides, usually with a reasonable default TTL.

Where this trips people up

A few mistakes account for most setup failures. Adding the record at the registrar when DNS is actually managed elsewhere — a common situation when a domain was bought through one provider but DNS was later delegated to another, like a CDN or hosting platform — means the record you added is invisible to the internet even though it looks correct in the registrar's dashboard. Typos in the target hostname are common and silent; a CNAME pointing at a slightly wrong value won't error, it'll just never resolve correctly. And forgetting that DNS changes take time to propagate — sometimes minutes, sometimes hours depending on the previous record's TTL — leads people to conclude a correct setup is broken when it just hasn't finished propagating yet.

Verifying ownership

Beyond the CNAME that actually routes traffic, most shortener platforms require a separate ownership verification step before activating the domain — usually a TXT record with a unique token the platform generates for your account. This exists so the platform doesn't let anyone claim a domain they don't control; without it, someone could theoretically point their own shortener setup at a domain they don't own if the CNAME were the only check. The TXT record is typically added the same way as the CNAME — same DNS host, same interface — and once it's detected, the platform marks the domain as verified and starts serving redirects under it.

SSL and certificate provisioning

Once DNS is verified, most platforms automatically provision an SSL certificate for the subdomain so links resolve over HTTPS rather than throwing a certificate warning. This step is usually automatic and doesn't need a separate action, but it's also usually not instant — there's a short window, typically minutes rather than hours, between DNS verification completing and the certificate being live. Testing a link during that window can show a certificate error that resolves itself shortly after; it's worth waiting a few minutes before assuming something's broken.

Testing before you rely on it

Before pointing real campaigns at a newly configured domain, it's worth creating one test link and confirming the full path: the short URL resolves, it redirects to the correct destination, it loads over HTTPS without a warning, and — if the platform tracks this — the click actually shows up in analytics. Testing the redirect alone isn't sufficient; a domain can resolve and redirect correctly while still having a broken analytics pipeline behind it if verification only partially completed. Confirming all three pieces together is the only way to be sure the setup is actually done, not just DNS-correct.

Who needs to be involved

In practice, this setup usually needs one person with access to DNS management, which isn't always the same person who wants the branded shortener working. At a small company that might be the same individual wearing two hats; at a larger one, it often means a marketing or growth team needs someone on the infrastructure or IT side to add a couple of records. Flagging that dependency early avoids the common failure mode where a project stalls for a week because a DNS change request sat in someone else's queue behind higher-priority work. The actual technical steps take minutes; the coordination to get access to make them is usually the longer part.

What happens if you switch shortener providers later

Because the branded domain is yours, not the provider's, moving to a different sharing-link platform later doesn't mean losing the domain or re-training your audience on a new one. The DNS record gets repointed at the new provider's target, ownership gets re-verified there, and go.yourdomain.com keeps working under new infrastructure without anyone who's ever seen that domain needing to notice a difference. This is one of the more understated advantages of owning the domain layer: a generic shortener domain ties you to that specific vendor forever, since every link you've ever shared has that vendor's domain baked in permanently. A branded domain keeps that flexibility in your hands, which matters more the longer you've been using the shortener and the more historical links depend on it continuing to resolve.

A short setup checklist

For anyone about to do this for the first time, it helps to have the sequence written out plainly rather than piecing it together mid-setup:

1. Pick a subdomain that fits your brand and isn't already in use for something else
2. Get the CNAME target and verification token from the shortener platform
3. Add the CNAME record at whichever provider actually manages your domain's DNS, not necessarily your registrar
4. Add the TXT verification record alongside it
5. Wait for propagation and confirm the platform shows the domain as verified
6. Wait a few extra minutes for the SSL certificate to provision before testing over HTTPS
7. Create one test link and confirm the redirect, the certificate, and the analytics tracking all work end to end

None of these steps individually are hard, but skipping the last one — actually testing before relying on the domain for a real campaign — is the most common way a setup that looks complete turns out to have a gap discovered at the worst possible time.

How useopengraph handles custom domains

Sharing Links in useopengraph support custom domains as part of the core feature — you add the CNAME and verification record pointing at useopengraph, and once verified, every link you create under that workspace uses your own domain automatically rather than a shared one. From there, the links function like any other sharing link: click analytics by day, country, device, and referrer, with Split Testing available on the Growth plan and above to run multiple OG image variants behind a single branded, trackable link.