How to set up SPF, DKIM and DMARC on Squarespace domains

Everything happens in one place: your domains dashboard → your domain → DNS → DNS Settings → Custom Records → Add record. Squarespace will ask for your password or your 2FA code before it lets you add anything. In the Name field you type only the prefix — @ for your root domain, _dmarc for DMARC — because, in Squarespace's own words, "Squarespace automatically adds your domain to the Name field."

One thing to know before you start: Squarespace publishes no SPF or DKIM values of its own. Not for Google Workspace, not for Titan, not for anyone. Those values come from whoever sends your email, and you copy them from their screen. What this guide gives you is the where, the how, and the three traps specific to Squarespace.

These three records let receiving mail servers check that a message claiming to be from you really is from you. They do not guarantee your email reaches the inbox — your content and your sending reputation matter at least as much — but without them, anyone can send email in your name.

What we don't do: we never touch your DNS zone. This guide tells you what to type and where. You're the one who saves it, in your own account, with your own credentials.

Before anything else: is Squarespace actually holding your DNS?

This is the question that decides whether the next twenty minutes are useful or wasted, and Squarespace documents it clearly enough to quote.

If your domain is registered at Squarespace, or connected through Nameserver Connect, your records live at Squarespace and this guide applies. Squarespace's wording: "When your domain connects to Squarespace via nameserver connect, your domain's DNS records are stored at Squarespace."

If your domain is connected through DNS Connect, they don't. "When your domain connects to Squarespace via DNS connect, your domain's DNS settings are stored with its third-party provider." Squarespace then tells you plainly: "Log into your domain provider account and follow their instructions to edit your records."

And if you've pointed a Squarespace domain at custom nameservers, the panel keeps working but stops mattering: "If you add custom nameservers to your domain, the records in the domain's Squarespace DNS settings panel won't apply to the domain."

So check your nameservers first. The values below don't change — only the panel does.

Good news if you're on Nameserver Connect. Squarespace limits which record types you can add — "You can only add A, AAAA, CNAME, MX, SRV, and TXT records to your domain." TXT and CNAME are both on the list, so SPF, DKIM and DMARC are all doable.

The records to copy and paste

1. SPF — who is allowed to send as you

What you must replace: the include:, almost certainly. The line above is for Google Workspace, which Squarespace still sells — but it's Google's published value, not Squarespace's. Use whatever your own mail provider gives you:

If several services send on your behalf, they all go in one single line:

v=spf1 include:_spf.google.com include:spf.example-crm.com ~all

⚠️ One SPF record per domain. Always. Two v=spf1 lines don't mean double protection, they mean no SPF at all — not for the new tool, and not for the mailboxes that worked yesterday. When you add a sending tool, you edit the line you already have.

Squarespace merges SPF records for you, and that's unusual. Its documentation says: "To add multiple SPF records to a Squarespace Domain, add them individually as custom records. Then, our system will automatically merge them into one." It also warns that the merge may not be visible: records added on top of a preset "won't appear to merge in the DNS panel after you refresh the page, but they will still propagate as a single record." Convenient — but it means the panel isn't showing you what the world sees. Check from outside.

On quotation marks: Squarespace says that "including quotation marks in the Data/Text field of an SPF record can sometimes cause propagation issues, depending on your domain's nameservers. If the SPF record doesn't resolve, remove the quotation marks." Start without them.

Email Campaigns doesn't need SPF, and Squarespace says so explicitly: "Previously, verification also included adding an SPF record to your DNS settings, but verification best practices have evolved over the years. Our current security features make an SPF record unnecessary, so we've removed this requirement." That's about Email Campaigns only — it says nothing about your mailboxes.

2. DKIM — the signature on your messages

Squarespace does not generate your DKIM key. Whoever sends your email does, and the value is unique to your account. Copy it; never invent it.

For Squarespace Email Campaigns, and only for that, Squarespace publishes a fixed record:

