Custom Domain Short Links: A 20-Minute Setup That Buys You Trust

You paste a short link into a customer email. It reads bit.ly/3xK9pQ. Nothing in it tells the reader the link came from you.

A custom domain URL shortener puts your short links on a domain you own, like go.yourbrand.com/spring. It takes one DNS record on a subdomain. Your own part is under ten minutes; the rest is waiting.

This guide works on almost any shortener, because the DNS part is the same everywhere. One step does change by vendor. I will flag it when we reach it.

What do you need to set up a custom domain URL shortener?

Three things:

1. A domain you already own, or one you buy.
2. Access to that domain's DNS settings.
3. A shortener that supports custom domains.

The domain is the only guaranteed cost. If you own one already, a subdomain of it costs nothing extra. Renewal prices vary a lot between extensions, and the first-year price is often not the real one. Our guide on choosing a short domain covers that trap.

Your shortener may request the certificate for you at no cost. Check that before you start.

Here is where the 20 minutes goes.

Your own work takes under ten minutes. The rest is waiting, and it can run past 20 minutes. Nothing is broken if it does.

Which subdomain should you pick?

Use a subdomain, not your bare domain. The subdomain is the part in front: the go in go.yourbrand.com. The next section explains why the bare domain does not work.

Common choices are go, link, l, s, get and try. Any of them is fine. Four rules help:

• Keep it short. Every character shows up in every link you send.
• Say it out loud. People read links aloud and type them from memory.
• Avoid a name you already use. www, mail, app and shop may point somewhere already.
• Pick one and keep it. Changing it later breaks every link you have published.

That last rule matters more than the other three put together. A short link is meant to outlive the campaign that created it.

Why can't you use your bare domain?

Because the DNS rules forbid it.

Your bare domain is called the apex, or the root. It is yourbrand.com with nothing in front.

A CNAME record points one name at another name. That is the record a shortener asks for. A CNAME cannot sit at the apex.

RFC 1912 puts it plainly: "A CNAME record is not allowed to coexist with any other data." The apex always holds other data. It carries the SOA and NS records that make the zone work at all. So a CNAME there is invalid.

Providers sell workarounds called ALIAS, ANAME or CNAME flattening. These are vendor features, not standards. The IETF draft for ANAME expired in 2019 and never became an RFC. Behaviour differs between providers.

Two of the biggest providers cannot do it at all, and plenty of guides get this wrong. AWS says an alias record in Route 53 "can only redirect queries to selected AWS resources" or to another record in the same hosted zone. Azure DNS alias records work the same way, pointing only at Azure resources or a record set in the same zone.

Neither one can point your apex at an outside shortener. If an article tells you to just use an ALIAS record, open your provider's own documentation before you believe it.

A subdomain avoids all of this. It takes an ordinary CNAME, and every DNS provider supports that.

The one DNS record you add

Open your DNS provider. That is wherever your nameservers live, which is often your registrar but not always. Add one record.

Four things go wrong here more than anything else.

The Host field. Some providers want just go. Others want the whole name, go.yourbrand.com. Enter the wrong style and you create go.yourbrand.com.yourbrand.com. Look at an existing record to see which one your provider uses.

The record type. Use CNAME, not A. An A record points at an IP address, and that address can change without anyone telling you.

The proxy toggle. If your DNS sits on Cloudflare, every record has an orange cloud next to it. Whether it belongs on or off depends on your shortener. Read their page, because the wrong setting can stop validation.

The TXT record question. Some shorteners also want a TXT record to prove you own the name. Others check over HTTP instead and need no TXT record at all. This is the step that differs by vendor, so follow your own shortener's instructions.

Why does the certificate take a while?

Your short links have to load over HTTPS. That needs a TLS certificate, a file that proves to the browser that this domain is really yours. Without one, the browser shows a warning instead of your page.

You do not usually buy or install it. Your shortener asks a certificate authority for one as soon as your DNS record starts answering.

