DMARC, SPF and DKIM Setup on Squarespace (Including Domains Migrated from Google Domains)

Where your DNS records actually live

DNS is not in your website settings. It is in the domains dashboard, which is a separate area of your Squarespace account.

Go to account.squarespace.com/domains. Click the domain name. Click DNS in the side panel, then DNS Settings. Scroll past the preset records Squarespace manages for you until you reach the section called Custom Records. Click Add record.

At that point Squarespace asks you to enter your current password again, or to pass a two-factor check if you have 2FA enabled, then click Continue. The prompt fires when you click Add record, not when you open the panel, which catches people out.

If your domain came over from Google Domains, this is the answer to "where did my DNS go." Squarespace bought the Google Domains registrations in September 2023 and finished migrating everyone through 2024. Your records came across intact. They now live in this Custom Records panel and nowhere else. There is no Google-branded console left to log into for these domains, and the old Google Domains API is gone.

• Squarespace defaults and preset records sit above Custom Records. Leave them alone.
• Custom Records is where SPF, DKIM and DMARC go.
• A separate section further down is called Domain Nameservers.

The Name field trap

Squarespace automatically appends your domain to whatever you type in the Name field. The panel does not show you this. It does not warn you. It just does it.

So if your DMARC guide tells you the host is _dmarc.yourdomain.com and you type that in, Squarespace creates a record at _dmarc.yourdomain.com.yourdomain.com. The panel looks correct. Nothing errors. Every DMARC checker on the internet reports that you have no DMARC record, and you spend an afternoon convinced the tools are broken.

Type only the part that comes before your domain.

• SPF: Name field = @ (the @ symbol means the domain itself)
• DMARC: Name field = _dmarc
• DKIM for Google Workspace: Name field = google._domainkey
• DKIM for Squarespace Email Campaigns: Name field = squarespace._domainkey

The exact SPF and DMARC records

Both go in the Type dropdown as TXT. Squarespace's help articles talk about "DMARC records" as if they were a record type, but the dropdown does not offer one. DMARC is a TXT record.

SPF tells receiving mail servers which servers are allowed to send mail using your domain. Set Type to TXT, Name to @, and put your value in the Text field. For Google Workspace that is: v=spf1 include:_spf.google.com ~all

You get one SPF record per domain. If you already have one, edit it rather than adding a second. Two SPF records is a permanent error condition, not a warning. Merge the include: statements into a single line.

DMARC tells receiving servers what to do when a message fails SPF and DKIM, and where to send reports about it. Set Type to TXT, Name to _dmarc, and Text to: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Start at p=none. That is monitor mode. It changes nothing about how your mail is treated and it starts the reports flowing. Read a few weeks of reports, confirm every legitimate sender is passing, then move to p=quarantine and later p=reject. Jumping straight to p=reject is how people lose their invoices.

DKIM: Squarespace does not generate the key

This trips up a lot of people. Squarespace does not host email. It never has. There is no DKIM key to generate inside Squarespace for your regular mail, because Squarespace is not sending it.

DKIM adds a cryptographic signature to outgoing messages so a receiving server can confirm the message really came from your domain and was not altered. The key is generated wherever your mail is actually sent from. Squarespace's only job is to publish the public half of it.

Google Workspace: in the Google Admin console, go to Apps, then Google Workspace, then Gmail, then Authenticate email. Click Generate new record, choose 2048 bit, and keep the default selector google. Google hands you a TXT value. Add it in Squarespace as Type TXT, Name google._domainkey. Then go back to Google and click Start authentication. If you skip that last click, the record is published and DKIM is still off.

Microsoft 365 works differently. It gives you two CNAME records rather than a TXT record. Add them under Custom Records with Type CNAME and the selector names Microsoft provides, again without your domain on the end.

Squarespace Email Campaigns is the one case where Squarespace does send on your behalf. In the Email Campaigns settings panel, add your sender details, then click Authenticate under Sender details. It gives you a CNAME with host squarespace._domainkey pointing to squarespace-domainkey.squarespace-mail.com, plus a _dmarc TXT record. The panel shows "Domain is unauthenticated" until it resolves. That message disappearing is your confirmation.

Letting someone help without giving up your password

Squarespace has proper delegated access for domains. It is called a domain manager invite, and it is the correct way to let a consultant, agency or IT contractor work on your DNS.

Open your domains dashboard, click the domain, click Permissions, then click Invite domain manager. Enter their name and email address. They get an email titled "Domain Manager Invitation" and accept it with their own Squarespace login. If the email does not arrive, use the menu next to their name under Invites sent and choose Copy invite link.

