How to Set Up DNS Records the Right Way
Learn how to set up DNS records with clear steps for A, CNAME, MX, TXT, and more. Includes provider tips and fixes for common errors.
You've just opened your registrar dashboard to connect a domain, and the screen is asking for host, type, value, and TTL. That's the moment new users freeze, because DNS feels like a pile of jargon until you treat it as a few decisions in the right order. For how to set up DNS records, the job is simple enough, choose what you want the hostname to answer with, choose which host label it applies to, and decide how long resolvers should cache that answer.
A clean way to think about it is this, DNS sits between a name people remember and the destination a machine needs. If you're pointing a branded short-link domain at a service like 302.sh, you're not “doing DNS” in the abstract, you're deciding whether the root domain should answer one way, whether a subdomain should answer another way, and how quickly changes should show up when you edit them later. The part people get wrong most often is the host field, because that's where they accidentally enter the full domain when the provider wants only the label.
Table of Contents
- What DNS Records Actually Do When You Set Them Up
- The Record Types You Will Touch Most Often
- Adding Records in Cloudflare, GoDaddy, and Namecheap
- Pointing a Branded Domain With a Real Example
- TTL and Propagation Explained Without the Hand-Waving
- Common DNS Errors and How to Fix Them Fast
- Your DNS Setup Checklist and Next Steps
What DNS Records Actually Do When You Set Them Up
A DNS record is just a structured answer. Someone types a domain into a browser, or a service checks a domain for verification, and the resolver asks, “What should this hostname point to?” The record gives the reply, and the TTL tells caches how long they can hold onto that reply before asking again. Microsoft's domain setup flow sends admins through the DNS records page, then into a Manage DNS wizard, and finishes by verifying and authorizing the records at the registrar, which is a good reminder that DNS setup is both configuration and validation, not just a form fill. Microsoft's domain setup guidance
For a branded short-link domain, think of the decision like this, do you want the root domain to answer, or do you want a subdomain such as go to answer? A root domain usually uses an A record pointing @ to an IPv4 address, while a subdomain usually uses a host like www or another label. That distinction matters because the host field is not decoration, it's the selector that tells the provider which name in the zone gets the record. Microsoft and other provider guides show these exact field patterns, and their examples commonly use 3600 seconds or provider defaults such as 1800 seconds for TTL. Microsoft's DNS record setup guide
Practical rule: if you can only remember one thing, remember that the host field chooses which name, and the value field chooses what answer.
That's why DNS has multiple record types instead of one universal record. A website record, a mail record, and a verification token are not the same kind of instruction, even when they live in the same zone. Once you separate those decisions in your head, the screens stop looking random.
The Record Types You Will Touch Most Often
Different records solve different problems, and the confusion starts when people try to use the same one everywhere. For a branded short-link domain, the most common jobs are pointing a website, proving ownership, or supporting mail and service lookups. Azure's DNS quickstart shows the exact sequence for an A record, select the zone, open Record sets, click Add, set the name, type, TTL, and IP address, then create the record. That sequence is the model to keep in mind even if your provider labels the buttons differently. Azure DNS quickstart
DNS record types at a glance
| Type | Points to | Common use | Example value |
|---|---|---|---|
| A | IPv4 address | Root domain or host pointing to a server | An IPv4 address |
| AAAA | IPv6 address | Same as A, but for IPv6 | An IPv6 address |
| CNAME | Canonical hostname | Subdomain alias, branded links, service targets | Another hostname |
| TXT | Text string | Verification, SPF, tokens | A provider token or policy string |
| MX | Mail server | Email routing | A mail host with priority |
| SRV | Service endpoint | Specific services like SIP or Teams | Service name plus target |
The pattern is easy once you slow down. A records map a hostname to an IPv4 address, so they're the default when you need a root domain to point directly at a server. AAAA records do the same job for IPv6. CNAME records point one hostname to another hostname, which is why they're the right fit when a service gives you a canonical target instead of an IP address.
TXT records are the catch-all for ownership proof and policy text. Microsoft 365's flow uses TXT verification tokens, and it's also common for teams to leave a stale token behind after validation, which later blocks a re-check if the provider expects a clean value. MX records tell mail where to go, and SRV records are for services that need more than a simple name-to-target mapping. Microsoft's setup guidance also notes that TXT verification often depends on an exact provider-specific token, so a typo or forgotten cleanup can break the whole flow. Microsoft 365 DNS record guidance
Don't force one record type to do another record type's job. If the provider wants a CNAME, don't improvise an A record because it feels simpler.
For a short-link domain, the decision point is usually whether you're pointing a subdomain at a service target, or whether you're proving domain ownership with TXT. If you keep those two tasks separate, the rest of the zone becomes much easier to read.
Adding Records in Cloudflare, GoDaddy, and Namecheap
The clicks look different, but the work is the same, choose the right zone, choose the record type, fill the fields, save. Cloudflare, GoDaddy, and Namecheap all do that with slightly different labels, and that's where beginners trip. Cloudflare's flow is under DNS and Records, GoDaddy buries the practical work deeper in its DNS area, and Namecheap keeps the interface cleaner but still expects you to match the field names exactly.
Cloudflare
Open the domain, go to DNS, then select Add record. Choose A for the root if you're pointing the apex, or choose TXT if you're pasting a verification token. Fill in the Name, Type, and Target or value fields, then save.
The main Cloudflare quirk is the proxy toggle. Microsoft's general DNS instructions note that the equivalent record must be visible to the service doing the validation, and Cloudflare's own update steps tell you to make sure the orange cloud is turned off for a subdomain CNAME when an external service needs to see the true target. That's the part people miss when a record is technically present but still not working. HubSpot's DNS provider instructions for Cloudflare and general field mapping
GoDaddy
Go to My Products, then DNS. Find the record list, choose the right type, and pay close attention to the Host field, because GoDaddy is where people most often paste the full domain when they should only enter the subdomain label. For a branded short-link setup, that usually means entering only the go label, not the full name.
For a TXT record, paste the verification token exactly as provided, without adding spaces or extra punctuation. If you also see forwarding or redirect options, leave them alone unless the service specifically asks for them, because redirects are not a substitute for the record the provider requested. GoDaddy's DNS instructions for CNAME records show the same basic pattern, enter the subdomain in Host, paste the target in Points to, and save. GoDaddy DNS field pattern in HubSpot's provider guide
Namecheap
Open Advanced DNS, then click Add new record. Namecheap keeps the workflow tidy, but it still expects you to separate the Host, Value, and TTL fields properly. That makes it easy to move quickly, and just as easy to misread the TTL column and leave an old value in place.
Use A for an apex record and TXT for verification. If you're setting up a subdomain for a short-link service, Namecheap's CNAME flow is the cleanest option when the service gives you a hostname target. Namecheap's provider guide shows the same subdomain logic, enter the prefix in Host, enter the target in Target, and save the record. Namecheap DNS provider guide in HubSpot's documentation
The blunt rule here is simple. If the provider gives you a hostname target, use CNAME. If the provider gives you an IP address, use A. If the provider gives you a token, use TXT. When you keep those three decisions straight, the interface names stop mattering as much.
Pointing a Branded Domain With a Real Example
A small team setting up a short-link domain usually has one goal, make go.example.com behave like a branded front door for link management. That's a subdomain decision, not a root-domain decision, because a CNAME belongs comfortably at the subdomain level. 302.sh's custom-domain flow is built around that same idea, create a dedicated subdomain and point it at the service target with the record the provider gives you. 302.sh custom domain setup
The root-domain question comes up immediately, because someone always asks whether the apex can point the same way. The short answer is that a normal CNAME is for aliases, so at the root you either use a provider feature like ALIAS or ANAME if it exists, or you keep the branded short-link domain on a subdomain such as go. That's not a workaround, it's a design choice. If the service expects a canonical hostname and your registrar can't flatten a root CNAME, move the branding to the subdomain and stop fighting the zone file.
A sane setup for go.example.com usually has two records working together. One record points the subdomain at the short-link service, and another TXT record proves ownership when the service asks for it. If the TXT token is wrong, missing, or left behind after validation, the service may never finish the domain check even though the CNAME looks right.
The mistake people make here is trying to force the root to do a subdomain's job. If the service documentation says to use a branded subdomain, follow that instruction and keep the apex separate. That avoids ugly redirect hacks and keeps the zone easy to audit later.
A clean subdomain beats a clever root-domain trick when you need the setup to survive staff turnover.
For teams managing campaigns, this matters because the DNS record becomes part of the product setup, not an isolated admin task. The custom domain gives the links a branded face, and the TXT record gives the provider proof that you own the face you're attaching. If you're using a short-link platform for exactly this use case, the handoff from DNS to service settings should feel boring, not fragile.
TTL and Propagation Explained Without the Hand-Waving
TTL is the timer on your DNS answer. A resolver caches the result for that long, then asks again after it expires. That's why a record can be correct in the dashboard and still look wrong to someone on the other side of the internet. The cache is doing what you told it to do.
The practical planning move is to lower TTL to 300 seconds 24 to 48 hours before a planned change, then raise it again after the cutover. Provider examples commonly use 1800 seconds or 3600 seconds, which is a reasonable balance for stable records, while 86400 seconds is the kind of long cache window you reserve for records you almost never touch. One operational guide recommends the 300-second pre-flip because old caches expire sooner after the update, which reduces the time users keep seeing stale answers. Operational TTL guidance for DNS changes
How to think about the timing
If you change a record while the old TTL is still long, some resolvers will keep serving the old answer until their cache expires. That's not DNS failing, that's caching behaving correctly. A lower TTL narrows the delay window, but it also means more frequent lookups while the record is active, so you don't want to leave it low forever unless you have a reason.
The realistic part is that TTL is guidance, not a promise. Some resolvers and ISPs cache aggressively, and some clients use stale data longer than you'd like. That's why people talk about propagation windows in broad terms, and why you should test from more than one place instead of trusting the first browser refresh.
The cutover routine that works
Practical rule: lower the TTL first, wait for the old cache to age out, make the record change, then restore a normal TTL once the new answer is stable.
That sequence matters because it avoids the common trap where someone edits a record and immediately expects the whole world to catch up. For a branded domain, you want the cutover to be calm and boring. Lowering TTL is the only numeric control you really have for that, so use it on purpose instead of leaving the default in place by habit.
If you're running a short-link domain, this is the difference between a clean launch and a day of “it works on my laptop” complaints. The record can be right, the service can be right, and the user can still see the old destination until the cache clears. TTL is the delay knob.
Common DNS Errors and How to Fix Them Fast
Most failed DNS setups come down to a small handful of mistakes. The interface makes them look mysterious, but the root causes are boring, and that's good news. If you know what to look for, you can usually fix the problem without opening a support ticket.
The four failures that show up again and again
Overlapping records in the same host: If you have two records fighting over the same name, or a CNAME and an A record on the same host, the result can look like the record is ignored. The fix is to audit the existing zone and remove the conflict before saving the new record.
Wrong host field format: Some providers want
go, some want@for the root, and some want the field left blank. If you paste the full domain where the provider expects only the label, the record lands in the wrong place or not at all.Stale verification TXT: A verification token that was valid once can become a problem later if the provider expects a fresh check. Microsoft 365's setup flow uses TXT verification and notes that the token may need to be removed after validation, so don't leave cleanup until you've forgotten why the record exists. Microsoft 365 DNS verification flow
TTL left too high during a cutover: If the TTL stays long, half the world can keep using the old record while you think you've already finished the change. That's usually what people mean when they say propagation is “stuck.”
There's a simple diagnostic order that saves time. Check the authoritative zone first, then ask a public resolver what it sees, then compare that answer with what the service expects. If the authoritative record is wrong, fix the record. If the authoritative record is right but a public resolver is stale, wait for the cache window to expire.
The blunt truth is that DNS problems are usually self-inflicted. A wrong label, a conflicting record, or a rushed TTL change explains most of the pain. Once you train yourself to inspect the zone instead of blaming the browser, the debugging gets a lot shorter.
Your DNS Setup Checklist and Next Steps
Before you hit save, check type, host, value, TTL, and proxy state. After you save, verify the record from the provider's authoritative side, then check what a public resolver returns. If the setup included a verification TXT record, remove it once the provider confirms ownership, because forgotten tokens create needless clutter later.
For the next layer, email authentication records like DKIM and DMARC matter if the domain also sends mail, and root-domain aliases like ALIAS or ANAME matter if you insist on apex branding. If you're building a branded short-link domain, hosted TLS can remove one more moving part, which is why services like 302.sh can keep that side of the setup simpler for teams that just want the domain to work. 302.sh guide on creating a bit link
302.sh gives you branded short-link domains, custom slugs, and automatic TLS on Cloudflare's edge, which makes this DNS work useful instead of ceremonial. If you want a short-link setup that stays tied to a clean subdomain while you manage redirects and analytics in one place, visit 302.sh and wire your domain up the right way.