Why a custom domain is worth the setup time
A branded short link built on your own domain reads as yours the instant someone sees it, before they even click. A link on a shared shortener domain reads as borrowed, and on some platforms it can carry that platform's own reputation, good or bad, since every customer's links share the same root domain. Put your links on a domain you control and that reputation, along with the link itself, belongs to you rather than to whichever url shortener you happened to sign up with.
This is also the difference between a url shortener with custom domain support and one without it. Without it, you are permanently a tenant on someone else's address. With it, the platform is infrastructure underneath a domain you already own, and you could in theory move providers later without every link you have ever shared going dead.
Subdomain or apex domain: use the subdomain
This is the part most setup guides skip, and it is the first thing that trips people up. A CNAME record points one hostname at another, and DNS rules generally do not allow a CNAME to sit on an apex domain, the bare yourbrand.com with nothing in front of it, because the apex already has to carry NS and SOA records that a CNAME cannot coexist with. Some DNS providers offer a workaround, commonly called an ALIAS or ANAME record, or CNAME flattening, that fakes apex support behind the scenes. It works, but it is provider-specific, and not every registrar offers it.
The simpler path, and the one that works everywhere without exception, is a subdomain: go.yourbrand.com, link.yourbrand.com, or similar. A subdomain can always carry a plain CNAME record, no special feature required, which is why almost every link tool that supports a link domain asks for a subdomain rather than your bare root domain.
| Record type | Works on a subdomain | Works on an apex domain | Typical use for a link domain |
|---|---|---|---|
| CNAME | Yes, always | No, in standard DNS | Pointing go.yourbrand.com at your link platform |
| ALIAS / ANAME | Yes | Yes, provider-dependent | Pointing a bare yourbrand.com at a platform, where supported |
| A record | Yes | Yes | Pointing directly at a fixed IP address, rarely what a link platform gives you |
| TXT | Yes | Yes | Proving domain ownership before a certificate is issued |
Setting it up: the short version
Once you have picked a subdomain, the process itself is short. Your platform gives you a target hostname, you add a CNAME record pointing your subdomain at it, and you add a TXT record if one is requested. Then you wait. DNS propagation is usually done within minutes but can take up to a couple of days depending on your provider's time-to-live setting on the old records. Certificate issuance normally follows automatically once the CNAME resolves cleanly, without you needing to do anything else.
That is the version that works the first time. It does not always happen that way.
The failure mode almost nobody warns you about: CAA records
If your DNS is correct and propagation has clearly finished, but the certificate still will not issue, the next thing to check is a CAA record. A CAA (Certification Authority Authorization) record restricts which certificate authorities are allowed to issue a certificate for your domain at all. If a previous host, a previous platform, or a security policy set at your domain has left a CAA record locked to one specific certificate authority, and your new link platform issues through a different one, commonly Let's Encrypt, the request will fail silently. Nothing in your DNS looks wrong. The CNAME is correct, and the certificate simply never appears. Most support documentation never mentions this as the reason.
The fix is either to remove the restrictive CAA record if you do not need it, or add an explicit entry that permits the certificate authority your platform uses. Either way, check for one before assuming the platform's verification system is broken.
Redirect based versus reverse proxy: what you are buying
Not every "custom domain" feature does the same thing underneath, and the difference matters more than the marketing copy usually lets on. A redirect based setup sends a visitor's browser from your domain straight to the platform's own domain, which means the address bar shows your branding for a fraction of a second and then reveals the underlying platform anyway. Anyone who reads the URL bar after the page loads sees exactly what tool you are using, which quietly defeats a lot of the point of paying for a custom domain in the first place. A redirect is a genuinely useful mechanism elsewhere, but it is the wrong one here.
A reverse proxy setup is different. The platform serves your page's content while your domain stays in the address bar for the entire visit, and nothing bounces. That is real infrastructure on the platform's side, not a cosmetic trick, and it is what Raydar's first paid plan gives you when you connect a link domain. Before setting anything up on any platform, it is worth confirming in writing which of the two you are getting, because the DNS instructions can look identical while the visitor experience underneath is completely different.
Troubleshooting a domain that will not verify
- DNS has not fully propagated yet. Check again after a few hours rather than assuming it failed.
- The CNAME target was copied with a trailing character missing, or a stray period added or dropped.
- A CAA record is silently blocking certificate issuance, covered above.
- An existing A or AAAA record on the same subdomain is conflicting with the new CNAME. A hostname can only carry one of these at a time.
- Your own computer or browser has a stale DNS cache from before you made the change. Try a different device or network before troubleshooting the DNS itself further.
Choosing a subdomain that reads well
Any subdomain works technically, but not every one works the same for a reader glancing at a link. Short, common patterns like go., link., or s. read as intentional and get out of the way of the brand name behind them. Anything longer than one short word in front of the dot starts competing with the brand itself for attention, which works against the reason you branded the link to begin with. If you already run a shortener domain for one purpose, for example an internal link for staff, keep it separate from the subdomain you use for public marketing links, since mixing the two makes both harder to reason about later.
What a custom domain changes for SEO and link equity
A branded short link is not the same as a canonical URL, and a custom domain on a shortener does not, by itself, change how a search engine treats the pages it eventually points to. What it does change is who owns the reputation sitting behind every click. A shared shortener domain used by thousands of unrelated customers can get flagged by a platform, an email filter, or a security tool because of what someone else on that same domain did, and every customer sharing the domain inherits that risk together. A domain only your own links live on does not carry anyone else's history. It is a genuinely underrated reason to set one up, well before the branding argument even comes into it. For a broader look at what makes a shortener trustworthy or not in the first place, see is a url shortener safe.
Test it before you rely on it
The domain verifies. Do not assume it is finished. Load a real link on it from a phone and confirm the certificate shows as valid, the destination is correct, and the click still logs the way it did on the old domain. The full process for checking a link's behavior properly, hop by hop, is covered in how to test a redirect. It is also worth loading the link specifically inside Instagram's or TikTok's in-app browser before you rely on the new domain for anything shared from those platforms, since in-app browsers occasionally handle a freshly issued certificate differently than Safari or Chrome do in the first hour or two after it goes live.