What you must replace: nothing here — this one really is the same for everyone. But note it only covers your marketing campaigns, not the mailbox you reply from.

For your actual mailboxes: Google Workspace gives you a single TXT record with the selector google by default, generated in the Google Admin console. Titan, Fastmail, Proton and the others each give you their own. Same rule every time: copy what your own screen shows.

⚠️ Never trust a tutorial that hands you a ready-made Microsoft 365 DKIM value. Since May 2025, Microsoft uses a new CNAME format for custom domains added after that date, with a partition character assigned dynamically — it is genuinely impossible to guess.

If your DKIM value is long: a 2048-bit key runs past 255 characters, and DNS handles long text values by splitting them into quoted chunks — "first part" "second part". That's the DNS protocol, not a Squarespace quirk. Squarespace claims you won't need to: "Squarespace supports DKIM and SPF records up to 2048 bits, so there's usually not a need to split them into multiple records," while other TXT records "have a smaller limit of 255 characters." If the form rejects your key with an "Enter valid data" error, that's the 255-character limit talking, and splitting is your answer.

3. DMARC — the instruction you give to inboxes

What you must replace: YOU@YOUR-DOMAIN.com with an address you actually read. That's where your reports land, and a DMARC record without a rua= is a report you'll never see.

Type _dmarc and nothing else. Squarespace spells this one out: "In the Name field, enter _dmarc without your domain at the end. Our system automatically adds your domain."

Why p=none first. It means "watch and tell me". Nobody gets blocked, nothing changes for your recipients, and you start receiving a list of everything sending in your name — including the tools you'd forgotten about. You watch for two to four weeks, confirm every legitimate sender is recognised, and only then tighten one notch to p=quarantine, then p=reject.

⚠️ One DMARC record per domain too. Squarespace enforces this — "You can only add one DMARC record to a Squarespace domain." If you already have one, you edit it.

⚠️ Careful with Squarespace's merge advice. When you have to combine two DMARC records, its guidance is: "If the records have policy tags with different values, use the more secure value in the merged tag." Applied literally to p=none and p=reject, that tells you to publish p=reject — the strictest possible policy, before you've read a single report. Merge the rua= addresses, keep the gentler policy, and tighten deliberately afterwards.

If you use Email Campaigns, watch the order of operations. Squarespace notes that "if your domain has a DMARC policy set to p=reject, you can't use the sender details until after you verify the domain." Verify first, tighten later — which is the right order anyway.

The click path

1. Open your domains dashboard at account.squarespace.com/domains.
2. Click the domain name. If you have several Squarespace domains, note that "you'll manage their DNS records separately."
3. Click DNS, then DNS Settings.
4. Scroll down to Custom Records.
5. Click Add record.
6. Enter your password, or reauthenticate with your 2FA method, and click Continue. This step is real, it's documented, and almost no tutorial mentions it — don't assume something broke.
7. Pick the Type from the dropdown, fill in Name, then the value field, and click Save.

The Name field wants the prefix only. Squarespace: "Squarespace automatically adds your domain to the Name field. This means if your provider asks you add your domain to the Name field, like yourdomain.com, you'll enter @. If your provider asks you to enter a specific value and your domain to the Name field, like mail.yourdomain.com, you'll enter mail." So: @ for SPF, _dmarc for DMARC, squarespace._domainkey for the Campaigns CNAME. Never _dmarc.yourdomain.com.

Don't be thrown by the field names. Squarespace calls the value field Text on one screen and Data on another, and the host field Name or Host depending on where you look — both spellings appear in its own documentation, sometimes on the same page. They're the same fields.

On TTL: Squarespace's default is four hours — "All custom records have a 4-hour TTL by default, but you can change that if you have specific needs for that record." Default is fine for all three records here.

The 3 mistakes we see most often on Squarespace

1. Losing the protection Squarespace set up for you, without ever being told

This one is specific to Squarespace, it's documented in plain sight, and almost nobody knows about it.

