--- type: blog title: "CNAME or A Record? Read Your Store's DNS Instructions" description: "Connecting a store domain? Understand A records, CNAMEs, root domains, and record conflicts before changing DNS or replacing a working email setup." date: "2026-10-11" lastModified: "2026-10-12" authors: "Runner AI Team" tags: ["DNS", "Store Launch", "Store Operations"] featured: false readTime: "5 min read" thumbnail: "https://storage.googleapis.com/runner-blog/blog/cname-or-a-record/cover" thumbnailAlt: "An A record card pointing to a server address beside a CNAME card pointing to another name that leads to a server, under a small storefront" seo: title: "CNAME or A Record: Which Does Your Store Domain Need?" description: "Choose a CNAME or A record for your store domain by reading the host's requirements. Check root-domain limits, record conflicts, and ownership before launch." --- Use an A record when your hosting platform supplies an IPv4 address. Use a CNAME when it supplies another hostname as the destination. The choice between a CNAME or A record is not a preference setting: it depends on the exact name you are connecting and the host's supported configuration. For a store, preserve working email records and separate DNS routing from ownership verification. An instruction to add `www` can look almost identical to an instruction for the root domain. Copying the right value into the wrong record type will not connect either one. Start by matching three fields: the record's type, its host or name, and its destination value. ## CNAME or A record: what does each value mean? An A record maps a hostname to an IPv4 address. A CNAME makes one hostname an alias of another hostname. [DNSimple's comparison of A and CNAME records](https://support.dnsimple.com/articles/differences-a-cname-records/) explains both mechanisms and gives a real example of a CNAME chain used for its own blog. - **A:** An IPv4 address, such as `192.0.2.10`. Resolve this name to that address. - **CNAME:** Another hostname, such as `storefront.example.net`. Follow that name to find its address. - **AAAA:** An IPv6 address. Resolve this name to that IPv6 address. - **TXT:** Text supplied for a specific purpose, often including an ownership challenge. These are illustrative values, not Runner AI connection settings. Do not paste them into your DNS provider. Get the destination from the current instructions for your own store. A CNAME value is not a page URL. It does not include `https://`, a path such as `/products`, or a checkout link. DNS connects names; it does not select individual pages. An A record needs the supplied IPv4 address, not the hostname that happens to resolve to that address today. That last distinction matters with managed hosting. Replacing a requested CNAME with an IP address you found through a lookup creates a separate configuration to maintain. The provider can change the addresses behind its hostname without updating your copied A record. Follow the supported destination rather than reverse-engineering a substitute. ## Why the root domain and www can need different records `example.com` is the root, or apex, of the domain. `www.example.com` and `shop.example.com` are separate hostnames. An A record can be used for a root domain or a subdomain; it is not restricted to the root. A standard CNAME has a different constraint: it cannot share its exact name with ordinary records such as A, MX, or TXT. The root of a DNS zone already needs records such as SOA and NS. That makes a normal CNAME unsuitable there. Some DNS providers offer ALIAS, ANAME, or CNAME flattening to provide hostname-based routing at the root. These are provider-specific mechanisms, not permission to ignore the hosting instructions. For example, [Cloudflare's CNAME flattening documentation](https://developers.cloudflare.com/dns/cname-flattening/) says it resolves the target and returns the final IP address instead of the CNAME. A DNS panel can therefore show a CNAME-style configuration while a public lookup returns an address. Check the provider's documented behavior before declaring the record missing. Your host might request an A record for `example.com` and a CNAME for `www.example.com`. Another supported setup may differ. Neither hostname automatically proves that the other is connected. Also, pointing both names to a host does not itself establish which one redirects to the other; redirects are a separate website or hosting configuration. ## Check for conflicts without breaking business email Before changing DNS, save a record of the current zone and identify which service each record supports. Your storefront, business email, and email-authentication services can share the domain while using different record types and names. Connecting a store is not a reason to delete everything in the zone. The CNAME restriction applies to the **exact hostname**, not every name beneath the domain. An A record and an MX record can coexist at `example.com`, while a CNAME at `www.example.com` can route the website. By contrast, adding a CNAME at a name that already has an A record creates a conflict that needs a deliberate correction. Use this review before saving: 1. Confirm you are editing the active DNS provider, which may differ from the registrar where you bought the domain. 2. Match the requested host exactly. Check whether the provider expects a short name such as `www` or the full hostname. 3. Check existing records at that same name and identify their owners before removing a conflict. 4. Enter the supplied type and value. Keep email and unrelated verification records intact. 5. Compare the saved record with the original instruction, then check the hosting platform's status. If you cannot explain an existing record, ask the person who manages the domain before deleting it. A working storefront is not a successful change if order notifications or support email stop arriving afterward. ## A correct DNS record is not a complete store connection DNS routing answers where a hostname resolves. Domain ownership answers whether the platform has accepted your right to use it. HTTPS and the customer journey add further checks. These are related, but passing one does not prove the others. Runner AI separates domain attachment from ownership verification. Its [custom-domain guide](https://www.runnerai.com/docs/en/guides/storefront-and-publishing/custom-domains) explains where to find the exact records and how to complete the supported connection process. Use that guide for Runner-specific actions, rather than copying example settings from an article. For the short version of those steps, see [connect your custom domain in Runner AI](./launch-online-store-10-minutes-no-code#step-5-connect-your-domain-5-minutes) in our store launch guide. It covers the free Runner address, a domain you already own, and buying a domain through Runner. If routing is correct but an ownership challenge is still required, waiting cannot supply the missing record. If records are correct but different networks return old and new answers, use the [DNS propagation troubleshooting guide](./dns-propagation-time) to decide whether to wait or investigate further. After the domain connects, verify the store at the final address. Open a product, add it to the cart, and follow the checkout path using the payment provider's supported test method. Runner's [live-store and checkout guide](https://www.runnerai.com/docs/en/guides/storefront-and-publishing/live-store-and-checkout) covers that acceptance check. If you are still evaluating the platform, review [Runner AI's ecommerce hosting workflow](https://www.runnerai.com/features/best-ecommerce-hosting) before starting a domain move. ## Related questions ### Why use a CNAME instead of an A record? A CNAME lets your hostname follow another hostname's address resolution. This is useful when a managed service owns and changes the destination addresses. It does not make a CNAME universally better. Use the type your host supports for the exact name, and check whether the DNS provider imposes a same-name conflict or root-domain limitation. ### Can I have a CNAME and an A record together? Yes, at different names within the same domain. You might have an A record at `example.com` and a CNAME at `www.example.com`. A standard CNAME cannot coexist with an A record at the exact same hostname. Review the conflicting name rather than deleting unrelated records across the zone. ### Is a CNAME a website redirect? No. A CNAME tells DNS to follow another hostname; it does not issue an HTTP redirect or change the address shown in the browser. The destination host still needs to serve your requested hostname correctly. If you want visitors to move from the root to `www`, configure and test that redirect separately. ### Should I choose an A record because it is faster? Do not change a supported hosting configuration on that assumption. A CNAME can involve additional resolution steps, but caching and provider behavior affect the result. Correct routing and a maintainable destination come first. Choose a CNAME or A record from the host's requirements, not an unmeasured promise of a faster store.