Do not begin the domain cutover with an unfinished store. First review the generated draft page by page, complete the online store launch checklist, and confirm who controls the domain account. Custom domains are available in Setka: add the intended domain, follow the exact record instructions shown for that store, and confirm that the product reports the expected connected and primary states before publishing. Never reuse DNS values from another store, an article, or an old support message.

That sequence keeps the technical change small and the business decision visible. DNS can take time to update across resolvers, so plan a monitored cutover.

Understand the small part of DNS that matters

A domain such as example.com is the human-readable address. DNS is the public directory that tells browsers where that address should go. You manage its records through the DNS provider authoritative for the domain; that may be the registrar that sold it or a different service.

For this launch, four terms matter:

  • Hostname: the address being connected, such as the root domain or a www subdomain.
  • Record type: the DNS provider’s method for pointing that hostname elsewhere. Use only the record type Setka currently shows for this store.
  • Target: the generated destination shown inside Setka for this store. Copy it from the current product screen; never reuse a value from an article, screenshot, another store, or an old support message.
  • TTL and caching: DNS answers may remain cached for a period. Changing a record does not force every resolver and device to see the new answer at once.

You do not transfer ownership of the domain to Setka by changing this record. The merchant retains the registrar and DNS accounts, renewal responsibility, and control over other records such as email. That is useful control, but it also means the merchant owns the accuracy of the DNS change.

Prepare the domain account before touching records

Sign in to both the registrar and the active DNS provider before launch day. Confirm that the domain is renewed, account recovery works, and multi-factor authentication will not depend on an unavailable teammate. Identify one person authorized to edit DNS and another who can verify the change.

Capture the current DNS zone before editing. Record the exact hostname, type, value, TTL, and proxy state of the record you intend to replace. Do not delete unrelated MX, TXT, verification, or mail-authentication records. If an existing website uses the domain, decide what must happen to it and preserve anything needed for rollback.

Also decide which customer-facing form should be primary. Ask Setka how the counterpart hostname is handled for the current store rather than inferring aliases or redirects. This is a routing decision, not a branding detail: ads, email, packaging, profiles, and search listings should eventually use one consistent primary address.

The controlled DNS flow

[Approved store preview]
          |
          v
[Add owned hostname in Setka]
          |
          v
[Copy the target Setka shows for this store]
          |
          v
[Create the indicated DNS record at the active provider]
          |
          v
[Wait for the product's connection check] ---> [Wrong or stale answer? Compare with current instructions]
          |                                      ^
          v                                      |
[Confirm the expected connection state]
          |
       connected
          v
[Choose primary when ready]
          |
          v
[Publish approved draft explicitly]
          |
          v
[Test public domain and purchase path]

The diagram deliberately contains no fixed target. The value is generated in the product and may be store- or environment-specific.

Connect the domain in Setka

Use the current in-product workflow rather than a copied walkthrough:

  1. Add the hostname you own in Setka.
  2. Read the record instructions generated for that domain and store. Copy the hostname, record type, and target exactly as shown.
  3. At the active DNS provider, change only the indicated record. Preserve unrelated mail, verification, and service records.
  4. Return to Setka and confirm the domain reaches the expected connected state. If it does not, compare the authoritative DNS answer with the current instructions before changing anything else.
  5. Confirm the intended domain is shown as primary before publishing.

Do not repeatedly change a correct record just because one device still sees an old answer. Check the authoritative record first, then compare results from a separate network or resolver. Propagation depends on previous caching and provider behavior; no universal completion time is responsible to promise.

Do not infer certificate readiness, redirects, or fallback behavior from a DNS response alone. Ask Setka for the current fallback and removal procedure before the cutover, and record it in the launch plan.

Preview first; publish deliberately

A connected domain is not proof that the store is ready. It proves only that routing has reached the required state. Before publishing, inspect the generated draft in Setka across the homepage, categories, representative product pages, cart, and checkout entry. Switch between desktop and mobile preview, use long product names and real prices, add required images, and verify navigation rather than admiring only the first screen.

Setka makes this separation useful: it creates the storefront draft inside the commerce platform, lets the merchant preview pages and device widths, and requires an explicit Publish action. That is preferable to treating a DNS change as approval of whatever happens to be in a theme. The merchant still owns the truth of product information, payment and shipping settings, domain records, final review, and the decision to go live. If payment setup is part of this launch, complete the checkout and Stripe payments guide before the cutover.

Use a launch-day cutover checklist

Run this list from one shared record. Assign every check to a named person and note the time, result, and evidence.

Before changing DNS

  • The store passed desktop and mobile preview using representative products.
  • Prices, stock assumptions, shipping, tax settings, contact details, policies, cart, and checkout path were reviewed.
  • The approved draft/version is unambiguous; nobody is still editing it during cutover.
  • Registrar and authoritative DNS access work, and the existing relevant record is documented.
  • The desired primary hostname and any intentional alias are agreed.
  • The hostname, record type, and target generated for this store are visible in the current product.
  • A rollback owner, monitoring window, and customer-support contact are assigned.

Connect and publish

  • Create only the DNS record currently indicated for this store.
  • Confirm the saved record exactly matches Setka’s current instructions.
  • Confirm Setka reports the expected connected state; if not, compare the record with the current instructions.
  • Open the connected hostname on a separate network and check that the browser reaches the intended store securely.
  • Confirm the intended connected hostname is primary when the team is ready for the public address to change.
  • Preview the approved draft once more, then use the explicit Publish action.

Validate the public store

  • Load the primary hostname with and without a trailing path, including category and product URLs.
  • Test any counterpart hostname or fallback path that Setka has confirmed for this store.
  • Check homepage, navigation, category, product, cart, and checkout entry on desktop and a real phone.
  • Complete the controlled payment and order tests appropriate to the launch plan.
  • Confirm images, styles, scripts, and downloadable policies load without mixed-domain errors.
  • Verify analytics and consent behavior if configured, then record the baseline.
  • Check the primary URL, canonical behavior, crawl controls, and sitemap using the ecommerce SEO checklist.

Monitor after publication

Stay available after the change. Test from more than one network, because the team office may be seeing a cached answer that differs from customers’ results. Watch domain status in Setka, failed navigation, checkout and payment outcomes, incoming orders, support messages, and analytics anomalies. Recheck the domain later in the monitoring window rather than declaring success after one homepage load.

If the custom domain fails, preserve evidence before changing several things at once: note the hostname, time, network, visible error, Setka state, and authoritative DNS answer. Compare the record with the current generated instructions. If launch risk is unacceptable, ask Setka for the current fallback or removal procedure rather than improvising a new target or deleting unrelated records. Do not advertise a certificate timetable or infer that a redirect, certificate, or third-party proxy will solve the problem.

For the broader sequence around catalog, storefront, settings, and launch, return to how to build an online store. Domain connection is one controlled stage in that system, not the moment all readiness questions disappear.

Connect only after the preview passes

Setka keeps the generated storefront, preview, publishing action, and custom-domain workflow in one operating path. That reduces handoffs, but it does not remove merchant responsibility for DNS ownership and launch approval.

Finish the preview and checkout checks, agree on the primary hostname, and prepare the monitored cutover record. Then connect the custom domain—and publish only the draft your team has approved.