SPF, DKIM & DMARC for Squarespace.
Squarespace is a website and commerce platform, not a mailbox host — and that shapes how you authenticate email. Squarespace sends mail as your domain in two forms: Email Campaigns (newsletters and marketing) and store & system notifications (order confirmations, receipts, shipping updates, contact-form and form responses). Both are signed by the same CNAME-delegated DKIM key you publish in DNS — there is no Squarespace SPF include to add. Actual mailboxes (person@yourdomain) live on Google Workspace, Microsoft 365, or an IMAP host and authenticate separately. This guide covers publishing Squarespace's DKIM delegation and the DMARC record that ties it together.
Why authenticate Squarespace?
Gmail and Yahoo's bulk-sender rules now require SPF, DKIM, and a DMARC record for anyone sending marketing mail at volume — which is exactly what Email Campaigns does. Without authentication, campaigns and even order receipts land in spam or get rejected, and your domain can be spoofed. Because Squarespace signs on your behalf via delegated DKIM and stamps its own domain on the Return-Path, that one DKIM CNAME is the only path to DMARC alignment — getting it live is the difference between mail that passes DMARC as your domain and mail that fails alignment and gets filtered.
The SPF reality for Squarespace
There is no Squarespace SPF include, and adding one would not help. Squarespace removed the SPF step from domain verification (the legacy include:_spf.squarespace.com is gone), and it stamps its own domain (squarespace-mail.com) on the Return-Path of both Email Campaigns and store notifications — so SPF is evaluated against Squarespace's domain, never yours, and can never align to your From address. That means DMARC passes for Squarespace mail solely through DKIM, which is why the delegated DKIM CNAME must be live before you enforce anything. Keep your root v=spf1 record scoped to whoever actually runs your mailboxes (e.g. Google Workspace); do not add a Squarespace entry to it.
Step by step
- 1
Inventory everything that sends as your domain
Squarespace sends as your domain in two forms — Email Campaigns (newsletters/marketing) and store & system notifications (order confirmations, receipts, shipping updates, form responses) — and it does not host mailboxes. Both forms are signed by the same delegated DKIM key, so you publish one CNAME for all of it. A person@yourdomain inbox is separate: it lives on Google Workspace, Microsoft 365, or an IMAP provider, each with its own records. List every sender before touching DNS.
- 2
Open the correct DNS editor
If your domain is registered or managed at Squarespace (including domains migrated from Google Domains in 2023-24), edit DNS at Settings → Domains → select the domain → DNS Settings → Custom Records / Add Record. If the domain is registered elsewhere and only pointed at Squarespace, add every record at that registrar instead. The Host/Name field is relative — you enter squarespace._domainkey, never the full domain.
- 3
Publish the Squarespace DKIM CNAME
Add one CNAME — Name squarespace._domainkey, Type CNAME, Value squarespace-domainkey.squarespace-mail.com. This single record lets Squarespace DKIM-sign everything it sends as your domain — both Email Campaigns and store/system notifications — with d=yourdomain.com. Don't append your domain to the host, don't add https:// or trailing spaces, and if your DNS runs behind Cloudflare set the record to DNS-only (grey cloud) so it isn't proxied or CNAME-flattened — proxying breaks the DKIM delegation.
- 4
Turn on Email Campaigns sending in Sender Details
If you use Email Campaigns, open Email Campaigns → Settings → Sender Details, set your From name and address on your own domain, and click Verify Domain (labelled Authenticate in some accounts). Squarespace emails a verification code to that From address — paste it back to prove you control the mailbox. The panel then shows the same squarespace._domainkey CNAME from the previous step plus a suggested _dmarc TXT to publish; there is no separate per-campaign DKIM record to add.
- 5
Publish your DMARC record at p=none
Add a TXT record at _dmarc with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Squarespace's verify flow may prefill a monitor-only _dmarc value, but only one _dmarc TXT is allowed per domain and the aggregate reports only reach you if rua points at a mailbox you read — so publish (or merge into) a record whose rua you control. p=none is monitor-only and changes no delivery, but the reports tell you whether Squarespace mail is passing DKIM-aligned before you tighten.
- 6
Skip the Squarespace SPF include — set SPF for your mailbox host only
Squarespace has no SPF include to add (the old include:_spf.squarespace.com was retired, and its Return-Path is on squarespace-mail.com, so SPF can't align regardless). Your single root v=spf1 TXT should list only who runs your mailboxes and any other real senders — for example include:_spf.google.com for Google Workspace. Do not invent a Squarespace SPF entry; DKIM is what authenticates Squarespace mail.
- 7
Verify, then tighten DMARC
Back in Sender Details click Authenticate for a green check; confirm the CNAME with dig or an external checker, then send a test campaign to a Gmail address and open Show original — DKIM should read PASS with d=yourdomain.com and DMARC PASS. Propagation is usually 15-60 minutes but can take up to 48-72 hours. After a week or two of clean reports, step DMARC to p=quarantine and then p=reject.
Records to add
Squarespace generates the exact values in its setup wizard — these show the shape of what you'll add at your DNS host.
| Type | Host | Value |
|---|---|---|
| CNAME | squarespace._domainkey | squarespace-domainkey.squarespace-mail.comThe one DKIM record for all Squarespace sending — Email Campaigns and store/system notifications alike (receipts, order/shipping updates, form responses). Delegates the squarespace selector so Squarespace signs with d=yourdomain.com using a key it hosts and rotates. Concrete and non-account-specific: the same host and value for every Squarespace user, so you can add it verbatim. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comYou own this. Squarespace's Email Campaigns verify flow may prefill a monitor-only _dmarc value, but only one _dmarc TXT is allowed per domain and the reports reach you only if rua points at a mailbox you read. Start at p=none, then tighten to quarantine/reject once reports are clean. |
| TXT | @ | v=spf1 include:_spf.google.com ~allIllustrative — this SPF is for your MAILBOX host, not Squarespace. Squarespace sending needs no SPF entry (no include exists; its Return-Path is squarespace-mail.com, so SPF can't align). Swap _spf.google.com for whoever runs your mailboxes, or omit SPF entirely if you have no other senders. |
Keep exactly one SPF (v=spf1) TXT record on your root domain — merge every sender into it. Two SPF records is itself an error.
The 10-lookup budget
SPF is capped at a hard 10 DNS lookups — go over and it returns a permerror and stops validating everywhere. Here's what Squarespace's setup costs against that budget.
Squarespace's recommended setup adds 0 lookups — all 10 stay free for the senders that do need an include.
DKIM
Squarespace authenticates entirely through CNAME-delegated DKIM — there is no DKIM TXT key to paste. You add one CNAME: host squarespace._domainkey pointing to squarespace-domainkey.squarespace-mail.com. That single record delegates the squarespace selector so Squarespace signs every message it sends as your domain — Email Campaigns and store/system mail (order confirmations, receipts, shipping updates, form responses) alike — with d=yourdomain.com, using a key it hosts and rotates. Email Campaigns adds no separate DKIM record; its Sender Details verify flow simply confirms this same CNAME resolves (alongside an emailed sender-verification code and a suggested _dmarc TXT). Because it's pure CNAME delegation, Squarespace can rotate keys without you touching DNS again — but if the CNAME is proxied (Cloudflare orange cloud), CNAME-flattened, or mistyped, signing silently fails and mail loses its only path to DMARC alignment.
DMARC
DMARC is a record you publish at _dmarc. Squarespace's Email Campaigns verification even generates a suggested value for you, but it's monitor-only (p=none) and the reports only help if the rua points at a mailbox you actually read — so own the record: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com to start, then tighten to p=quarantine and p=reject once the reports show Squarespace (and your mailbox host) passing aligned. The alignment nuance is critical here: Squarespace's Return-Path sits on squarespace-mail.com, so SPF never aligns to your domain — DMARC passes for Squarespace mail only through DKIM, which is exactly why the CNAME must be live before you enforce. One trap: only one _dmarc TXT is allowed per domain, so if you already publish DMARC, keep your record and reconcile Squarespace's suggested value into it rather than adding a second.
Check it actually worked
In Squarespace, return to Email Campaigns → Settings → Sender Details and click Authenticate — a green check means the CNAME resolved and your sender is verified. For store email, Squarespace verifies the same squarespace._domainkey CNAME automatically once it propagates. Confirm independently with dig CNAME squarespace._domainkey.yourdomain.com (it should return squarespace-domainkey.squarespace-mail.com), then send a test campaign to a Gmail address and use Show original to check DKIM = PASS with d=yourdomain.com and DMARC = PASS. Propagation is usually 15-60 minutes but can take up to 48-72 hours. Qualisend's SPF/DKIM/DMARC checker and domain health tools flag any missing or misaligned records.
Common gotchas
- DNS setup
There is no Squarespace SPF include. Adding include:_spf.squarespace.com (retired) or any Squarespace SPF entry won't help — Squarespace's Return-Path is on squarespace-mail.com, so SPF can never align to your domain. DKIM via the CNAME is the only alignment path; a stray Squarespace include just burns one of your 10 SPF lookups.
- DNS setup
One CNAME covers all Squarespace mail. The same squarespace._domainkey CNAME signs both Email Campaigns and store/system notifications — you do not add a separate DKIM record per stream. You still open Sender Details to set your From address and verify the sender if you send campaigns, but that uses the same CNAME.
- DNS setup
Because SPF can't align, DMARC for Squarespace mail depends entirely on DKIM. If the delegated CNAME isn't live (or is proxied/flattened), your mail fails DMARC even when your From domain has a perfect SPF record.
- DNS setup
Only one _dmarc record is allowed per domain. Squarespace's verify flow prefills a monitor-only DMARC; if you already publish one, keep yours (merge, don't add a second) and make sure rua points at a mailbox you read so you actually receive the reports.
- DNS setup
The Host/Name field is relative. Enter squarespace._domainkey, not the full FQDN — Squarespace and most registrars auto-append your domain. Some registrars also require a trailing dot on the CNAME target (squarespace-domainkey.squarespace-mail.com.).
- DNS setup
Don't proxy the DKIM CNAME. Behind Cloudflare, set the record to DNS-only (grey cloud). An orange-clouded or CNAME-flattened record breaks the delegation and DKIM signing fails silently.
- Coverage
Squarespace doesn't host mailboxes. A working person@yourdomain address requires Google Workspace, Microsoft 365, or an IMAP host — each with its own SPF include and DKIM selector (e.g. google._domainkey), entirely separate from these Squarespace records.
- Coverage
Domains that moved from Google Domains now edit DNS inside Squarespace. After the 2023-24 migration, sign in at Squarespace (Settings → Domains) to add these records — not at the old Google Domains console.
Build your SPF record
Squarespace doesn't need an SPF include: on your root domain — use the generator to assemble one clean record for your other senders, and keep it to a single line.
Sending sources
Search for each platform you send email through and tick it.
Search for your email platform above, or .
This domain's own servers
Authorize the domain itself, if it sends mail directly (not through a platform above).
Other senders & IPs
Anything not in the list — another provider's SPF host, or specific IP addresses.
We add the include: prefix — enter the hostname your provider documents.
Policy for everyone else
What receivers should do with mail from any server not listed above (the all mechanism).
No senders yet, so every message would hit the ~all policy. Add the platforms you send through in step 1.
- Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
- Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
- Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.
Authentication published? The next step is sending to a clean, verified list.
Verify a listSquarespace SPF — FAQ
Related reading
Once it's published, confirm everything resolves with the domain health check, then read who's sending as you with the DMARC report analyzer. Browse all sending sources in the generator. Authentication is only half of deliverability, though — a listed sending IP or domain still lands you in spam no matter how clean your SPF is, so it's worth watching the blacklists with blacklist monitoring.
Authenticated — now keep the list clean
Passing SPF, DKIM, and DMARC gets you to the inbox; a clean list keeps you there. Verify yours — start free with 100 credits, no card required.