Do I need an SPF record for Squarespace?

No — not for Email Campaigns. Squarespace sends campaign mail with a Return-Path on its own domain, so your SPF record isn't evaluated for it, and their current guidance dropped the SPF requirement. What makes campaigns pass DMARC is DKIM alignment.

How do I set up DKIM for Squarespace Email Campaigns?

Verify your custom domain in the Email Campaigns settings — the same setting that unlocks sending from your own address. Squarespace configures DKIM signing for your domain as part of that verification.

How do I add a DMARC record for Squarespace?

Add a TXT record named _dmarc in your domain's DNS settings — the Squarespace Domains panel if DNS is hosted there, or your external DNS provider. Start with p=none and rua=mailto:reports@yourdomain.com, then enforce p=reject once your reports only list senders you own.

What SPF record should I add if I use Google Workspace with Squarespace?

v=spf1 include:_spf.google.com ~all as a TXT record at the root of your domain. If you already have an SPF record, merge the includes into one record and keep the total under 10 DNS lookups.

Where do I add a DMARC record in Squarespace?

Settings then Domains, click the domain, open DNS, scroll to Custom Records and click Add Record. Set Host to _dmarc on its own, Type to TXT, and paste the record value into Data. Squarespace appends your domain to the host automatically, so typing the full _dmarc.yourdomain.com creates a record nothing will read. If your nameservers are at another registrar, add the same TXT record there instead.

Why do my Squarespace campaigns still fail DMARC after I verified the domain?

Check the d= value on the DKIM-Signature header of a failing message. If it names a Squarespace domain rather than yours, the verification has not taken effect for that sending address: campaigns sent before verification completed keep the old signature, and a second sender address in the campaign settings may still be unverified.

Does Squarespace host my email mailboxes?

No. Squarespace resold Google Workspace and stopped selling it to new customers, transferring existing subscriptions to Google directly. Your mailboxes are with Google Workspace, Microsoft 365, Zoho or another provider, and that provider supplies the SPF and DKIM values your domain needs. Squarespace Email Campaigns is a separate sender with its own DKIM signing.

Squarespace SPF Record & DMARC: How to Set Up Email Authentication

Squarespace Email Campaigns works differently from most providers: Squarespace no longer requires an SPF record for campaigns, and adding one won't change how your mail is judged. The path to a passing DMARC is DKIM plus a DMARC record of your own. Here's what to publish, what to skip, and why.

The short version: verify your domain in Email Campaigns so Squarespace signs with DKIM aligned to you, publish one _dmarc TXT record, and add an SPF record only for whoever hosts your actual mailboxes. Squarespace campaign mail does not need an SPF entry from you.

First: work out who actually sends your mail

This is where most Squarespace setups go wrong, and it takes thirty seconds to settle. Three different things can put your domain in a From address, and each is authenticated separately:

Email Campaigns — newsletters and announcements you compose in Squarespace. Sent from Squarespace's own infrastructure. This is the one this guide is mainly about.
Your mailboxes — the address a human replies from. Squarespace has never run these itself; it resold Google Workspace, and stopped selling it to new customers, transferring existing subscriptions to Google directly. So your mailbox provider is Google Workspace, Microsoft 365, Zoho, Fastmail or similar — and their SPF and DKIM values are the ones your domain needs.
Site notifications — form submissions, order confirmations, abandoned-cart mail. These are sent by Squarespace from Squarespace's own address, not yours, so there is nothing for you to authenticate. If a customer receipt shows a Squarespace sender rather than your domain, that is by design.

Check which mailbox provider you're on by looking at where you sign in to read mail, or by running your domain through the free DMARC checker — the MX records it reports name your provider directly.

Squarespace SPF record — do you need one?

For Email Campaigns: no. Campaign mail is sent from Squarespace's own infrastructure with a Return-Path on Squarespace's domain, so your SPF record isn't even evaluated for it — and their current guidance dropped the SPF requirement entirely. Adding include:squarespace-mail.com to your SPF harmlessly covers their servers, but it's not what makes campaigns pass DMARC.

This trips people up because it inverts the usual advice. SPF authorises the servers that appear in the envelope sender, not the From address a reader sees. When a provider puts its own domain in the envelope — as Squarespace does — your record is never consulted, and no amount of editing it changes the outcome. DKIM is what carries your domain through.

What your SPF record does need is your mailbox provider:

Google Workspace: v=spf1 include:_spf.google.com ~all
Microsoft 365: v=spf1 include:spf.protection.outlook.com -all
Zoho Mail: v=spf1 include:zoho.com ~all — see the Zoho guide for the regional variants.

One record only. If your domain already has an SPF record, merge the includes into it rather than publishing a second — two SPF records is a permanent error and receivers stop evaluating both. Keep the total under 10 DNS lookups; the free SPF record checker counts them for you and names which includes are expensive.

Squarespace DKIM — the piece that matters

This is the whole game for campaigns. In Email Campaigns, verify your custom domain — the same setting that unlocks sending from your own address rather than a Squarespace one. Squarespace sets up DKIM signing for your domain as part of that verification, so campaign mail arrives signed and aligned to you.

