How to Set Up a Custom Domain Link Shortener

Why a custom domain is worth the setup time

A generic short domain like bit.ly or tinyurl.com works fine functionally, but every link carries someone else's brand instead of yours, and recipients increasingly hesitate to click unfamiliar generic shorteners given how often they've been used for spam or phishing. A custom domain, something like go.yourcompany.com, puts your own brand in front of the click and signals legitimacy in a way a generic domain can't. The setup is a one-time investment that pays off across every campaign link created afterward.

Step 1: Choose the subdomain, not just the root domain

Most teams use a subdomain of their existing domain, like go.yourcompany.com or link.yourcompany.com, rather than the bare root domain. This is both easier to configure, since it doesn't touch your primary website's DNS records, and safer, since any misconfiguration is isolated to the subdomain rather than risking your main site's availability. Pick something short and memorable, since it will appear in every link your team creates going forward.

Step 2: Add the CNAME record your provider requires

Your link management tool will provide a target hostname to point your subdomain at, typically via a CNAME record in your DNS provider's control panel. Log into wherever your domain's DNS is managed, GoDaddy, Cloudflare, Namecheap, or your registrar of choice, and add a new CNAME record with your chosen subdomain as the host and the tool's provided target as the value. This is the single most important step, and also the one where most setup errors happen.

Step 3: Wait for DNS propagation before assuming something's broken

DNS changes don't take effect instantly everywhere. Propagation can take anywhere from a few minutes to 48 hours depending on your DNS provider and the TTL, or time-to-live, set on the record. It's common to test a custom domain five minutes after adding the CNAME record, see it fail, and assume the configuration is wrong when it's simply still propagating. Use a DNS lookup tool to check whether the record has resolved before troubleshooting further.

Step 4: Let SSL provision automatically, but verify it actually did

Modern link management platforms provision an SSL certificate for your custom domain automatically once the CNAME record resolves correctly, so links serve over HTTPS instead of throwing a security warning. This step usually happens without any action needed from you, but it depends entirely on the CNAME being correct first. If SSL provisioning seems stuck, the DNS record is almost always the underlying issue rather than the SSL step itself.

Common DNS mistakes that break the setup

The most frequent error is a typo in the CNAME target, an extra character or a missing trailing dot depending on the provider's conventions. The second most frequent is pointing the record at the wrong value entirely, often because a team member copies an example from documentation instead of the actual value generated for their specific account. A third common mistake is adding an A record instead of a CNAME record when the provider explicitly requires a CNAME, which will cause the domain to resolve to nothing usable.

Testing the setup properly before rolling it out

Once the domain resolves, create a single test link and confirm it redirects correctly, loads over HTTPS without a certificate warning, and that any UTM parameters attached to it survive the redirect. Test this from a different network than the one you configured it on, ideally a phone on mobile data, since local DNS caching can make a broken setup appear to work correctly on the machine that just configured it.

Rolling out the new domain across your team

Once verified, update your team's saved UTM templates to use the new custom domain by default so nobody accidentally keeps generating links on the platform's generic domain out of habit. This is also a good moment to formalize or revisit your naming convention, since a custom domain rollout is a natural checkpoint for standardizing how links are built going forward; see our naming convention guide if that hasn't been done yet.

UTMLoop supports custom domains on paid team plans with guided DNS setup and automatic SSL provisioning; see pricing for details and features for the full setup flow.

Handling multiple environments or brands under one setup

Some teams need more than one custom domain, for example separate short domains for different product lines, regional brands, or a staging environment used to test campaigns before they go live. Each domain generally needs its own CNAME record and goes through the same propagation and SSL provisioning process independently, so plan for the additional setup time if you're configuring more than one at once rather than assuming the second domain will be faster simply because you've done it before.

It's also worth deciding upfront which team members are allowed to add or modify custom domain configurations, since DNS changes have consequences beyond the shortener itself if someone accidentally edits the wrong record on a shared domain. Restricting this to a small admin group avoids an accidental outage on infrastructure the wider marketing team depends on daily, and it means any future troubleshooting starts with a known, small list of people who could have made a change rather than an open-ended guess across the whole organization.

A troubleshooting walkthrough: the domain resolves but links still fail

One confusing failure mode deserves its own walkthrough because it doesn't match the usual DNS-error pattern: the custom domain resolves correctly, a DNS lookup tool confirms the CNAME is pointed at the right target, but links still return an error or a certificate warning instead of redirecting properly. The first thing to check in this situation is whether the domain has been added and verified inside the link management platform itself, not just pointed at it via DNS. A CNAME record alone tells the internet where to send traffic; the platform still needs to be told which domain to expect and issue a certificate for, and skipping that registration step inside the tool is an easy thing to miss after finishing the DNS half of the setup.

The second thing to check is whether a conflicting record already exists on the same subdomain, most commonly a leftover A record or TXT record from a previous, unrelated service that was once pointed at that same subdomain and never removed. Most DNS providers allow only one record type actively resolving per subdomain for routing purposes, so a stale A record can silently override a newly added CNAME even though both appear in the DNS panel. Removing the old record and waiting for the shorter of the two records' TTL to expire usually resolves this within an hour. If neither of these explains the failure, the platform's support documentation for domain verification errors is worth checking before assuming the DNS configuration itself is at fault, since by this point the DNS layer has usually already been ruled out.