DNS for your web store.

What DNS is, and who is involved

Every website lives on a computer somewhere, and that computer is reached by a numeric address. Nobody wants to type numbers to reach a store, so the internet keeps a directory that matches names people can remember, like yourstore.com, to the addresses computers actually use. That directory is the Domain Name System, or DNS. When a customer types your domain into a browser, the browser looks it up in DNS, gets back an address, and goes there.

Your domain's entry in that directory is a short list of records. One says where the website is. Another says where email for the domain should be delivered. Others prove to outside services that you control the name. Every one of those records is something you, or someone you have hired, has control over, and "changing DNS" simply means editing that list.

Three roles that are easy to confuse

Most of the confusion around DNS comes from three roles that can be played by one company or by three. It is worth separating them before touching anything.

• The registrar is the company you pay each year to hold the domain name itself. Namecheap and GoDaddy are common examples, but there are many. The registrar records that the domain is yours and, critically, records which nameservers are in charge of its DNS. If you lose access to your registrar account, you lose control of the domain, regardless of where the store is hosted.
• The DNS host is the service that stores your list of records and answers when someone looks your domain up. By default this is usually the registrar, but it does not have to be. It can be a separate DNS provider such as Cloudflare, or it can be your store platform.
• The web host, or store platform, is where your store's pages actually live. It is what the DNS records point at. Shopify, BigCommerce, a WooCommerce host, and the rest all sit in this role.

Nameservers are the link between the first two. They are the note kept at the registrar that says "the DNS records for this domain live over there." Changing a record edits one line in the directory. Changing nameservers changes who keeps the directory. Those are very different actions, and the rest of this guide comes back to that distinction repeatedly.

Why this matters when you launch or move a store

A new store, or a store moving to a new platform, is not reachable at your domain until DNS says so. The step that puts the store live is a DNS change. How large a change depends on how you approach it. Pointing one or two records at the new platform is small and contained. Moving nameservers to the platform hands over everything attached to the domain, including your email. Understanding the difference is what lets you make the small change on purpose rather than the large one by accident.

The records a web store uses

A DNS control panel can look intimidating, but a store owner will only ever deal with a handful of record types. Each record has a name (the part of the domain it applies to), a type, a value, and a time-to-live, which is covered further down. Most control panels use "@" in the name field to mean the bare domain itself, with no "www" in front.

A and AAAA records: where the website is

An A record points a name at the numeric address of the server that should answer for it, and an AAAA record does the same for the newer, longer IPv6 address format. For a store, the A record on the bare domain is what sends yourstore.com to your platform.

CNAME records: one name is an alias for another

A CNAME says "this name is an alias for that other name, go look that one up instead." It is how www.yourstore.com is normally pointed at a hostname your platform gives you, so that if the platform changes its underlying addresses, your record keeps working. DNS rules do not allow a CNAME on the bare domain itself, which is why the root usually gets an A record and www gets a CNAME. Some DNS hosts offer a workaround for the root under names like ALIAS or ANAME, and your platform's documentation will say whether to use one.

MX records: where your email goes

MX records tell every mail server in the world which servers accept email for your domain, and in what order of priority to try them. They have nothing to do with the store and everything to do with whether orders@yourstore.com receives anything. Because they live in the same list as the store records, they are the most commonly broken thing in a domain move.

TXT records: verification and email authentication

A TXT record is plain text that other services read. Two uses matter for a store. The first is verification: a platform, a search console, or an email tool gives you a code to publish as a TXT record to prove you control the domain. The second is email authentication. SPF is a list of which servers are allowed to send mail as your domain. DKIM is a signature your mail provider adds so receiving servers can confirm a message is genuine. DMARC is a policy telling receivers what to do when a message fails those checks. Together they are what keep your order confirmations and replies out of spam folders, and the guide to email authentication covers how to check whether yours are set up correctly. Some mail providers publish DKIM as a CNAME rather than a TXT record. It needs to survive the move either way.

