What "pointing a domain" actually means
There's no software to install and nothing to run on your own machine. Pointing a domain means editing a DNS record inside your domain's zone, hosted wherever your DNS is managed, and that one edit is the entire technical task. Everything else, the account setup on whatever service you're connecting to, the waiting, the verification, sits around that single change rather than adding more steps to it.
Whole domain or subdomain first
Decide this before touching any DNS settings, because it determines which record type is even available to you. An apex domain, the bare yourbrand.com with nothing in front of it, already has to carry NS and SOA records that standard DNS won't let a CNAME coexist with, so a CNAME on the apex is simply not allowed on most providers. A subdomain, go.yourbrand.com or link.yourbrand.com, has no such restriction and can always carry a CNAME. If you want the root domain itself connected to a service and your provider doesn't support an apex workaround, an A record pointed at a fixed IP is usually the fallback, when the service can give you one. The custom domain vs subdomain distinction itself is covered in more depth in what is a custom domain.
A record vs CNAME: what's actually different
An A record maps a name directly to a number, an IPv4 address. A CNAME maps a name to another name, which then gets resolved on its own. That difference matters more than it sounds like it should. If a service's underlying server IP changes without warning, and you pointed an A record straight at it, your domain breaks the moment that IP is retired, until you manually update the record yourself. A CNAME doesn't have that problem, because the service can change its own infrastructure behind the hostname freely, and your CNAME keeps resolving correctly without you touching anything. This is why almost every SaaS platform, link tools included, asks for a CNAME on a subdomain rather than a raw IP, and reaches for an A record only when there's a genuine fixed address involved.
| Record type | What it points to | Works on an apex domain | Common use |
|---|---|---|---|
| A | An IPv4 address | Yes | Pointing a domain directly at a server's fixed IP |
| AAAA | An IPv6 address | Yes | Same role as an A record, for IPv6 |
| CNAME | Another hostname | No, in standard DNS | Pointing a subdomain at a service's hostname, the most common setup for hosted tools |
| ALIAS / ANAME | Another hostname, flattened to an IP at lookup time | Yes, where the provider supports it | Faking CNAME-like behavior on an apex domain |
| TXT | Arbitrary text | Yes | Domain ownership verification, SPF records, other proof-of-control checks |
| MX | A mail server's hostname | Yes | Routing email for the domain, unrelated to web pointing but frequently confused with it |
Adding the record
Once you know the record type and have the exact target value from the service, the entry itself is short: the subdomain label as the host, most DNS editors expect just "go" rather than the full "go.yourbrand.com" since the zone already scopes to your domain, and the value the service gave you. Leave the TTL, time to live, at whatever default your provider sets unless you're planning ahead for a cutover, covered below. Add any TXT record the service also requested in the same zone, at the same time, so you aren't waiting through two separate propagation cycles for one setup.
DNS propagation: what's actually happening while you wait
"Propagation" makes it sound like your change has to travel and spread across the internet, and that's not really what's slow about it. The authoritative nameserver for your domain, the one your DNS provider runs, applies your edit almost immediately, often within seconds. What causes the delay is every recursive resolver sitting between you and that authoritative server, the ones your ISP or a public DNS service runs, that already had the old record cached. A resolver won't ask the authoritative server again until the old record's TTL expires, and only then does it fetch your new answer. If the record you're replacing had a 24 hour TTL, some resolvers keep serving the stale answer for up to a day after your change went live at the source, no matter how fast the authoritative side updated.
There's a trick that shrinks that window dramatically for a planned change. Lower the TTL on the existing record a day or two before you intend to make the real change, down to something like 300 seconds. Let that shortened TTL itself propagate out first, then make the actual switch. Every resolver's cache expires quickly the second time around, and the whole cutover finishes in minutes rather than the worst-case 24 to 48 hours most documentation quotes as a blanket figure.
Setting up a subdomain specifically
The mechanics are identical to any CNAME setup above: pick a short, obvious label, go, link, or similar, add it as a new host in your existing domain's zone, and point it at whatever hostname the destination service provided. Nothing about adding a subdomain touches your existing website or email configuration on the root domain, since each record lives independently in the same zone. If you're connecting a subdomain specifically to a link platform, the full walkthrough, including a certificate authority restriction that quietly blocks issuance and rarely turns up in a service's own support docs, is in how to use a custom domain for short links.
Where this goes wrong
- The host field was entered as the full subdomain including the root domain, when the editor already expected just the label.
- An existing A or AAAA record already sits on the same hostname. A single name can't carry a CNAME alongside another record type at the same time.
- The target value was copied with a missing or extra trailing period, which some DNS editors treat as a different value entirely.
- A CAA record on the domain restricts which certificate authority can issue for it, blocking certificate issuance even once DNS itself is correct.
- Your own device or browser has a stale local DNS cache from before the change. Test from a different network before assuming the record itself is wrong.
- The domain's nameservers were changed at some point and nobody updated where new records actually get added, so edits made at the registrar never take effect anywhere.
Registrar vs DNS provider: a distinction that trips people up
Buying a domain and managing its DNS are two separate jobs, and a lot of confusion during setup comes from assuming they're the same account. Every domain has a registrar, wherever you originally bought it, and a set of nameservers, which decide who answers DNS queries for that domain. Most registrars set themselves as the default nameservers, so for a lot of domains the two really are the same place. But it's common enough to move a domain's nameservers to a separate provider, for better DNS tooling, faster propagation, or a security layer the registrar doesn't offer, and once that happens, records added back at the original registrar simply do nothing. The DNS zone lives wherever the current nameservers point, not wherever the domain happened to be purchased. If a record you just added doesn't seem to be taking effect no matter how long you wait, checking which nameservers the domain currently uses is the fastest way to rule out editing the wrong place entirely.
Confirming it's actually live
Check the record with a direct DNS lookup rather than trusting what loads in a browser tab, since a browser can be serving a cached page or a cached DNS answer well after the real record has changed everywhere else. Once the lookup returns the new value consistently, confirm inside the destination service's own dashboard, most show a live verified or connected status once they've independently detected the record. The general process for testing that whatever you've pointed the domain at behaves correctly end to end, not just resolves, is covered in how to test a redirect.