Custom Domain Link Shortener: Verifying Ownership and Going Live

Setting up a custom domain link shortener sounds like it should be complicated, and for a lot of people it's the one step that stalls an otherwise five-minute setup. In practice it's a handful of DNS records and a verification check, the same pattern used to connect a custom domain to almost any hosted service. The confusion usually isn't the difficulty of the steps — it's not knowing which record goes where, or why a domain that looks connected still shows as unverified an hour later.

Why you need a subdomain, not your root domain

Almost every custom domain link shortener setup uses a subdomain — go.yourcompany.com or links.yourcompany.com — rather than pointing the bare root domain at the shortener. There's a practical reason for this beyond convention: your root domain is almost certainly already pointed at your main website, and repointing it would take your site offline. A subdomain gets its own DNS record that lives alongside your existing root domain configuration without touching it. It also reads cleanly to anyone who clicks the link — go.yourcompany.com signals 'this is a link' in a way that yourcompany.com doesn't, and it keeps your primary domain's reputation with email and link-scanning systems separate from whatever volume of shortened links you're generating.

The two DNS records that actually matter

Almost every provider that supports custom domains for links asks for the same two things, even if the exact interface differs:

1. A CNAME record, pointing your chosen subdomain (go.yourcompany.com) at a target hostname the provider gives you. This is what actually routes traffic for that subdomain to the provider's infrastructure once it's live.
2. A TXT record, usually containing a unique verification token tied to your account. This proves you control the domain's DNS before the provider will start serving traffic for it — without this step, anyone could claim a domain they don't own.

Both records get added in whatever tool manages your DNS — that's your domain registrar (GoDaddy, Namecheap) or, more commonly for teams with any technical infrastructure, a DNS provider like Cloudflare or Route 53. If you're not sure which one controls your domain's DNS, check the nameservers listed at your registrar; whichever service they point to is where these records need to go, not necessarily where you originally bought the domain.

Why verification takes time — and how to stop it from stalling

DNS changes don't take effect instantly. Every DNS record has a TTL (time to live) that controls how long other systems are allowed to cache the old answer before checking again, and propagation across the wider DNS system can take anywhere from a few minutes to, in slower cases, several hours. This is the single most common source of frustration in this setup: someone adds the records correctly, checks back five minutes later, sees 'not verified,' and assumes something's wrong. Usually nothing is wrong — the record just hasn't propagated yet. Before troubleshooting further, it's worth checking the record directly with a DNS lookup tool rather than relying on the provider's dashboard alone, since a dashboard's verification check might be running on a delay separate from actual propagation.

A genuine misconfiguration usually looks different from a propagation delay: the record type is wrong (an A record where a CNAME was expected), the subdomain has a typo, or there's a conflicting record already sitting on that same subdomain from a previous integration. If a lookup tool shows nothing at all for the subdomain after an hour or more, that's the point to go back and recheck exactly what was entered, rather than continuing to wait.

SSL happens automatically, but not instantly either

Once DNS is verified, most providers automatically provision an SSL certificate for the new subdomain so links resolve over HTTPS rather than throwing a browser security warning. This step depends on the DNS verification completing first, so if verification is still pending, don't expect the certificate step to move — they're sequential, not parallel. This is also usually automatic and doesn't require anything from you beyond having verification pass; if a domain stays verified but insecure for more than a short window, that's worth flagging to support rather than assuming it will resolve on its own.

Common mistakes that cause a domain to never verify

• Adding the CNAME record on the root domain instead of the subdomain — most DNS providers treat these as entirely separate records, and a record added to yourcompany.com does nothing for go.yourcompany.com.
• Leaving an old A or CNAME record on the same subdomain from a previous project — most DNS systems won't let two conflicting records coexist on the same name, so the new one silently fails to take effect until the old one is removed.
• Copying the verification token with extra whitespace or a trailing character from the dashboard, which produces a TXT record that looks right at a glance but doesn't match what the provider is checking for.
• Using a DNS provider with proxying enabled by default (a common default on some providers) when a plain CNAME is expected, which can route traffic through an extra layer the verification check doesn't anticipate.
• Assuming a change is live immediately because it shows correctly in the DNS provider's own dashboard — that dashboard reflects what you entered, not what's actually propagated and visible to outside systems yet.

Multiple domains and what that's actually useful for

Some setups call for more than one custom domain — an agency managing links across several client brands, or a company running distinct product lines under different domains. Each domain typically goes through the same CNAME-and-TXT verification independently; there's no shortcut for verifying several at once, because DNS ownership has to be proven separately for each one. Once multiple domains are verified, most tools let you choose which domain a given link uses at creation time, which means the domain becomes a deliberate choice per link rather than a single fixed setting — useful when different audiences or different brands need to see a domain they specifically recognize rather than one shared default.

What changes once the domain is live

Once a custom domain is verified and active, every new sharing link you create can use it instead of a shared or generic domain. Existing links you created before adding the domain generally keep working on whatever domain they were originally issued on — switching domains after the fact usually isn't retroactive, since changing where an already-shared link resolves would break it for anyone who bookmarked or already has a copy of the old URL. Plan the domain setup before you start generating links you intend to share widely, not after.

Doing this in useopengraph

useopengraph's sharing links support custom domains as part of the core workflow — add your subdomain, drop in the CNAME and TXT records it gives you, and the domain moves to verified once DNS propagates, with SSL handled automatically after that. From that point on, every link you generate carries your own domain and full click analytics, without needing a separate shortener service or a workaround stitched together from a generic redirect tool. The DNS steps are the same regardless of provider — the difference is whether the rest of the workflow, from image generation to click tracking, lives in the same place as the domain setup or across three disconnected tools.

The whole process, DNS propagation aside, takes a few minutes of actual work. The waiting is DNS being DNS, not a sign anything's misconfigured — give it time before assuming you need to start over.