You may also see NS records, which list the nameservers themselves, and occasionally SRV or CAA records added by a specific service. Leave anything you did not add and do not recognize in place, and find out what it does before removing it.

Nameservers: changing one record versus changing everything

When a platform offers to "connect your domain," it usually gives you two routes. One is to add a couple of records at your current DNS host: an A record for the bare domain and a CNAME for www, both pointing at the platform. The other is to change your nameservers at the registrar to the platform's nameservers. They sound similar. They are not.

Changing a record

Editing a record at your current DNS host changes one line. Your email records, your verification records, and anything else attached to the domain are untouched, because the same DNS host is still answering for everything and you only altered the entries that say where the website is. This is the smaller, contained change, and for pointing a store at a new platform it is almost always sufficient.

Changing nameservers

Changing nameservers moves the whole directory. From the moment the change takes effect, the records at your old DNS host are no longer consulted by anyone. Only the records at the new nameservers count, and if a record was not recreated there, it no longer exists as far as the internet is concerned. Nameserver changes do not carry your records with them, and anything you did not copy across is gone the moment the switch happens.

This is why the route that looks simpler so often ends with a dead inbox. The platform's nameservers will answer correctly for the store, because the platform creates those records for you. They will not know about your email unless you tell them.

Should your registrar or your store platform manage DNS?

This is the question behind the two routes above, and it deserves a direct answer rather than "it depends."

For most store owners, keeping DNS at the registrar, or at an independent DNS host, and pointing individual records at the store platform is the better arrangement. The reasons are practical:

• Your email, your verification records, and any other services attached to the domain stay independent of the store platform. Nothing about your inbox depends on your store account.
• Switching platforms later means editing the two records that point at the store, not rebuilding your entire DNS configuration somewhere new.
• If you ever close the store, change your mind about the platform, or have an account problem with it, the domain and everything else attached to it are unaffected.
• A dedicated DNS host tends to support more record types and settings than a store platform's built-in DNS, which matters as soon as you add email marketing, a help desk, or any other service that asks you to publish records.

Letting the platform manage your nameservers is the simpler setup, and that is a real advantage, not a trivial one. The platform creates the records the store needs, keeps them correct if its own infrastructure changes, and there is one less control panel to understand. The tradeoff is that more of your infrastructure is now tied to one vendor. Your email configuration lives inside your store platform, leaving the platform later means moving all of your DNS again, and you are limited to whatever DNS features the platform chooses to offer.

The platform-managed route is a reasonable choice when the domain carries nothing but the store: no email on the domain, no other services, and no plans to change platforms soon. Even then, every existing record must be recreated at the platform before the nameservers change.

Platforms change what they support and what they recommend, and the wording in their setup screens changes with it. Rather than relying on this guide or any other for the current details, check your platform's own documentation for how it currently connects a domain and which route it recommends, then apply the tradeoff above to your own situation.

Moving nameservers to a new host, safely

If you have decided a nameserver change is the right move, whether to a store platform, a dedicated DNS provider, or a new registrar's DNS, the process is the same. It is not technically difficult. It is a sequencing exercise, and the order is what protects you.

