Squarespace Domains: Point Your Domain to AWS

What Squarespace Domains is

Squarespace Domains is the domain registrar that Squarespace runs. Google Domains customers were moved to Squarespace after Squarespace bought the Google Domains registrations; Google's own support page describes the change and points remaining questions to Squarespace. If your domain came from Google, its registrar is now Squarespace, and that is the account where DNS is edited unless you moved DNS elsewhere.

Two things are easy to mix up. The registrar is the company that holds the registration. The DNS provider is the service that answers queries for the domain. A Squarespace-registered domain can have its DNS served by Squarespace, or by another provider such as Route 53, which is the setup this guide covers.

Where the DNS settings live

Squarespace documents the path in its Help Center article "Edit your domain's DNS records". Open the domains dashboard, click the domain, choose DNS in the side panel, then click the pencil on a record to edit it. Each record has a Type, Name, Priority, TTL and Data field. Squarespace says a record change can take 24 to 48 hours to appear, and that custom records default to a 4-hour TTL.

DNS editing in Squarespace is only available when the domain is registered with Squarespace or connected through Nameserver Connect. If the domain uses nameservers at another provider, the records must be edited there. Check which case you are in before you look for the fields. The Squarespace menu labels can change, so use the Help Center article as the reference for current wording.

Option A: keep Squarespace DNS and add a CNAME

This is the smallest change. Leave the nameservers alone, and add a CNAME record for the subdomain that points at the load balancer hostname your app exposes. The hostname is the DNS name AWS gives the load balancer, not an IP address.

Type:  CNAME
Name:  app
Data:  k8s-prod-appingre-1234567890.eu-west-1.elb.amazonaws.com
TTL:   4 hours (14400 seconds, the Squarespace default)

Why the apex is the limit

A CNAME cannot sit on the bare domain, and it cannot coexist with other records at that name. An A record is the usual alternative for the root, but it needs an address that does not change. An ALB does not give you one, so an A record to its current IP will break when AWS replaces the load balancer nodes. Squarespace lists ALIAS among its web hosting record types, so test a root ALIAS with dig before you rely on it. If it does not resolve correctly, use option B for the root and keep the subdomain on option A.

• Use option A for app.example.com or www.example.com when you do not need the bare domain.
• If you need the bare domain to redirect to www, set a redirect in your host or CDN, not an A record to a load balancer.
• Use the same TTL on every record in the subdomain if you change several at once.

Option B: move nameservers to a Route 53 hosted zone

Delegation hands the whole zone to AWS. Route 53 then answers for the bare domain as well as every subdomain, and it can hold alias records to an Application Load Balancer, which is the normal setup for an app on EKS. Route 53 documents the same sequence for a domain registered elsewhere: create a public hosted zone, then point the registrar at the zone's name servers.

1. Create the hosted zone

In the Route 53 console, choose Create hosted zone, enter the domain (for example example.com), keep the type as Public hosted zone, and create it. Route 53 does not host a bare top-level domain such as .com, so the name must include the registrable domain. The zone comes with four NS records and an SOA record.

2. Recreate the existing records first

A new zone starts with only the records you create. Copy every record from the Squarespace DNS page into the Route 53 zone before you change anything else. Mail is the one that hurts: MX, SPF (a TXT record), DKIM, DMARC and any verification TXT records for Google Workspace or other services. Add the web records too, so the site keeps working while you wait.

3. Check DNSSEC

If DNSSEC is on for the domain at Squarespace, turn it off before you change nameservers. A signed domain carries a DS record at the parent zone that matches the old keys. After the switch, resolvers can fail to validate the new zone and return SERVFAIL for the whole domain. Confirm the DNSSEC setting is off, then move on.

4. Update the nameservers at Squarespace

Copy the four NS values from the hosted zone. In Squarespace, open the domain, find the nameserver setting, and replace the existing entries with the four Route 53 values. Save, then leave it alone while it propagates. Squarespace's Help Center has the current steps for this screen, and they can differ from this summary.

5. Add the alias record for the app

Once the zone is authoritative, create an A record with Alias turned on in the hosted zone. Choose the load balancer as the target. Route 53 does not charge for alias queries to an ELB load balancer. Use the same record for the bare domain and for the subdomain if you want both.

# Confirm the zone is authoritative for the domain
dig NS example.com +short

# Confirm the app answers on the root and the subdomain
dig A example.com +short
dig A app.example.com +short

Option C: transfer the registration away

You only need a transfer if you want the registration itself at another registrar. Changing DNS does not require it. If you do move the registration, the ICANN Transfer Policy applies. A domain that was newly registered, or whose registrant details changed, is locked for 60 days. Registrars can apply that lock, and a transfer request made during the window is refused.

• Check the lock first. In the Squarespace domain settings, look for the domain lock toggle. If it cannot be turned off, the 60-day window is still running.
• Turn off the lock, then request the transfer authorization code (auth code). The code is emailed to the registrant contact address, which may differ from your login.
• Give the code to the gaining registrar, and approve the transfer from the confirmation the registrar sends.
• Confirm the DNS plan before you start. If the zone stays at Squarespace, the DNS will keep working. If DNS moves to Route 53, do option B first.

Exact menu labels and fees come from Squarespace and the gaining registrar, and they change. Read the current Squarespace Help Center article on transfers before you start, rather than relying on a copied procedure.

Verify the change from outside

Do not trust the dashboard alone. Ask public resolvers what they return. Propagation is uneven, so query more than one resolver and note the TTL in each answer.

# Which name servers are authoritative right now?
dig NS example.com +short
nslookup -type=NS example.com 8.8.8.8

# Subdomain CNAME or alias target
dig CNAME app.example.com +short
dig A app.example.com +short

# Follow the chain from the root servers down
dig +trace example.com

# Mail records, to confirm nothing was lost in the move
dig MX example.com +short
dig TXT example.com +short

Troubleshooting

• NS answers still show the old provider: the registrar change has not propagated. Check the Squarespace nameserver setting, then wait out the TTL.
• SERVFAIL on the whole domain after a nameserver change: DNSSEC is still on. Disable it at the registrar and retry.
• Mail bounces or stops after the move: an MX, SPF, DKIM or verification TXT record was not copied. Compare dig MX and dig TXT output with the old zone.
• Subdomain resolves to the wrong address: a stale CNAME or A record is still in the old DNS. Remove it so only one record type exists at that name.
• Browser still shows the old site: the local resolver or browser has the old answer cached. Test with dig against a public resolver first.

How SeaGit uses the domain

SeaGit runs apps on Amazon EKS in your own AWS account, and its domain feature handles the DNS side for apps you deploy there. It does not connect to Squarespace. The steps that matter are the same as option B above, with SeaGit doing the record writes after you delegate.

• You add a DNS provider. For this setup that is AWS Route 53. Cloudflare and PowerDNS are the other options.
• You add the domain to SeaGit as a hosted zone under that provider, then set the domain as the root domain of an environment.
• If the domain is registered at Squarespace, you delegate it by setting the Squarespace nameservers to the Route 53 zone, as in option B. SeaGit does not change them for you.
• Once the domain is active, the cluster add-on external-dns writes an address record for each exposed deployment, plus a TXT ownership record. The add-on cert-manager issues a wildcard certificate for the domain with a DNS-01 challenge in the same zone.
• You do not create those per-deployment records by hand. Custom domains need a paid plan. The free plan uses a managed *.segt.io subdomain.

The SeaGit documentation for domains covers the provider setup, the delegation step and the lifecycle, including detaching a domain from an environment before you destroy it. Start there: /docs/domains.

Frequently asked questions