New Domain Purchase Checklist: Nameservers, Records, Email, and Locking It Down

After a new domain purchase, the checklist that matters is not branding or social handles, it is DNS: lock the domain, turn on auto-renew and WHOIS privacy, point the nameservers, set the A/AAAA and CNAME records for the site, add MX records only if you are receiving mail there, and verify every piece resolves before you call it done. None of this is optional busywork; skipping the lock or the auto-renew is how domains get lost to a lapsed renewal or a hijack far more often than to any technical failure.

Most ‘what to do after buying a domain’ posts are marketing checklists: match your social handles, trademark the name, hire a designer. Useful eventually, and beside the point on day one. Day one is DNS and account security, the part a non-technical checklist skips because it assumes a hosting company did it for you. Here is the actual sequence, in the order that avoids a stalled site or a locked-out registrar account.

Table of contents

• Lock the account before anything else
• Point the nameservers
• The records that make a site live
• Mail, and why it should not live on the web host
• Verify it end to end before you call it done
• Mistakes that show up in the first week
• What to do only after the technical checklist is done
• How this fits the rest of the stack
• FAQ

Lock the account before anything else

The domain is worth nothing to you if someone else can transfer it out. Three settings, checked in the registrar dashboard, before you touch DNS:

• Registrar lock (transfer lock) on. Prevents an unauthorized transfer to another registrar. Turn it off only when you intend to transfer the domain yourself.
• Two-factor authentication on the registrar account, not just the domain. Most domain thefts start with a compromised registrar login, not a DNS attack.
• Auto-renew on, with a payment method that will not silently expire. A domain that lapses and gets re-registered by someone else is far more common than any technical failure.

WHOIS privacy (sometimes called ID protection) is worth turning on at the same time if it is not the default — it keeps your registrant contact details out of the public WHOIS record, which is otherwise scraped constantly for spam and social engineering targets.

Point the nameservers

Nameservers decide who answers DNS queries for the domain — the registrar’s own DNS, your host’s DNS, or a third-party DNS provider. Most registrars default to their own nameservers, which is fine until you need something they do not support, like advanced record types or fast propagation on change. A third-party DNS provider is worth it mainly for DNSSEC support or record types your registrar’s built-in DNS lacks.

If your host manages DNS for you, point the nameservers at the values they give you and stop managing records at the registrar entirely — running two DNS providers for one domain is a common source of records mysteriously not taking effect, because you edited the one nobody is actually querying.

Changing nameservers takes effect once the registry updates, usually within a few hours, though resolvers that already cached the old nameservers hold onto them until their TTL expires.

The records that make a site live

Once the right DNS is in charge, the records themselves are short:

• A or AAAA on the apex, the bare domain, pointing at your host’s IP address.
• CNAME on www, pointing at the same target as the apex, or at a hostname your host provides.
• A redirect so one of example.com and www.example.com is canonical and the other forwards to it — pick one and be consistent, for SEO as much as for clarity.
• CAA, naming the certificate authority allowed to issue for the domain, which closes off issuance by anyone else.

For a static site or a service on a platform, the host usually publishes both the IP for A/AAAA and a CNAME target for www on the same settings page — copy them exactly rather than reusing an IP you found for a different service, since hosting IPs get reassigned. Drop the TTL to a few minutes before you plan a change and put it back up afterward. Nothing propagates in the sense people mean; resolvers just hold onto answers until the TTL says to ask again.

Mail, and why it should not live on the web host

MX records tell the world where mail for the domain gets delivered. Set them only if you are actually receiving mail there — a domain with no MX record and a null SPF record is a cleaner, safer state than one half-configured for mail nobody checks.

If you are receiving mail, route it through a dedicated mail provider rather than the same box serving the website. Add SPF, DKIM and DMARC records as that provider instructs; skipping them is the single most common reason legitimate mail from a new domain lands in spam. For a small team, a hosted mail provider is a fixed monthly cost that is smaller than the time spent chasing why a password reset email is not arriving.

Verify it end to end before you call it done

Do not trust the registrar dashboard’s saved confirmation. Check from outside your own network.

dig +short example.com A
dig +short www.example.com CNAME
dig +short example.com MX
curl -I https://example.com

The dig calls confirm the records actually resolve to what you set; curl -I confirms the site answers over HTTPS with a valid certificate. If any of them return nothing, the record has not propagated yet, the nameservers have not switched, or there is a typo in the value — check in that order.

Mistakes that show up in the first week

The same handful of mistakes account for most new-domain support tickets.

• Editing records at the registrar while the host manages DNS. Nothing changes because nobody is querying the registrar’s DNS anymore.
• No redirect between the bare domain and www. Half your links work and half return nothing, depending on which one someone typed.
• Skipping CAA. Not a security hole on day one, but a cheap insurance record against certificate issuance you did not request.
• WHOIS privacy left off by default. The registrant email ends up on every spam list within a week of the domain going live.

What to do only after the technical checklist is done

Trademark checks, social handle matching, and business registration are real tasks, and they are the ones every marketing-oriented checklist leads with. Do them after the domain actually resolves to something, not before — a perfectly branded domain that returns nothing when someone types it in is a worse first impression than a plain one that loads. Register domain variations only if brand protection genuinely matters at your scale — most projects do not need five misspelling variants sitting unused and costing a renewal fee each year.

How this fits the rest of the stack

None of this checklist is dramatic, which is exactly why it gets skipped — until the domain that should have taken twenty minutes to point at a live site is still showing a registrar parking page a week later. Once the records are set and the redirect is consistent, the RunxBuild hosting calculator is the next stop for sizing what the domain will actually point at: a static site, a service, or both. Custom domains and certificates on RunxBuild covers custom domains on the hosting side, and the dashboard is where the record gets added once you are ready.

Useful related references:

• Registering a Domain Name Cheaply Without the Renewal Trap
• Domain Transfer Authorization Code: What It Is and How to Get It
• Authorized Domains: The Production Checklist Most Apps Forget
• Custom domains and certificates on RunxBuild

FAQ

What is the first thing I should do after a new domain purchase?

Lock the account, not the DNS. Turn on the registrar transfer lock, two-factor authentication on the registrar login, and auto-renew with a payment method that will not lapse. Domains are lost to expired renewals and compromised logins far more often than to any DNS misconfiguration.

Should I use my registrar’s nameservers or my host’s?

Whichever one actually manages your DNS going forward, and only one — running both means editing records somewhere nobody is querying. If your host provides DNS management, point the nameservers there and stop touching records at the registrar. Third-party DNS is worth it mainly for DNSSEC or record types your registrar’s built-in DNS lacks.

What DNS records does a new domain need for a website?

An A or AAAA record on the apex pointing at your host, a CNAME on www, a redirect making one of the two canonical, and a CAA record naming the certificate authority allowed to issue for the domain. MX records only if the domain receives mail.

How do I check that my domain’s DNS is actually working?

Run dig +short example.com A and dig +short www.example.com CNAME from a terminal, then curl -I https://example.com to confirm the site answers over HTTPS. If any command returns nothing, the record has not propagated, the nameservers have not switched yet, or there is a typo in the value.

Do I need WHOIS privacy on a new domain?

Yes, unless you have a specific reason to publish your contact details. Without it, your registrant email and address are scraped from the public WHOIS record almost immediately and end up on spam and social-engineering target lists. Most registrars offer it free or nearly free.