1. Find your registrar, and make sure you can log in. If you are not sure who it is, a public WHOIS or RDAP lookup on your domain will name the registrar. Then confirm you personally can sign in to that account, that the recovery email is one you control, and that the domain is not sitting in a former developer's or agency's account. Domains registered under someone else's account are one of the most common surprises in a store migration, and they need to be sorted out before anything else.
2. Check the renewal date. If the domain is due to renew within the next month or two, renew it now, and confirm the payment method on file is current. A domain expiring in the middle of a move takes down the store, the email, and everything else at once.
3. Write down every record you currently have. Export the zone if your DNS host offers it. If not, screenshot every record and type them into a document: name, type, value, priority for MX records, and TTL. Pay special attention to MX, to every TXT record, and to any CNAME you do not recognize, which is usually an email marketing tool, a help desk, or a link tracker that will quietly stop working if it is left behind. This inventory is your safety net.
4. Get the exact nameserver values from the destination. The new DNS host will give you two or more hostnames to enter at the registrar, typically in the form ns1.example-host.com. Copy them exactly. A typo in a nameserver takes the entire domain offline, not just the website.
5. Recreate every record at the destination before you change anything. The new host's records have no effect until the nameservers point there, so you can build the complete set in advance with no risk. Work through your inventory line by line: MX first, then SPF, DKIM, and DMARC, then the store's A and CNAME records using the values the platform gives you, then every verification and service record. When you are done, compare the two lists. They should match, apart from the store records that are deliberately changing.
6. Lower your TTL a day or two ahead. Every record carries a time-to-live, the number of seconds other servers are allowed to remember an answer before asking again. Defaults vary from a few minutes to a full day. Lowering the TTL on your records to a few minutes means cached answers expire quickly once you make the real change, so visitors move to the new answers within minutes rather than over the course of a day. The lower value has to be in place for at least as long as the old TTL before it does any good, which is why a day or two in advance is the usual advice. This is what people mean by "propagation": not a single event, but caches all over the internet expiring on their own schedules.
7. Verify your email records before you switch. See the warning below. This is the step that is skipped most often and regretted most.
8. Make the change during a quiet period, then watch it. Enter the new nameservers at the registrar. Then check, from an outside connection or with an online DNS lookup tool, that the domain resolves to the store, that the MX records are answering correctly, and that a test email sent from an outside account arrives. Send an outbound test as well, and confirm it lands in an inbox rather than a spam folder.
9. Leave the old records alone for a few days. For a nameserver change specifically, there is one cache you cannot shorten: the record at the domain registry that says which nameservers are in charge, which can be remembered for up to two days. Lowering your own TTLs still helps, but it is also the reason the old host must keep answering correctly during the overlap. If the old host is still serving correct records, the overlap is invisible to visitors. Do not delete the old zone or cancel the old DNS hosting until the change has fully settled.

Common mistakes

Almost every DNS problem in a store move is one of a short list.

• Breaking email with a nameserver change. The nameservers move, the store comes up, and nobody notices that the MX records were left behind until a customer mentions their email bounced. Recreate MX, SPF, DKIM, and DMARC at the new host before the switch, and test from an outside account afterwards.
• Not lowering the TTL in advance. With a day-long TTL, some customers see the old store and some see the new one for up to a day after the switch, and any mistake takes just as long to undo. Lower it a day or two before, and raise it again once everything has settled.
• Letting the domain expire mid-move. An expired domain takes down the website, the email, and every service attached to it at the same moment, and recovering it is slow and not always possible. Check the renewal date and the payment method before starting.
• Changing the wrong kind of record. Changing nameservers when a record change was all that was needed is the classic version, but it has relatives: putting a CNAME on the bare domain where an A record belongs, updating www but not the bare domain so the two go to different places, or editing a TXT record when the platform actually asked for a CNAME. When a platform gives you a value to add, look at what type it says and add exactly that type.
• Not controlling the registrar account. If the domain sits in a former developer's account, you cannot change nameservers, cannot renew it, and cannot recover it if they stop responding. Get the domain into an account you own before the move, not during it.
• Deleting the old records too early. Cancelling the old DNS hosting the same day as the switch means anyone still using a cached answer gets nothing at all. Leave it for a few days.

---

Once the roles are clear, DNS stops being mysterious: a registrar that holds the name, a DNS host that keeps the records, and nameservers that say which host that is. Most store launches need two records changed. The ones that need more need the sequence above, with the email check treated as non-negotiable.

In practice, the DNS change is the last step of a platform migration or a new store launch, and it is the step that decides whether launch day is quiet. When Archer Technology runs a migration or a store setup, the domain work is part of the plan rather than an afterthought: the record inventory, the email verification, the TTL change ahead of time, and the switch itself, timed with the redirects and the rest of the cutover. If you would rather have that handled alongside the move, book a call and we will start with where your domain and DNS currently live.