Setting up a custom short-link domain — the walkthrough

Setting up a custom short-link domain is a 30-minute job once you know the order of operations. You buy a short domain (or pick a subdomain on a domain you already own), you add one DNS record at your registrar, the platform issues a TLS certificate over the next minute or two, and your first link works. The pieces are simple. The reason most people stall halfway is that the DNS step looks foreign if you've never touched a registrar control panel before — and registrars love hiding the right input behind three nested menus.

This walkthrough goes through every step in order. Picking the domain. Subdomain versus apex. The exact DNS record to paste. Why TLS just appears without you doing anything. The optional CAA record that prevents a class of certificate-issuance attacks. The verification step that 80% of people skip and then can't figure out why their link returns a 404. By the end you'll have a checklist you can run on any short-link platform, not just ours.

Step 1 — Pick the domain#

The domain you point at the redirector is the public face of every link you ship from now on. Two paths.

Path A: subdomain on your existing brand domain. You already own yourbrand.com. You set up link.yourbrand.com, go.yourbrand.com, try.yourbrand.com, or whatever short prefix you want. Your branded short links look like link.yourbrand.com/spring. Cost: zero — the subdomain lives inside the domain you already pay for. Setup: one CNAME record, the easiest path on every modern registrar.

Path B: a separate short domain. You buy something like yourbrnd.co or ybr.link and use it exclusively for short links. Your links look like yourbrnd.co/spring. Cost: $10-30 per year for the domain. Setup: same DNS work as path A, but on a fresh domain.

Path B is what most agencies and bigger brands run — the link looks slicker. Path A is what most small businesses run because the cost is zero and the setup is faster. The trust signal lands either way as long as the domain is recognisably yours. When the work is for a paying client and the QR codes go on physical assets, the subdomain question becomes a billable line item rather than a setup cost — covered in branded QR codes for agency clients. Senders running email campaigns hit the same domain question for a different reason — whether a custom short-link domain survives Mailchimp's link-wrapping inside a newsletter is the email-channel version of this same setup decision.

If you go with path B, three opinions worth absorbing before you buy:

• Buy a .com if it's available and short enough. .com carries the most trust by a wide margin. If yourbrnd.com is taken (it usually is), drop to a country-style short — .co, .link, .to, .io for tech-leaning audiences. These are mainstream now and don't trigger "is this a phishing link" reflexes.
• Avoid the cheap-bulk TLDs. .xyz, .click, .top, .tk. These are heavily abused by spam campaigns. Email providers and link previews flag them. The few dollars saved on registration cost you in click-through rate.
• Twenty characters is the upper bound. Including the TLD. lnks.work/k/spring (18 chars) is great. mybrandshortlinks.com/k/spring is not a short link in any meaningful sense. The length constraint matters double if you plan to use the domain for QR codes — every extra character forces the QR to be denser and harder to scan at small print sizes, which is the QR-specific case covered in why the QR code domain matters as much as the design.

Buy through a reputable registrar — Cloudflare Registrar, Porkbun, Namecheap, Hover. Avoid bargain-bin registrars that bundle hostage-style upsells. Once the registrar side is sorted, the short-link generator is where you'll wire the first slug against the new domain and confirm the redirect resolves end-to-end before anything goes live.

Step 2 — Subdomain or apex?#

Before you touch DNS, decide what hostname your links will use.

Subdomain (recommended) is link.yourbrand.com or yourbrnd.co/... where the relevant DNS record sits below the apex. Subdomains support CNAME records natively, which is what every short-link platform asks for. Setup is a one-liner.

Apex is yourbrnd.co itself — the bare domain, no subdomain prefix. Apex looks cleanest in print and reads tightest in copy. The catch: the DNS spec doesn't allow CNAME records at the apex, because the apex needs other records (SOA, NS) that CNAME is not allowed to coexist with.

Apex setups need one of two workarounds:

• An A record pointing directly at the platform's IP. Works on every registrar but locks you to whatever IP the platform happens to be on today. If the platform changes IPs, your link breaks until you update DNS.
• An ALIAS or ANAME record. A registrar-side fake-CNAME that resolves the target hostname behind the scenes and serves the IP at the apex. Cloudflare DNS calls it "CNAME flattening". DNSimple, Hover, and a few others call it ALIAS or ANAME. GoDaddy doesn't natively support this, which is one of the reasons most apex-domain setups end up moving DNS to Cloudflare.

