DNS for branded links: from record to working HTTPS

Choose the hostname without disrupting your website

A registered domain such as example.com can host a main website, email, and a link service on separate hostnames. go.example.com is a subdomain; example.com is the zone apex. Moving the apex could affect the main website, while pointing a dedicated subdomain typically leaves the apex alone. Inspect existing records and domain ownership before editing. Keep unrelated MX and TXT records intact.

A dedicated short domain can be useful when the short URL itself matters in print. Record who renews it and how long links must keep working. If the domain expires or its registration changes hands, a service account cannot keep printed or shared URLs alive.

Records solve different problems

A records map a name to an IPv4 address; AAAA maps to IPv6. A CNAME aliases one hostname to another and is common on subdomains. TXT can carry proof of control. The exact host labels, targets, and any apex alias or flattening support depend on the DNS provider and the link service. Copy values issued for your specific project; the examples here are schematic.

Four readiness checks

First query the authoritative DNS record and make sure the response matches the intended target. Second confirm that the service has accepted ownership verification. Third wait for a certificate that covers that exact hostname. Fourth make a real HTTPS request and confirm that the host routes to the expected site or redirect application. www.example.com and example.com are separate hostnames and may require separate validation.

The sequence explains a common failure: DNS resolves, yet the browser reports a certificate error or the hosting edge shows a generic site-not-found page. DNS has done its part, while TLS or the application's hostname binding is not yet ready. A redirect rule inside the application cannot run before the provider accepts the HTTPS request for that host.

DNS resolves → ownership verified → TLS certificate active → host routed → known path works

Propagation and recovery

DNS answers can be cached until their TTL expires, and certificate provisioning can have a separate delay. Check the authoritative answer as well as a recursive resolver; do not repeatedly change correct records while an issuance is pending. Preserve the old values so a failed move can be rolled back. Test a known link, an unknown path, and both schemes and hostname variants after cutover.

These are general DNS and hosting principles. Use only the exact record values issued by your live service when connecting a domain.

A failure table for real setup screens

If a DNS lookup still returns an old target, confirm that the domain's authoritative nameservers are the ones whose dashboard you edited. If the record is correct but TLS is pending, compare the provider's validation names and values character for character and allow its issuance process to finish. If TLS is active but the edge displays a generic site-not-found page, inspect the hostname-to-project binding. These are separate transitions; repeating the same DNS edit will not necessarily repair a routing binding.