What does Squarespace set up automatically when I buy Google Workspace through it?

Only the MX records. Squarespace's signup guide and MX article both say the MX records are generated automatically for domains on its default nameservers — no Squarespace page claims it adds SPF, DKIM or DMARC for Google Workspace, in any signup path. Those three are manual: publish Google's SPF (Squarespace's panel merges multiple SPF rows into one published record, a Squarespace-only behaviour), generate DKIM in the Google Admin console and add the TXT (Squarespace supports DKIM records up to 2048 bits without splitting), and publish your own DMARC — carefully, because Squarespace's panel permits only one _dmarc record and up to four features want to write it: registration defaults, Email Campaigns (which puts a TXT with a per-domain unique code there), email forwarding rules, and you.

What happens if I cancel Google Workspace in Squarespace?

Cancelling does not end the Workspace account — it automatically transfers it to Google, ending the reseller relationship, with a 7-day Google billing grace period. It is one-way: the account cannot be reinstated through Squarespace or transferred back, and there is no direct hop from Squarespace to another reseller. Your mail is not deleted. Squarespace's support scope is similarly bounded while you stay: it covers the Workspace panel in Squarespace, billing, signup and user management — 'for anything else, contact Google.' Also note the inversions Squarespace documents: cancelling your website leaves Workspace billing running, while losing the domain subscription leaves billing alive but mail dead, because there are no active MX records.

Google Workspace · Squarespace · Full setup

Google Workspace through Squarespace: automatic MX, manual everything else

First published 20 October 2026 · Automation scope and panel behaviour from Squarespace's support pages read in full; record values inherited from Google's documentation (Packs #7/#43). Sibling of Workspace on Namecheap — the two hosts behave almost oppositely, as the tables below show.

Do not fix the wrong thing first. “Squarespace set up my Workspace” means exactly one thing in Squarespace's own text: the MX records generated automatically. No Squarespace page claims SPF, DKIM or DMARC are added — in any path. The gap is invisible (mail flows; authentication silently doesn't), and it surfaces as spam-folder placement and DMARC failure months later. This guide scopes every path, then finishes the job.

The three doors — know which one you walked through

Door	What automates (per Squarespace/Google text)	What remains yours
A — Bought Workspace through Squarespace	MX records auto-generate (Squarespace nameservers). The panel's three default anti-spam TXTs remove themselves when your custom email records land	SPF, DKIM, DMARC — all manual
A′ — Domain bought during Google signup (Squarespace as Google's registrar partner)	Google configures DNS; mail works immediately (Google's text) — per-record scope for SPF/DKIM/DMARC is never enumerated	Verify all three by readback; assume nothing
B — Google-direct Workspace, DNS at Squarespace	Google's connect flow “automatically adds a verification CNAME and multiple MX records” (Squarespace's words) — with a documented “Conflicting DNS record” failure if old MX/DKIM/SPF/forwarding records stand in the way (remedy: delete them first)	SPF, DKIM, DMARC — all manual

Signup preconditions are a trap of their own (Door A): existing MX records, an existing verification TXT, an existing Workspace account, or a Titan email subscription all disqualify through-Squarespace signup. The recovery is Google's free-up-the-domain form (24–48 hours; users get renamed) — not cancelling things at random.

The manual rungs (Squarespace panel grammar)

Panel grammar, from Squarespace's docs: names are relative — “Leave your domain off the end. We add it for you.” Fields: MX = Name / Priority (0–255) / Mail Server; TXT = Name / Text; CNAME = Name / Data. Squarespace states a TTL only for SRV (default 4 hours); its MX/TXT instructions have no TTL step — don't hunt for one.

MX (if not already automated): Add preset → “Google Workspace MX” (domain → DNS; you'll re-authenticate with password/2FA). Squarespace describes the contents only as “the necessary records” and prints both end states as normal (“Most likely, you'll have five records… Or, you'll have one MX record”) — so read back which set you got (Google's current set is the single smtp.google.com, Article #43; ignore the doubled-G typo “SMTP.GGOOGLE.COM” printed in one Squarespace paragraph — the same article spells it correctly elsewhere). If the preset errors: delete the whole preset block and re-add (Squarespace's recovery).
SPF — Squarespace inverts the usual rule. Everywhere else, two SPF records = PermError. Squarespace's panel merges multiple SPF rows into one published record — so add Google's include as a row, but first check what rows already exist (preset + custom rows display separately while publishing merged). Two cautions from Squarespace itself: stray quotation marks can break resolution, and a “Custom records not saved” error is fixed by delete-and-re-add, not editing.
DKIM — the easy rung here. Generate in Google's Admin console (2048-bit, selector google), add the TXT at google._domainkey. Squarespace states SPF/DKIM records are supported “up to 2048 bits, so you usually don't need to split them” — the exact inverse of Namecheap's undocumented manual split (Article #43). Paste whole; read back.
Start authentication in Google's console (the Records alone don't sign anything — inherited Google mechanics).