A domain manager can manage domain settings and DNS, toggle auto-renew, connect the domain to a site, and add or remove other domain managers. They cannot delete the domain, cannot reactivate an expired domain, and cannot manage a connected Google Workspace account. That is a sensible amount of access to hand a contractor.

To revoke it: Permissions, click the three dots next to their name, choose Remove domain manager. Do this the day the work finishes.

Site contributor roles are a completely separate system and they do not grant DNS access. Making someone an Administrator on your Squarespace website does not let them touch DNS on a standalone domain. Domains migrated from Google Domains usually have no Squarespace website attached at all, so contributor roles do not exist for them in the first place. The domain manager invite is the only route.

Quirks that reject perfectly valid records

Squarespace enforces a 255 character limit on TXT values. Go over it and you get "Enter valid data" with no explanation of which rule you broke. A 2048 bit DKIM key runs to roughly 400 characters, so this bites regularly.

Squarespace's own documentation contradicts itself here. The email article says it supports DKIM and SPF up to 2048 bits without splitting. The troubleshooting article says 255 characters maximum. Assume you will hit the limit and know the fix.

The fix is to split the value into chunks under 255 characters, wrap each chunk in its own pair of double quotes, and put all the chunks in a single record separated by spaces. Resolvers stitch them back together. Do not create two separate TXT records for one DKIM selector. That breaks DKIM rather than fixing it.

A trailing period will be rejected. Strip any full stop from the end of a value you pasted.

"This name record is already in use" means you have a conflicting record at the same host name. Find the old one and edit it instead of adding another.

Custom records default to a four hour TTL, which is how long resolvers cache the answer. Squarespace lets you set a custom value from the dropdown. If you are about to make a change, drop the TTL first, wait for the old one to expire, then change the record.

Squarespace says allow 24 to 48 hours to propagate. In practice most changes are visible in minutes. Do not panic at hour two. Do not accept silence at hour 48 either, because that means something is wrong.

Check it properly, not with a green tick

A dashboard tick means Squarespace saved a string. It does not mean the record is correct or that any mail server accepts it. Query DNS directly from outside Squarespace.

On Mac or Linux, run these three commands, substituting your domain and your DKIM selector:

dig +short TXT yourdomain.com @8.8.8.8

dig +short TXT _dmarc.yourdomain.com @8.8.8.8

dig +short TXT google._domainkey.yourdomain.com @8.8.8.8

On Windows, use nslookup -type=TXT _dmarc.yourdomain.com 8.8.8.8

Pointing at 8.8.8.8 queries a public resolver rather than whatever your machine happens to use, so you see what the rest of the internet sees. If a lookup returns nothing, try it again with your domain doubled on the end, for example _dmarc.yourdomain.com.yourdomain.com. If that one returns your record, you hit the Name field trap.

Then do the real test. Send a message from your actual mail account to a personal address at a different provider. Open the raw message source and find the Authentication-Results header. You want to see dkim=pass, spf=pass and dmarc=pass. That header is a receiving mail server telling you it accepted your setup. Nothing in any control panel carries the same weight.

What Squarespace cannot do

Being straight about the limits saves you time later.

There is no DNS write API. None. You cannot script record changes, cannot manage Squarespace DNS from Terraform, and cannot run an ACME DNS-01 challenge for automated certificate renewal. Every change is a manual click behind a reauthentication prompt.

For domains migrated from Google Domains, Squarespace does not support Dynamic DNS. Any DDNS records survived the migration as static A or AAAA records frozen at their last known IP address, and they no longer update. Squarespace also does not support the ACME DNS API, so certificates issued that way keep working until they expire and then stop renewing.

There is no bulk management. If you hold a dozen domains, you edit each one individually.

Squarespace support will show you where the Add record button is. Their documentation states plainly that their scope of support for DNS is limited and they will not advise on whether your record content is correct.

And there is no DMARC report aggregation. The address in your rua tag will receive raw XML attachments from every large mail provider on earth, which is unreadable without a parser.

If you need automation, DDNS or DNS-01 renewals, the honest answer is to move DNS hosting to a provider that has an API while keeping Squarespace as your registrar. Point the Domain Nameservers section at Cloudflare or similar and rebuild the records there. That is a real option and it is often the right one.

If you would rather not do this yourself

Everything above is genuinely doable in an afternoon. If you followed it and your test message came back with three passes, you are done and you do not need us.

We do this work for businesses that would rather hand it off, or that got partway through and found something that does not behave the way the documentation says it does. We work through a domain manager invite, which you issue and revoke yourself. We do not accept passwords, government IDs or card numbers, and there is no situation in which we need them. We cannot promise any particular deliverability outcome, because inbox placement depends on your sending history and content as much as your DNS. What we can do is get the records correct, confirm them against live DNS and real message headers, and show you the evidence.