When you register a domain with Squarespace — or connect one via nameservers — you get three records for free. Squarespace's words: "When you register your domain or connect it via nameservers, we automatically apply three TXT records (DKIM, SPF, and DMARC). These records are anti-spam records that prevent spam from originating on domains that aren't using email services."

Then you set up email. And: "The records are automatically removed when you add any custom email records. It's not possible to manually re-add these records after they've been removed. Your email provider includes anti-spam records or other security features."

That last sentence is where it goes wrong. Your mailbox provider does give you SPF and DKIM. No mailbox provider publishes a DMARC record for you — not Google Workspace, not Titan, not Microsoft. So the moment you add your first email record, your domain goes from "protected by default" to "no DMARC at all", the records can't be restored, and the explanation you were given says everything is fine.

How you spot it: you set up email on a Squarespace domain weeks or months ago, and a DMARC lookup on _dmarc.yourdomain.com returns nothing.

The fix: publish your own _dmarc record, as in section 3 above. You're not repairing what Squarespace removed — you're publishing something better, with a rua= so you can actually see what's happening.

2. Thinking "verified" means "authenticated"

Squarespace domains verify themselves for Email Campaigns: "Domains that are registered through or managed by Squarespace verify automatically, which means you don't have to manually update their DNS settings." You see the preset in your DNS panel, everything is green, and it's easy to stop there.

But what that preset publishes is a DKIM CNAME for campaigns plus a bare-bones DMARC, SPF was explicitly dropped from the requirements, and none of it covers the mailbox you actually reply from. A verified Email Campaigns setup and a protected domain are two different things.

How you spot it: your campaigns send fine, but a scan of your domain shows no SPF for your mailbox provider, or a DMARC record with no rua= — so no reports, so no visibility.

The fix: treat them as two jobs. Campaigns are handled by the preset. Your mailboxes need their own SPF and DKIM, from your mail provider, and your domain needs one DMARC record with a reporting address.

3. Reading Squarespace's DMARC description and concluding it's a marketing setting

Squarespace defines DMARC like this: "A DMARC record is a type of TXT record that verifies your domain when you send Email Campaigns or other marketing using your custom email address. By adding a DMARC record and allowing mail providers to verify your domain, you can help minimize how often your marketing emails get flagged as spam."

Nothing there is a lie, and it's missing the point. DMARC exists so that someone who is not you can't send email in your name. It's a domain protection, not a campaign deliverability tweak. Read the description above and you'd reasonably conclude that if you don't send newsletters, you don't need it — and there's no article on Squarespace to correct you, because there isn't one on DMARC at all.

How you spot it: you don't have a DMARC record and you assumed it didn't apply to you because you don't do email marketing.

The fix: publish v=DMARC1; p=none; rua=mailto:... even if you never send a campaign in your life. Especially then — it's the only way you'll find out someone else is sending as you.

One piece of credit where it's due: Squarespace's DMARC example is v=DMARC1; p=none. No pct= anywhere in its documentation, and it doesn't push you to p=reject on day one. It's incomplete — no rua=, so no reports — but it's not dangerous, which is more than can be said for some registrars.

How long before it takes effect

• In your account: saved as soon as you click Save.
• On the internet: Squarespace's own figure is 24 to 48 hours, "in some cases… up to 72 hours." In practice most changes resolve much faster.
• The old value can stay cached for as long as the TTL you had set before the change — four hours on Squarespace's default.
• For your provider's "Verify" button: wait an hour before clicking, then wait again. Clicking twelve times in five minutes only adds doubt.
• For DMARC reports: the first ones arrive 24 to 72 hours after you publish, then roughly once a day.

Next steps

• How to set up SPF, DKIM and DMARC on GoDaddy
• How to set up SPF, DKIM and DMARC on Cloudflare
• Set up Google Workspace email authentication
• How to move your DMARC policy to p=reject safely
• My emails go to spam even though SPF, DKIM and DMARC pass