For most setups, picking a subdomain and using a CNAME is the path of least resistance. Save apex for the version 2 of your branded link strategy, after you've proven the value and want to squeeze every character.

Step 3 — Add the DNS record#

Log into your registrar. Find the DNS or "manage DNS" section for the domain. Interfaces vary in friendliness; the inputs are always the same four fields:

• Type — what kind of DNS record. For a subdomain setup, CNAME. For an apex with a known platform IP, A. For an apex on a registrar that supports it, ALIAS or ANAME.
• Name (or Host) — the subdomain prefix. For link.yourbrand.com, type link. Some registrars want the full hostname; most want just the prefix. Read the placeholder text.
• Value (or Target / Points to) — what the record points at. For a CNAME, the hostname your platform gave you (e.g. cname.lnks.work). For an A record, the IP. Copy-paste from the platform's setup screen — don't type from memory.
• TTL — leave at the default (typically 1 hour). The default is fine.

Save. The record is live at your registrar within seconds. DNS resolvers across the internet cache the previous answer, so a fresh record takes a few minutes to propagate — sometimes longer on slow cached resolvers, though in practice most setups verify in under five minutes on a modern DNS provider.

DNS-record builder — paste-ready output#

Type your subdomain and target below. The output is exactly what you paste into your registrar.

The output above is verbatim. Paste it into your registrar. You should see "saved" or a green checkmark within a couple of seconds. If your registrar throws a validation error — usually about the value field — read it carefully. Most errors at this step are typos in the target hostname or the wrong record type.

Step 4 — TLS issuance happens automatically#

This is the part most people don't believe until they see it work. You don't install a certificate. You don't run any commands. You don't email support. The platform issues a TLS certificate for your custom domain on demand, the first time someone tries to load https://link.yourbrand.com/anything.

The mechanism is the Caddy on-demand TLS pattern, layered on top of Let's Encrypt's automated certificate API. The order:

1. A user visits https://link.yourbrand.com/spring.
2. The browser does a DNS lookup. The CNAME points at the platform's hostname, which resolves to the platform's IP.
3. The browser opens a TLS connection and asks for a certificate covering link.yourbrand.com.
4. The platform doesn't have one yet. It checks: does this hostname have a CNAME pointing at us? If yes, it asks Let's Encrypt to issue a cert via the HTTP-01 challenge.
5. Let's Encrypt issues the cert in 2-5 seconds. The platform serves it back to the browser.
6. TLS completes, the browser sees a valid https://, and the redirect fires.

First-request total: typically 4-8 seconds. Subsequent requests use the cached cert and complete in milliseconds. Renewal happens automatically every 60-90 days. The cert is public-trusted and indistinguishable from a manually-issued one — Let's Encrypt is the same CA that issues for the rest of the public web.

Step 5 — Add a CAA record (optional but recommended)#

A CAA record (Certificate Authority Authorization, defined in RFC 8659) tells the public web "only these named CAs are allowed to issue certificates for this domain." It's a defence against a class of attacks where a compromised registrar account or a sloppy CA accidentally issues a fraudulent cert for your domain through a CA you don't actually use.

For a Let's Encrypt-backed setup, the right CAA record is:

yourbrand.com.  IN  CAA  0 issue "letsencrypt.org"

Or, in your registrar's UI: type CAA, name @ (apex) or your subdomain prefix, value 0 issue "letsencrypt.org", TTL default.

This adds about 30 seconds to the setup. It does nothing on a normal day. The day a CA somewhere has a security incident, every domain on the internet without a CAA record could in theory be issued a cert through them — yours, with the CAA, can't be. It's belt-and-braces in the same spirit as enabling 2FA on a registrar account you rarely log into.

If you're setting CAA at the apex, every subdomain inherits it unless you set a different record specifically. So one record at the root covers link.yourbrand.com, mail.yourbrand.com, app.yourbrand.com, and so on. For most setups, one CAA at the apex is the right move.

Step 6 — Verify in the platform dashboard#

After DNS is saved, open the platform dashboard's "custom domain" section. There's almost always a "verify" or "check status" button. The platform runs three checks:

