Connecting an online shop or site builder

Module 7: Connecting external services · Reading time: 9 minutes

Learning objective: After this lesson, you'll be able to connect your domain to a platform such as Shopify or Wix without your email stopping.

Key concepts: A record on @, CNAME for www, clearing up conflicting records, AAAA, nameservers pointing to the platform, carrying mail records across, store mail records

Two routes

If you're building your website or online shop on a platform such as Shopify, Wix, Squarespace or Webflow, you want visitors on example.com and www.example.com to end up on that platform. Platforms almost always offer two ways to do this:

Most real-world problems happen with route 2: the website works immediately, but email stops, because the MX and other mail records were left behind at the old nameservers (lesson 2.1).

Route 1: adding records (Shopify example)

At the time of writing, Shopify provides these two records:

example.com.       3600   IN   A       23.227.38.65
www.example.com.   3600   IN   CNAME   shops.myshopify.com.

• A record on @. The bare domain can't have a CNAME, because your MX, NS and SOA records also live there (lesson 3.2). That's why the platform gives you an IP address here.
• CNAME for www. For www, a name is possible. The advantage: if the platform moves its servers, it only changes its own DNS and you don't need to do anything.

Other platforms work the same way, with their own IP address and target name. Wix, for example, provides an A record and a CNAME for www pointing to a Wix name. Always use exactly what the platform shows for your domain. The IP address can vary by platform, region or moment.

Clear up anything in the way

This is where things often go wrong. The platform wants its records to be the only ones for those names:

• A second A record on @. If there are two A records (the old IP of your web host and the new one from the platform), each visitor randomly gets one of the two. Half end up on your old site. Change the existing A record instead of adding a new one.
• An old AAAA record. If your web host also had an IPv6 address, there's often still an AAAA record on @ or www. Visitors with IPv6 (a large part of mobile networks) would then still reach the old server. If the platform doesn't provide an IPv6 address, remove the AAAA records for @ and www.
• An A record for www. A CNAME can't exist alongside another record with the same name. Remove the A or AAAA record for www first, then create the CNAME.
• A wildcard (*). A wildcard isn't a problem: the www name you create separately takes priority (lesson 3.3).

What you leave in place

Leave the MX records, the A record for mail (if you have one), SPF, DKIM and DMARC alone. An online shop doesn't need these to display your website. If you change them anyway, your mail stops.

If your website currently runs on a web host that also handles your mail, pay attention to your mail program. Does it list example.com or mail.example.com as the server, and did mail point to your web host via a wildcard? After the switch, example.com points to the platform, and then your mail program can no longer find your mailbox. In that case, create a separate A record mail pointing to the IP address of your mail server, or enter the server name your mail provider gives you in your mail program.

Certificate

The platform requests its own certificate (https) as soon as your records point to it. This only works once the old records have cleared from the caches (lesson 6.1). If it takes longer than a few hours, check whether an old A or AAAA record is still there, or a CAA record that doesn't allow the platform's certificate issuer (lesson 5.2).

Route 2: nameservers pointing to the platform

If you choose to point the nameservers to the platform, the platform manages your entire zone from that point on. Anything that was with your previous DNS provider no longer counts. Whatever you don't re-enter with the platform doesn't exist.

A real-world example, anonymised: a customer pointed their domain's nameservers to a site builder and then ordered mail from a different provider. The site builder had neatly created an MX record mail.example.com and an SPF record, but there was no A record for mail. So the name mail.example.com didn't exist (NXDOMAIN). Sending worked, receiving didn't: other mail servers didn't know where to deliver the mail. One A record for mail with the mail server's IP address fixed it.

If you use route 2, set up the following with the platform:

example.com.             3600   IN   MX    10 mail.example.com.
mail.example.com.        3600   IN   A     192.0.2.25
example.com.             3600   IN   TXT   "v=spf1 a mx include:spf.mailprovider.example ~all"
x._domainkey.example.com. 3600  IN   TXT   "v=DKIM1; k=rsa; p=..."
_dmarc.example.com.      3600   IN   TXT   "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

with the real values from your mail provider. If you use Microsoft 365 or Google Workspace, set up the records from lesson 7.1 or 7.2. Also don't forget any verification TXT records and subdomains you already had.

Before the switch, make a copy of your current zone (an export or screenshot), so you know what should be there (lesson 6.3).

Store mail: records for email sent from the platform

Online shops send order confirmations. To have these come from your own domain, the platform often asks for extra records, usually a few CNAME records for DKIM and sometimes a dedicated sender subdomain. These are additional records alongside your existing mail records. They have their own names and don't replace your MX. Watch out for duplicated domain names (www.example.com.example.com) and the trailing dot (lesson 2.2). If the platform sends on behalf of your domain, check whether it needs to be in your SPF record, and whether your DMARC policy allows it (lesson 7.4).

In practice: what it looks like in a panel

In the example panel My WebOké, you change the existing A record for @ on the DNS tab using Edit, remove the AAAA records, and use Add Record to create a CNAME www pointing to the platform's name. In DirectAdmin you do the same thing in DNS Administration; there, @ and * point to the package by default, so you create www separately.

In other panels, such as cPanel, Plesk, Cloudflare or your registrar's DNS screen, the buttons are named differently, but they're the same records. Some platforms offer an "auto-connect" button that sets the records via a link with your registrar; afterwards, always check that the old A and AAAA records are really gone.

Summary

• Route 1 (adding records) keeps your mail intact; route 2 (nameservers pointing to the platform) requires you to recreate all mail records with the platform.
• An A record goes on @, usually a CNAME on www. A CNAME on @ isn't possible.
• Change the existing A record instead of adding a new one, and clear up old AAAA records and an A record for www.
• Leave MX, SPF, DKIM and DMARC in place; watch out for a mail program that uses example.com as its server.
• Store mail records are additional records and don't replace your MX.

Quiz

Exercise

Exercise Z7.3: Recognising an online shop. See how a platform handles the "CNAME for www" route itself.

1. Look up the A record for shops.myshopify.com. Does the address start with 23.227.38.?
2. Pick an online shop or website you know that runs on a platform. Look up the CNAME record for www.<that domain> and the A record for the bare domain. Enter the domain name and both answers.

The check looks up the records live when you submit.

Exercise O7.3: Setting it up yourself in your practice zone. Set up your practice zone <code>.dnspractice.eu as if you were connecting it to an online shop platform, without breaking the mail. In the practice zone, you'll use the fake service shop-demo.dnspractice.eu; for your real domain, take the values from the platform's management screen.

1. Set an A record on <code>.dnspractice.eu to 203.0.113.10 (the "platform"). There should only be one A record on <code>.dnspractice.eu.
2. Make sure there's no AAAA record on <code>.dnspractice.eu or on www.<code>.dnspractice.eu.
3. Create a CNAME www.<code>.dnspractice.eu pointing to shops.shop-demo.dnspractice.eu. If there's an A record for www, remove it first.
4. Leave your MX records on <code>.dnspractice.eu in place. At least one MX must remain.

Further reading

These pages describe the steps in WebOké's panels (DirectAdmin and My WebOké). In other panels, it works the same way.

• Managing DNS records in My WebOké (with examples for CNAME, TXT, and external services)
• DirectAdmin guide 5.3: Adding or changing an A or AAAA record
• DirectAdmin guide 5.4: CNAME records and the trailing dot
• Use your own or external nameservers (such as Cloudflare) for your domain