Alignment is the word doing the work. An unverified campaign is still signed — by Squarespace, for Squarespace's domain. DMARC doesn't ask "was this signed?", it asks "was this signed by the domain in the From address?" Until you verify, the answer is no, and your campaigns fail DMARC no matter how carefully you wrote your records.

Verification is done from the Email Campaigns area of your Squarespace account, under the sender-details or domain settings for the campaign. If your DNS is hosted at Squarespace, the records are added for you; if it's elsewhere, Squarespace shows you the values to publish. Either way, confirm the key is live afterwards with the free DKIM checker.

Squarespace DMARC record — click by click

DMARC is one TXT record and it is entirely yours. Where you add it depends on who holds your DNS, not on who sends your mail.

If your DNS is hosted at Squarespace

Open your Squarespace account and go to Settings → Domains.
Click the domain you want to protect.
Open DNS (labelled DNS Settings on some accounts).
Scroll to Custom Records and click Add Record.
Set Host to _dmarc — just that, not the full _dmarc.yourdomain.com. Squarespace appends your domain automatically, and typing the whole thing creates a record at _dmarc.yourdomain.com.yourdomain.com, which nothing will ever read.
Set Type to TXT.
Paste the record value (below) into Data.
Save, and leave the TTL at whatever the panel defaults to.

Panel labels shift from time to time as Squarespace redesigns the area; the record you are creating does not. If you can find a place to add a custom TXT record, you are in the right screen.

If your DNS is hosted elsewhere

Domains bought before you moved to Squarespace, or pointed at Squarespace with nameservers left at the registrar, are administered at that registrar instead — Cloudflare, GoDaddy, Namecheap and the rest all have an equivalent "add TXT record" form. The host is _dmarc, the type is TXT, the value is identical.

The record to publish

Start in monitoring mode. It changes nothing about how your mail is handled and starts the reports flowing:

v=DMARC1; p=none; rua=mailto:reports@yourdomain.com

Read the aggregate reports for a week or two. Once every sender listed is one you own, enforce:

v=DMARC1; p=reject; rua=mailto:reports@yourdomain.com; sp=reject; adkim=s; aspf=s

Squarespace runs p=reject on its own domain, so the policy is proven on their infrastructure too. The full tag list is in DMARC record examples, and the staged walk between the two records above is DMARC policies explained.

Squarespace with Google Workspace

This is the most common Squarespace arrangement by a distance — site on Squarespace, mailboxes on Google — and it is where the two halves have to be set up separately.

SPF. One record at your domain root: v=spf1 include:_spf.google.com ~all. If you also send through a marketing platform outside Squarespace, merge that include into the same record.

DKIM. Google does not sign your mail until you switch it on, and this is the single most common gap we see on Squarespace domains. In the Google Admin console, go to Apps → Google Workspace → Gmail → Authenticate email, select your domain, choose a 2048-bit key, and generate. Google shows you a host (usually google._domainkey) and a long TXT value. Publish it in your DNS panel, wait for it to propagate, then come back and click Start authentication. Skipping that last click leaves the key published and unused.

DMARC. One record, as above — it covers Google and Squarespace and everything else at once. DMARC is per-domain, not per-sender.

The result is two independent paths to a DMARC pass: Google-sent mail aligns on SPF and DKIM, campaign mail aligns on DKIM. That redundancy is the point — DKIM survives forwarding where SPF does not.

What changes in your reports

Before: campaign mail passes SPF and DKIM — but for squarespace-mail.com, so DMARC fails alignment and you stay unprotected. After domain verification and a DMARC record: campaigns pass for your domain, and your reports list only senders you own.

The first week of reports is usually the most informative thing you'll see about your own domain. Expect at least one sender you'd forgotten — an old form tool, a CRM trial, a booking system — alongside the outright spoofing attempts. Point the rua= address at a monitor rather than a mailbox and it stays readable; if you have a report to hand right now, the free DMARC report analyzer turns the XML into a per-sender table with no account needed.

Troubleshooting

My campaigns still fail DMARC after verifying the domain

Check the failing message's headers for the d= value on the DKIM-Signature line. If it names a Squarespace domain rather than yours, the verification hasn't taken effect for that sending address — campaigns sent before verification completed keep the old signature, and a second sender address configured in the campaign settings may not be verified even though the first one is.

I added the record but the checker says there's no DMARC

Nine times out of ten it's the host field: _dmarc.yourdomain.com typed into a panel that already appends the domain. Look at the record list — if the name reads _dmarc.yourdomain.com.yourdomain.com, edit it down to _dmarc. Otherwise give it an hour; DNS changes at Squarespace are not always instant.

Do I need a DMARC record if I don't send email at all?

Yes, and arguably more urgently. A domain that sends nothing is a free identity for anyone who wants one, and a parked domain with no policy is the easiest kind to spoof. Publish v=DMARC1; p=reject; rua=mailto:reports@yourdomain.com and you've closed it.

Free checks: DMARC checker SPF checker DKIM checker Spam checker

Done? Run the free DMARC checker — it reads your live DNS and confirms your records parse and align. For the staged walk from p=none to p=reject, see DMARC policies explained.