How to connect a custom domain to your store

You bought the domain eleven days ago, you have typed it into the browser forty times since, and it still shows a registrar parking page with an advert on it. The store is live. The name is yours. The two facts have not been introduced to each other yet.

Here is the short version of how to connect a custom domain: you own a name, your store lives at an address, and DNS is the lookup table that sends one to the other. You edit two or three records at whoever you bought the name from, then you wait — not because anything is travelling anywhere, but because the old answer is sitting in caches that have to expire on their own schedule.

The order below matters. People who do step six before step three spend an afternoon debugging a certificate error that was never a certificate error.

What a domain and DNS actually are

A domain is not a thing you own outright. You lease it, usually a year at a time, from a registrar. Stop paying and it goes back on the market. That is the whole of it.

DNS — the Domain Name System — answers one question: what should I connect to when someone types this name? Your name has a set of records, each a single line answering one kind of question, and they live on nameservers that are authoritative for your domain. Your registrar provides nameservers by default, which is why the DNS editor is normally sitting in your registrar account.

These are the records that come up when you point a store at a name.

Two more terms you will see. TTL is time to live, in seconds — how long resolvers are allowed to remember an answer before asking again. Apex (or root, or bare) means the domain with nothing in front of it, and it matters because the original DNS rules do not allow a CNAME at the apex. Platforms work around this with A records or with their provider's own flattening, which is why the instructions for yourstore.com often differ from the instructions for www.yourstore.com.

The checklist

1. Decide the exact name you want customers to type

Apex (yourstore.com) or www? Either is fine. Pick one as canonical and make the other redirect to it, because if both serve the store independently you have split your traffic, your analytics and your search signals across two addresses. No name yet? Try the store name generator, and we wrote separately on whether you need a custom domain at all.

2. Lower the TTL first, if the name is already in use

This is the step everyone skips. If the domain currently points somewhere — an old site, a parking page, another platform — drop the TTL on those records to the lowest your registrar allows and wait a day before changing anything else. The real change then propagates in minutes rather than hours. Brand-new domain that has never resolved to anything? Skip this; there is nothing cached to expire.

3. Add the domain on the platform side first

Your store has to know the name is coming or it will not answer for it. Adding the domain in your dashboard tells the platform to accept requests for that hostname and to start the certificate process. On mAutomate a custom domain is included from the Grow plan at $79 a month, along with business email on the same domain — pricing has the full breakdown. Do this before you touch DNS.

4. Copy the records exactly as given

Your platform will show you the records to create. Type them exactly. Three mistakes account for most failures:

• Duplicated domains. Many registrars append your domain automatically, so www.yourstore.com in the host field becomes www.yourstore.com.yourstore.com. That field usually wants just www, or @ for the apex.
• Leftover records. An old A record sitting next to a new one sends some visitors to the old destination. Delete what you are replacing.
• A proxy or forwarding toggle left on. Registrar web forwarding or URL masking will quietly intercept the request before your store ever sees it.

5. Wait properly, and check with the right tool

Propagation is not distance, it is memory. Every resolver between your customer and your DNS holds its own copy of the old answer until the TTL runs out. Most changes settle within an hour or two; a domain that resolved to something else yesterday is always slower than one that resolved to nothing.

Your own browser is the worst possible test, because it caches aggressively and so does your operating system. Use a DNS lookup site, or dig yourstore.com in a terminal, and read what the authoritative nameserver says rather than what your laptop believes.

6. Let the certificate issue, then force HTTPS

Once DNS points at the platform, the platform can prove it controls the name and get an SSL certificate for it. This is automatic, and it is the part that appears to fail most often for one reason: a certificate cannot be issued until DNS is correct, so a certificate error almost always means step four is wrong rather than something being broken with HTTPS. Once it issues, check that every HTTP request redirects to HTTPS.

7. Add email records, separately and deliberately

Email does not follow the website. MX records control mail and are independent of the A and CNAME records that control the store. For [email protected] you add MX records plus the TXT records — SPF, DKIM, ideally DMARC — that let receiving servers verify mail genuinely came from you. Skip those and your order confirmations are far more likely to land in spam. If mail already runs on the domain, write the existing MX records down before you change nameservers: switching nameservers moves all records, mail included, and that is how people take their own email offline for a morning.

8. Update everything that still names the old address

Payment and shipping accounts, webhook URLs, ad platforms, social profiles, Google Search Console, anywhere you pasted a link. If you are moving from another platform, redirects from the old URLs decide whether you keep your search rankings — see how to migrate an ecommerce platform.

What a custom domain will not do for you

It does not make you rank. Search engines do not reward a name for existing, and a new domain has no history of any kind, which is occasionally worse than none at all for the first few months.

It does not make you look legitimate on its own. Customers read the whole page — photography, returns policy, spelling, whether the contact details are real. A good domain on a thin store is still a thin store.

It does not move your existing audience. Everyone who bookmarked the old address needs a redirect, and every printed card with the old name on it is now wrong.

And it does not give you email by itself. Those are two configurations on one name, and plenty of owners discover the gap when a customer replies to an order confirmation and the reply bounces.

If it still is not working

Nearly every failure is one of four things: the record is on the wrong host, an old record is still present, the platform does not know about the domain yet, or you are reading a cached answer. Work through them in that order before assuming the platform is at fault.