DNS for Designers Who Pretend to Understand DNS
Let's be honest with each other. You've connected a domain to a Squarespace site before. You've logged into a registrar, changed some records, waited for it to work, and when it did, you moved on without fully understanding what happened. And when it didn't work, you changed something else, waited again, and hoped.
This isn't a criticism. DNS is one of those areas where most web designers know just enough to get by and not quite enough to troubleshoot confidently. It's also one of those areas where a client will ask you a question, something like "why is my email not working after we moved the domain?" or "how long until the new site is live?", and the honest answer is "I'm not entirely sure" but the professional answer needs to be better than that.
So here's DNS, properly explained, for people who design websites rather than manage servers.
What DNS Actually Is
DNS stands for Domain Name System, and its job is simple in concept: it translates human-readable domain names (yourbusiness.co.uk) into machine-readable IP addresses (104.156.81.229). Computers communicate using IP addresses. Humans communicate using words. DNS is the translation layer between the two.
When someone types your client's domain into a browser, the following happens in roughly this order. The browser checks its own cache to see if it already knows the IP address for that domain. If it doesn't, it asks the operating system's resolver, which checks its own cache. If that fails, the resolver asks a recursive DNS server (usually provided by the user's internet service provider or a public service like Cloudflare's 1.1.1.1 or Google's 8.8.8.8). The recursive server works its way through the DNS hierarchy: first the root servers (which know where to find .com, .co.uk, .org, and every other top-level domain), then the TLD servers (which know which name servers are authoritative for yourbusiness.co.uk), and finally the authoritative name servers (which hold the actual DNS records for that specific domain and return the IP address).
This entire process typically takes between 20 and 100 milliseconds. It happens before the browser even begins loading the website. And it happens for every single visitor, on every single visit, unless the result is cached from a previous lookup.
The Records That Matter
DNS records come in several types, and understanding the differences between them is what separates "I can connect a domain" from "I can troubleshoot domain problems."
A Records point a domain (or subdomain) to an IPv4 address. When Squarespace tells you to set your A record to a specific IP address, you're telling DNS: "when someone asks for this domain, send them to this server." An A record is the most direct type of mapping. One domain, one IP address.
AAAA Records do the same thing but for IPv6 addresses (the longer format like 2607:f8b0:4004:800::200e). IPv6 is the newer addressing standard, and while adoption is growing, most Squarespace configurations still rely primarily on A records.
CNAME Records point a domain to another domain, rather than directly to an IP address. When Squarespace asks you to set a CNAME for your www subdomain pointing to ext-cust.squarespace.com, you're saying: "when someone asks for www.yourbusiness.co.uk, go ask Squarespace's servers where to find it." The CNAME creates a chain: your domain points to Squarespace's domain, and Squarespace's DNS resolves that to an IP address. There's a critical rule here that trips people up: you cannot set a CNAME on a root domain (the bare domain without www). CNAMEs only work on subdomains. This is a DNS specification, not a Squarespace limitation, and it's why Squarespace requires an A record for the root domain and a CNAME for the www version.
MX Records control email routing. They tell DNS: "when someone sends an email to anything@yourbusiness.co.uk, deliver it to this mail server." MX records have a priority value (lower numbers mean higher priority), which allows you to specify backup mail servers. If you're using Google Workspace, Microsoft 365, Zoho, or any other email provider, your MX records need to point to that provider's mail servers. This is the record that breaks most often during domain migrations, because changing name servers or DNS providers can inadvertently reset or overwrite MX records, silently breaking email delivery.
TXT Records hold text strings used for verification and security. The most common uses are SPF records (which tell receiving mail servers which servers are authorised to send email on behalf of your domain), DKIM records (which provide a cryptographic signature to verify email authenticity), and DMARC records (which tell receiving servers what to do with email that fails SPF or DKIM checks). If your client's email is going to spam after a domain change, missing or incorrect TXT records are almost always the cause.
NS Records specify which name servers are authoritative for a domain. When you change name servers at your registrar (for example, from GoDaddy's default name servers to Squarespace's or Cloudflare's), you're changing the NS records. This is a big change, because it redirects all DNS queries for the domain to the new name server, meaning every other record (A, CNAME, MX, TXT) now needs to exist on the new name server or it simply won't resolve.
Propagation: What's Actually Happening
When you change a DNS record, the change doesn't take effect globally at the same time. This is "propagation," and it's the source of more client anxiety than almost any other technical process.
Here's what's really happening. Every DNS record has a TTL (Time to Live) value, measured in seconds. The TTL tells caching servers how long they can store that record before they need to check for an updated version. If your A record has a TTL of 3600 (one hour), then any DNS server that has cached your record will continue serving the old value for up to one hour after you make a change.
The reason propagation seems to take “up to 48 hours" (the number everyone quotes) is that different DNS servers around the world cache records at different times, and some servers respect TTL values more strictly than others. ISP DNS servers in particular can be slow to update, and some will cache records beyond their stated TTL. In practice, most changes propagate within two to four hours, and many take effect within minutes.
If you know you're about to make a DNS change, the professional move is to lower the TTL in advance. Set it to 300 (five minutes) a day or two before the change, let that lower TTL propagate, and then make your actual change. Caching servers will now check for updates every five minutes rather than every hour, and your change will propagate much faster. After the change has settled, raise the TTL back to a sensible value (3600 or higher) to reduce DNS lookup load.
You can check propagation status using tools like whatsmydns.net, which queries DNS servers in multiple geographic locations and shows you whether they've picked up the new record yet. This is infinitely more useful than refreshing the browser and hoping.
The Squarespace-Specific Setup
Squarespace offers two approaches to domain configuration, and understanding the difference matters.
The first approach is using Squarespace as your DNS provider. You transfer your domain to Squarespace (or register it there originally), and Squarespace manages all your DNS records. The advantage is simplicity: Squarespace automatically configures the A record, CNAME, and SSL certificate. The disadvantage is limited control: Squarespace's DNS management interface is basic compared to dedicated providers like Cloudflare or Route 53, and advanced configurations (like geographic routing or failover) aren't available.
The second approach is using a third-party DNS provider and pointing the records to Squarespace manually. You keep your domain at your existing registrar (GoDaddy, Namecheap, Google Domains, Cloudflare, or wherever it currently lives), and you configure the A record and CNAME to point to Squarespace's servers. The advantage is flexibility: you keep full control of your DNS and can manage email records, subdomains, and advanced configurations without limitation. The disadvantage is that you're responsible for getting the records right.
For most client projects, the second approach is better, because it keeps the domain and DNS at a provider with full-featured DNS management while letting Squarespace handle only the website. This separation also makes future migrations easier. If the client ever moves away from Squarespace, the domain and DNS are already independent, and the change requires only updating the A record and CNAME rather than transferring the entire domain.
The Email Problem
The single most common DNS issue in Squarespace projects is breaking email during a domain connection or migration. It happens like this: the designer changes the domain's name servers to Squarespace, or configures DNS records for the website without checking what email records already exist. The MX records either get overwritten, deleted, or left pointing to the old DNS provider's servers (which are no longer authoritative). Email stops arriving. The client doesn't notice for a day or two because they're focused on the new website. By the time they realise, they've potentially missed important messages.
The prevention is straightforward but requires discipline. Before touching any DNS records, document everything that currently exists. Every A record, CNAME, MX record, TXT record, and NS record. Screenshot the full DNS zone file. Then, after making your changes, verify that every record that existed before still exists (or has been intentionally removed). Pay particular attention to MX records and their associated TXT records (SPF, DKIM, DMARC).
If you're changing name servers entirely, you need to recreate all existing records on the new name server before the switch. Not after. Before. Otherwise there will be a window, potentially hours, where those records don't resolve, and email will bounce.
SSL and HTTPS
Squarespace provides free SSL certificates (via Let's Encrypt) for all connected domains. The certificate is provisioned automatically once your DNS records are correctly configured and propagated. This usually happens within a few hours of connecting the domain, but it can take up to 72 hours in rare cases.
During the provisioning window, visitors to the site may see a browser warning about an insecure connection. This is normal but alarming to clients, so the professional move is to connect the domain and verify SSL before telling the client the new site is live. If the SSL certificate doesn't provision within 24 hours, the most common causes are incorrect DNS records (the A record or CNAME isn't pointing to Squarespace correctly), conflicting CAA records (a CAA record on the domain that doesn't include Let's Encrypt as an authorised certificate authority), or an old SSL certificate from a previous provider that hasn't expired yet.
Subdomains
Squarespace supports connecting subdomains (shop.yourbusiness.co.uk, blog.yourbusiness.co.uk) as separate sites or as aliases pointing to the main site. Each subdomain needs its own CNAME record pointing to Squarespace.
A common use case is running a client's main website on Squarespace while their blog or shop lives on a subdomain pointing to a different platform (Shopify, WordPress, or a hosted app). This works because each subdomain is an independent DNS entry. The root domain and www can point to Squarespace while shop.yourbusiness.co.uk points to Shopify's servers. DNS doesn't care that they're different platforms. It just routes traffic to wherever the records say.
What to Do When It Breaks
DNS problems tend to present as one of three symptoms: the website doesn't load, the website loads but shows the wrong site (or a parking page), or the website loads fine but email doesn't work.
If the website doesn't load, check the A record and CNAME. Use dig yourdomain.com in a terminal (or an online dig tool) to see what the domain currently resolves to. If the IP address doesn't match Squarespace's servers, the A record is wrong. If the www version doesn't resolve at all, the CNAME is missing.
If the website shows the wrong site, the DNS records are probably still pointing to a previous host. Check propagation status. If the records are correct at the authoritative name server but wrong in some locations, it's a caching issue and will resolve with time.
If email doesn't work, check MX records first, then SPF and DKIM TXT records. Use a tool like MXToolbox to verify that the MX records point to the correct mail server and that SPF and DKIM are configured properly.
In every case, the approach is the same: check the records, verify they match what they should be, test with external tools rather than your own browser (which may be cached), and wait for propagation before assuming something is broken. Patience and methodical checking solve 90% of DNS issues. The other 10% usually require contacting the registrar or DNS provider directly.
DNS isn't glamorous. It doesn't appear in any portfolio and nobody's ever been impressed at a networking event by someone explaining CNAME records. But it's the invisible infrastructure that determines whether your beautifully designed website actually appears when someone types the address, and getting it right, every time, without breaking email or causing downtime, is one of the markers of a designer who really knows what they're doing.
Related Articles