One number nearly every article gets wrong: Let's Encrypt certificates are valid for up to 100 days, not 90. Their current policy document says so. Either way the life is short, which is exactly why renewal has to be automatic.

Setups differ in how much they ask of you. The clik.so setup takes one CNAME on a subdomain and no TXT record, because it validates over HTTP. The certificate is free and renews itself.

While you wait, the link may show a certificate warning. That is normal. Do not delete the DNS record and start again, because that resets the clock.

One extension trap is worth knowing. .app, .dev and .page sit on the HSTS preload list, so browsers force HTTPS on them. A short domain on one of those is broken until the certificate exists. There is no phase where plain HTTP works while you sort things out.

How do you check it works?

Run all five. The first two can pass well before the link is usable.

1. Look up the record. In a terminal, run dig go.yourbrand.com CNAME +short. On Windows, use nslookup go.yourbrand.com. You should see your shortener's host.
2. Open a short link in a private window. A normal window may hand you a cached answer.
3. Check the padlock. No warning means the certificate is live.
4. Test on mobile data. Your phone uses a different resolver from your office wifi. This catches a half-finished change.
5. Paste a link into the app you actually use. WhatsApp, Slack and LinkedIn each fetch their own preview. If the preview looks wrong, that is a separate problem, and our guide to broken link previews walks through it.

It is not working. What now?

Work down this list in order. The first three cover most cases.

Not enough time has passed. DNS answers are cached for a set number of seconds, called the TTL. If the old record had a long TTL, resolvers keep serving the old answer until it expires. Waiting is the only fix.

The Host field is wrong. Look up the name you created. If you see go.yourbrand.com.yourbrand.com, you typed the full name into a field that wanted only go.

The record type is wrong. An A record where a CNAME was asked for looks fine in the editor and still fails.

You edited DNS in the wrong place. If your nameservers point at another provider, records at your registrar do nothing. Check which nameservers your domain actually uses.

Something else already sits at that name. A CNAME cannot share a name with other records. Delete or rename the old one first.

The proxy setting is wrong. On Cloudflare, the orange cloud changes what a lookup gets back. Set it the way your shortener's documentation says.

A CAA record is blocking the certificate. A CAA record lists which certificate authorities may issue for your domain. If you have one, make sure it allows the authority your shortener uses.

Your own browser is misleading you. Browsers cache DNS answers and certificates. A private window, a second device or mobile data gives you the truth faster than clearing caches does.

Does a custom domain really buy trust?

It buys two things you can point at, and one you cannot.

Start with the reputation problem. A shared shortener domain carries the reputation of everyone else using it, spammers included. Spamhaus runs a domain blocklist with a dedicated return code, 127.0.1.103, for an abused spammed redirector domain. A domain only you use cannot be dragged down by a stranger's campaign.

The second thing is plainer. A branded link says where it goes before anyone clicks it. go.yourbrand.com/spring and bit.ly/3xK9pQ carry very different amounts of information.

Text messages even have written guidance. CTIA's Messaging Principles and Best Practices, May 2023 edition, asks senders to use a dedicated shortener. Its wording is "a shortener with a web address and IP address(es) dedicated to the exclusive use of the Message Sender". That is a should, not a law, and carriers apply their own filtering rules.

What you cannot point at is a number. You will see claims that branded links get some exact percentage more clicks. Every version we could trace comes back to vendor marketing with no stated method. We looked at what really changes when a link gets shorter and left the number out on purpose.

How many domains do you need?

One is enough for most people. A second earns its place if you run a clearly separate brand, or if you want marketing links kept apart from transactional ones.

Check what your plan allows before you buy anything. On clik.so that is one custom domain on the free plan, two on Starter, five on Pro and twelve on Business. It also gives every account eight ready-made branded domains, such as link.clik.is and shop.clik.is, which do not count against that limit.

FAQ

Want to try this yourself?

Pick a subdomain, add one CNAME, wait for the padlock. That is the whole job, and it works the same way on any shortener worth using. The clik.so free plan includes one custom domain and 2,000 tracked clicks a month, with no card required. The plans page shows what each tier allows.