The _dmarc seat has four claimants

Squarespace's panel permits one _dmarc record — and four writers want it, each documented on a different Squarespace page: registration defaults, Email Campaigns (its verification puts a TXT carrying a per-domain unique code at _dmarc, alongside its CNAME squarespace._domainkey → squarespace-domainkey.squarespace-mail.com — which, note, does not collide with Google's DKIM TXT), email-forwarding rules, and you, publishing real DMARC policy. Squarespace's own merge procedure, followed in order:

If a preset/verification _dmarc TXT exists, note its unique code exactly, then delete the preset block.
Re-add as a custom TXT at _dmarc combining both: your DMARC policy (baseline v=DMARC1; p=none; rua=…) with the Campaigns verification code preserved as Squarespace's procedure specifies.
Read back: exactly one _dmarc answer, carrying both the policy and the code — then Campaigns stays verified AND DMARC reports flow (climb per Article #4).

The reseller boundary (read before you need it)

Fact (Squarespace-documented)	Consequence
Support scope: Squarespace covers the panel, billing, signup, user management — “for anything else, contact Google.” DNS support “can't offer technical information about how DNS records work with other services”	Authentication troubleshooting lands with Google/yourself — this guide, essentially
Cancel = automatic transfer to Google, 7-day billing grace, one-way, no reinstatement via Squarespace, no direct hop to another reseller. Mail not deleted	“Cancel” is a migration button wearing a scary label — and an irreversible one
No downgrades through Squarespace; monthly/annual cycle can't switch after signup	Plan changes route through the Google transfer
Cancel the website → Workspace keeps renewing. Lose the domain → billing lives, mail dies (no active MX)	The two subscriptions fail in opposite directions — audit both before cancelling either
Nameserver connect removes all CNAME records and some A records	Connecting an outside domain by nameservers can break existing email before setup begins; Squarespace documents a DNS-connect alternative. Finish email first, or reconnect records after

Verify

Readbacks: the MX set you actually received (one or five — both can be right; a blend is wrong); ONE published SPF (the merged result, checked publicly, not row by row); google._domainkey TXT matching the console; ONE _dmarc carrying policy + any Campaigns code.
Consoles: Google shows Gmail activated + DKIM “Authenticating email”; test mail returns spf/dkim/dmarc pass (Google's Check MX walks it).
Campaigns: if you use Email Campaigns, re-confirm its domain verification still shows green after the _dmarc merge.

FAQ

Squarespace says my records are there. Google says DKIM isn't started.

Both true: records ≠ signing. DKIM starts in Google's Admin console (the “Start authentication” act) — Squarespace's panel can only hold the key.

Can I switch to Google billing without downtime?

The cancel-to-Google transfer doesn't delete mail and carries a 7-day grace — but it's one-way. Do it for a reason (plan changes, support consolidation), not as a fix for an authentication problem, which it cannot solve.

Two SPF rows show in my panel — PermError?

Not here: Squarespace merges rows into one published record (verify the merged output publicly). This is the one host where the row count isn't the record count — which is why these guides are per-combination, not generic.

Sources

Squarespace Support — Google Workspace signup guide & MX article (automatic MX scope; both MX end states; the GGOOGLE typo) · DNS presets article (Google Workspace MX preset; provider list) · DNS records for email services (panel grammar; SPF merging; 2048-bit statement) · Email Campaigns domain verification (squarespace._domainkey CNAME; _dmarc unique code; merge procedure) · Cancel/transfer + suspended-account articles (one-way transfer; 40-day auto-renew-off path) · Nameserver vs DNS connect (CNAME removal) · Google answer/53929 (registrar-partner flow) · Packs #7/#43 (Google record mechanics).

Verification note: automation scopes, the merge behaviours and the transfer terms were confirmed from Squarespace's text on 20 October 2026. Which MX set the preset writes today is stated by no Squarespace page — the ladder's readback step exists because of that gap.

Did this guide work for you?

Your reaction tells us whether this guide solved the problem it promised to solve.