• DNS resolves correctly. Your CNAME points where it should.
• The hostname reaches the platform. A test request returns the expected response.
• TLS issued cleanly. The certificate is valid for the hostname.

When all three pass, the dashboard flips the domain to "verified" or "active". Wait for that indicator before you start generating links. Your own dig output shows DNS resolved on whichever resolver you happen to be on; the platform's view is the one that determines whether a real-world click works.

If verification fails, the dashboard usually says why: "DNS not resolving", "TLS handshake failed", "wrong CNAME target". Read the error, fix the obvious thing, click verify again. Every error has a single specific cause.

Step 7 — Generate your first link#

Switch the link generator from the platform's default domain to your own. In most dashboards this is a per-link toggle or an account-level default. Generate a link. Copy it. Click it. You should land on whatever destination you set.

If the link 404s, it's almost always one of two things: the platform default is still set so the link was generated on the wrong domain, or a typo in the slug. Both fixable in seconds.

Branded short links — why your domain beats bit.ly covers the trust and click-through case for why this work pays off. The mechanic is now in your hands; the conversion lift comes once you start using the new domain in real campaigns.

Common breakage — registrars that block CNAME at apex#

The most common stall point in a Path B setup: you decided to use the apex (yourbrnd.co directly, no subdomain) and your registrar doesn't support ALIAS or ANAME. GoDaddy, Network Solutions, and a handful of older registrars are in this camp. Three options:

1. Move DNS to a registrar that supports it. Cloudflare DNS is free and supports ALIAS via "CNAME flattening". You keep the domain registered where it is; you just change nameservers to point at Cloudflare. Setup is 15 minutes.
2. Use an A record. Most platforms publish a stable IP for this purpose. The trade-off: if the platform changes IPs, your link breaks until you update DNS. Fine for personal scale; not ideal where uptime matters.
3. Use a subdomain instead of the apex. go.yourbrnd.co instead of yourbrnd.co. Looks marginally less clean, zero migration. This is the path most people end up taking.

What about the long-term insurance?#

Beyond the click-through lift, the reason to do this work is migration optionality. The branded domain is the artifact you own.

Walk through it. You set up link.yourbrand.com on a platform today. Three years later — pricing, features, fall-out — you switch platforms. What happens to the QR codes you've printed, the links saved in customers' bookmarks, the scripts that reference link.yourbrand.com/spring?

They all keep working, as long as you keep the domain. Point the CNAME at the new platform. Import your slug-to-destination map. Verify, wait for TLS, done. From the user's view, nothing changed.

The CTR lift pays for itself within months. The migration optionality pays for itself the first time a generic shortener has an outage or sells to someone you didn't anticipate. Why you should own your link infrastructure walks through the four ownership levels — the custom-domain setup you just did gets you to level 2, the sweet spot for most businesses. Every QR code you've printed encodes the URL, so QRs keep working too — URL QR codes vs short-link QR codes covers why a custom domain is the highest-payoff QR insurance.

The click flow, in full#

Worth visualising once. From the moment a user taps your link to the moment the destination page loads.

Anti-pattern — subdomain without a CAA#

One trap worth flagging: if you use link.yourbrand.com and don't set a CAA record, some carrier ad-systems and email-link scanners flag the subdomain mismatch as suspicious. The reasoning is brittle but real — a sender uses yourbrand.com for the main site and link.yourbrand.com for redirects, the scanner sees the subdomain doesn't match the apex, and a percentage of the time it scores the email worse for it. The fix is the CAA record from step 5. Doesn't fully solve the problem; reduces the false-positive rate enough to matter.

What's left — the dashboard side#

The DNS and platform side are done. The remaining work is on your end:

• Switch your link generator default to the new domain so every new link runs on it.
• Update your QR generator. Encoded URLs should now use the new domain.
• Tell your team. If multiple people generate links, the shared default needs to be your new domain so nobody slips back to the platform default.
• Don't retroactively rebrand old generic-shortener links. They keep working as they were. New ones go branded.

From the platform's side, the new domain behaves identically to its built-in domain — same dashboard, same analytics, same edit flow. From your side, every new link reads as yours.

Related reading#

• Branded short links — why the domain matters — the case for going through the setup work in the first place.
• Branded short links, trust, and the click you lose — the CTR-and-conversion math.
• Custom domain — platform docs — the dashboard side of what you're configuring on DNS.