Add DMARC, SPF and DKIM on Squarespace: a precise DNS guide

8 June 2026 · 16 min read

How to add DMARC, SPF and DKIM records on Squarespace

Squarespace is a website builder first and a DNS host second, and that distinction explains almost every problem people hit when they try to add email authentication on it. The Squarespace DNS editor is perfectly capable of holding the TXT and CNAME records that DMARC, SPF and DKIM need. It just has a handful of quirks in how it asks you to type host names, how it stores long TXT values, and how it treats the zone apex, and those quirks are exactly where authentication setups go wrong.

This guide is specific to the Squarespace DNS editor. It walks through adding the SPF TXT record, the DKIM records (which on Squarespace are almost always CNAMEs pointing at your email provider), and the DMARC TXT record, with the Squarespace-specific gotchas spelled out: root versus host name, what to put in the Host field, how Squarespace handles a long TXT value, the CNAME-at-apex / flattening question, and TTL. If you want the plain-English version of what DMARC actually is before you touch DNS, read the DMARC requirements explainer first, then come back here for the Squarespace mechanics.

First, work out who actually sends your mail

This is the single most important step and it has nothing to do with Squarespace's interface. Squarespace does not send your everyday business email. Squarespace hosts your website. Your mailboxes almost certainly live with a separate provider: Google Workspace, Microsoft 365, Fastmail, Zoho, or whatever your domain registrar bundled. The DNS records you are about to add must describe that mail provider, not Squarespace.

There are only really three sources of mail to think about:

Your mailbox provider (Google Workspace, Microsoft 365, and so on). This is the big one. Its SPF include and DKIM records are the records that matter most.
Squarespace's own form and transactional mail. Contact forms, order confirmations from Squarespace Commerce, newsletter sends through Squarespace Email Campaigns. These send from Squarespace infrastructure and need their own SPF authorisation if you send campaigns from your domain.
Any third-party tools that send as your domain: a CRM, a help desk, an invoicing system, a separate marketing platform.

Before you change anything, photograph the current state. Run your domain through the DMARC checker, the SPF checker and the DKIM checker. You want to know what is already published so you do not accidentally overwrite a working record or add a second conflicting one.

Where the Squarespace DNS editor lives

You can only edit DNS in Squarespace if Squarespace is the authoritative DNS host for the domain. That happens in one of two ways:

The domain was bought through Squarespace (or transferred in). Then Squarespace runs the nameservers and you edit records under Settings, Domains, click the domain, then DNS or DNS Settings, then Advanced to reach the custom records area.
The domain is registered elsewhere but its nameservers point at Squarespace. Same editor, same place.

If your nameservers point somewhere else (your registrar, Cloudflare, Route 53), the Squarespace DNS editor is not where your live records are read from, and any record you add there is ignored. Check your nameservers first. A quick way: run the domain through the DMARC checker or any DNS lookup and see which nameservers answer. If they are not Squarespace's, do this work wherever your zone actually lives. The record values in this guide are identical regardless of host; only the editor differs.

Inside the Squarespace editor you add records with three or four fields, depending on type:

Host (Squarespace sometimes labels this the record name).
Type (A, CNAME, TXT, MX and so on).
Priority (MX only).
Data (the value).

The Host field is where most Squarespace mistakes are born, so we will be precise about it for every record.

The Host field: root versus a subdomain name

Squarespace expects you to enter the host name relative to your domain, not the full name. This trips people up constantly. Here is the rule:

To create a record at the root of the domain (the apex, example.com itself), enter @ in the Host field. Squarespace shows this as @ meaning "the bare domain".
To create a record at a subdomain or selector, enter only the label, without your domain on the end. For a record that should live at _dmarc.example.com, you type _dmarc in the Host field, not _dmarc.example.com.

This is the classic doubled-domain error. If you type the full _dmarc.example.com into the Host field, Squarespace appends your domain again and the record ends up at _dmarc.example.com.example.com, which no receiver will ever query. The record looks present in the editor and is completely invisible to the world.

So, throughout this guide, when a record needs to live at:

example.com (apex), the Host is @.
_dmarc.example.com, the Host is _dmarc.
selector._domainkey.example.com, the Host is selector._domainkey.

Always strip your own domain off the end before typing it into the Host field. When in doubt, add the record, then query the full name with the relevant tool and confirm it resolves at the name you intended.

Step 1: SPF, a single TXT record at the root

SPF authorises which servers may send mail using your domain in the envelope return-path. It is one TXT record, at the apex, and you may only ever have one. Two v=spf1 records on the same name is itself an SPF failure (permerror), so the whole job is merging everything into a single line.

In Squarespace:

Type: TXT
Host: @
Data: your single SPF string

The value depends on your mailbox provider. A few common starting points:

Google Workspace:

v=spf1 include:_spf.google.com ~all

Microsoft 365:

v=spf1 include:spf.protection.outlook.com ~all

If you also send Squarespace Email Campaigns or Commerce notifications from your own domain, Squarespace's mail needs authorising too. When you add a custom sending domain in Squarespace Email Campaigns, Squarespace gives you the exact include and DKIM records to add; follow those screens for the current values rather than guessing, because campaign-sending infrastructure changes. The principle is the same: the Squarespace include goes inside the one SPF record, merged with your mailbox provider, never as a second record.

A merged example for Google Workspace plus one extra third-party sender:

v=spf1 include:_spf.google.com include:servers.mcsv.net ~all

Three Squarespace-relevant points:

Use ~all (softfail), not -all, while you are still discovering senders. Move to -all (hardfail) only once you are certain every legitimate sender is inside the record. Going to -all too early is a reliable way to bin your own newsletters.
Mind the 10-lookup limit. SPF allows at most 10 DNS lookups when a receiver evaluates it. Each include: counts, and some expand into several more. Stack a mailbox provider, a marketing platform and a help desk and you can sail past 10, at which point SPF returns permerror and effectively fails for everyone. The SPF checker counts your lookups. If you are near the ceiling, see the section on flattening below, and our explainer on the SPF 10-lookup limit for the full mechanics.
One record only. If the SPF checker shows two v=spf1 lines, delete one and merge its includes into the survivor.

The TXT quoting and chunking gotcha on Squarespace

Long TXT values have a hard limit at the DNS protocol level: a single character-string inside a TXT record cannot exceed 255 characters. SPF strings rarely hit that, but DKIM TXT keys frequently do, and this is where Squarespace behaviour matters.

Do not add your own quotation marks. Some DNS hosts want you to wrap a TXT value in "...". Squarespace does not; you paste the bare value and Squarespace stores it. If you wrap it in quotes yourself, the quotes can become literal characters in the published record and break parsing. Paste v=spf1 include:_spf.google.com ~all exactly, with no surrounding quotes.
Do not pre-split long values across multiple Data fields. When a TXT value is longer than 255 characters, it must be split into multiple quoted chunks at the protocol level, but a well-behaved DNS host does that chunking for you behind the scenes. You paste the whole string into the single Data field. The trap is manually inserting " " breaks into the middle of, say, a DKIM key, hoping to chunk it yourself: that usually corrupts the key. Paste the entire value as one continuous string and let the resolver reassemble it. If a long key genuinely will not save, that is a sign you should be using a CNAME-based DKIM setup instead (most providers offer one), which sidesteps TXT chunking entirely. The next section covers exactly that.

Step 2: DKIM, almost always CNAMEs on a modern setup

DKIM attaches a cryptographic signature to your outbound mail and publishes the matching public key in DNS at a selector. There are two ways a provider hands you that key, and which one you use changes what you type into Squarespace.

Option A (preferred): CNAME delegation

Most current providers, Google Workspace included for newer configurations, and certainly Squarespace's own campaign sending, give you CNAME records that delegate the key to them. This is the better option because the provider owns and rotates the key behind the CNAME; you never touch DNS again when they roll keys.

A CNAME-delegated DKIM record on Squarespace looks like this. For a provider that uses selectors s1 and s2:

Type: CNAME
Host: s1._domainkey
Data: s1.dkim.exampleprovider.com (the target your provider gives you, ending in a dot if Squarespace requires the trailing-dot form; Squarespace generally accepts it without)

You add one CNAME per selector your provider specifies. Read the structure carefully, because the Host must be just the selector plus ._domainkey, with your domain stripped off:

Host:  s1._domainkey
Type:  CNAME
Data:  s1.dkim.exampleprovider.com

Host:  s2._domainkey
Type:  CNAME
Data:  s2.dkim.exampleprovider.com

Two Squarespace-specific cautions:

Use the exact target string the provider shows you. CNAME DKIM targets often embed your domain in the middle (some providers use a form like s1.example.com.dkim.provider.com). If your provider's value contains your domain, keep it; do not "tidy" it out. Dropping that middle segment means the CNAME resolves to nothing and DKIM silently fails.
It is a CNAME, not a TXT. If Squarespace is asking you for quotes or a TXT value here, you have picked the wrong Type. CNAME DKIM has no key text at all in your zone; the key lives at the target.

For more on what selectors are and why providers publish more than one, see DKIM selectors explained and DKIM key rotation.

Option B: a raw TXT key (Microsoft 365's older style, some legacy setups)

If your provider hands you a public key to paste rather than a CNAME target, you create a TXT record at the selector:

Type: TXT
Host: selector1._domainkey
Data: v=DKIM1; k=rsa; p=MIGfMA0GCSq... (the long key string from your provider)

This is precisely where the 255-character chunking issue from earlier bites, because a 2048-bit RSA key is well over 255 characters. Paste the whole v=DKIM1; ... p=... value as one continuous string into the single Data field. Do not insert your own quote-marks or spaces to break it up. Squarespace stores it and the resolver reassembles the chunks. Then verify with the DKIM checker using your exact selector name, because a corrupted or truncated key is the most common DKIM failure and it is invisible until you actually query it.

Note for Microsoft 365: Microsoft's standard guidance is to publish two CNAMEs (selector1._domainkey and selector2._domainkey) pointing at ...onmicrosoft.com targets, then enable DKIM signing in the Microsoft admin centre. That is Option A; use the CNAME form and add both selectors. The signing toggle in Microsoft's portal is a separate step from the DNS records and is easy to forget; records alone do not start signing.

The crucial alignment point

Whichever option you use, the thing that matters for DMARC is alignment: the DKIM signing domain (d=) on real delivered mail must match your visible From: domain. Publishing the record is necessary but not sufficient; the provider also has to be configured to sign as your domain. The only honest way to confirm this is to send a real message and read the Authentication-Results header in the received copy, checking for dkim=pass with d=yourdomain.com. The DKIM checker verifies the published key; the header confirms live signing. We cover why this distinction matters in DMARC alignment explained.

Step 3: DMARC, one TXT record at `_dmarc`

DMARC ties SPF and DKIM back to the visible From: address and tells receivers what to do with mail that fails. It is a single TXT record at the _dmarc host. On Squarespace:

Type: TXT
Host: _dmarc
Data: your DMARC policy string

Start in monitor-only mode, which changes nothing about delivery and simply collects reports:

v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1;

Field by field:

p=none means observe and report, quarantine nothing, reject nothing. This is a measurement phase, not a destination.
rua=mailto:... is the address that receives the daily aggregate XML reports. Use a mailbox you can actually read. Those reports are how you discover every sender. Pointing the address at the DMARC report analyzer saves you reading raw XML.
fo=1 asks receivers to send failure reports when SPF or DKIM fails alignment, which helps you find stray senders faster.

Two Squarespace-flavoured warnings on the Host field, because this is where the doubled-domain bug strikes hardest:

The Host is _dmarc, not _dmarc.example.com. Type the full name and your record lands at _dmarc.example.com.example.com and no receiver will ever find it.
The leading underscore matters. _dmarc with the underscore, not dmarc. Squarespace accepts underscores in the Host field; type it exactly.

If you would rather not hand-write the string, the DMARC generator produces a syntactically clean record you can paste straight into the Data field.

Why you start at `p=none`

p=none exists so you can see who sends as your domain before you start blocking anything. On a typical Squarespace-hosted site the surprise senders are often the Squarespace ones themselves: order confirmations, form notifications, or email campaigns sent from your domain that you forgot were authenticating against Squarespace infrastructure rather than your mailbox provider. The aggregate reports surface every one of them. Read why p=none is false security if you stay there so you treat it as a stage, not a finish line.

Walking up to enforcement

Sit at p=none for two to four weeks of report data, confirm every legitimate sender is passing with alignment, then tighten in stages. Each of these is just an edit to the same single DMARC TXT record's Data field in Squarespace:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com;

v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@example.com;

v=DMARC1; p=reject; rua=mailto:dmarc@example.com;

p=quarantine sends failing mail to spam rather than refusing it. pct=25 applies the policy to a quarter of failing mail so you can watch the effect before committing fully.
p=reject is the goal. At reject, anything failing DMARC for your domain is refused outright, which is what actually stops exact-domain spoofing and what Gmail, Yahoo and Microsoft now expect of bulk senders. See the enforcement journey for the full ramp and why Gmail, Yahoo and Microsoft now require DMARC.

Leave the alignment-mode tags at their relaxed defaults. Do not add adkim=s or aspf=s unless you have a specific reason; strict mode rejects legitimate aligned subdomain mail that relaxed mode accepts.

The CNAME-at-apex and flattening question

Two related Squarespace traps deserve their own section.

You cannot put a CNAME at the apex. DNS forbids a CNAME on the zone root (example.com itself) because the apex already carries other records (your website's A records, the MX, the SOA). This matters on Squarespace because some third-party email or marketing tools tell you to "add a CNAME for your root domain". You cannot, and Squarespace will reject it or it will break your site. CNAME DKIM records are always at a selector (s1._domainkey), never at @, so in practice this is fine for DKIM. But if a tool ever asks for a CNAME at @, that instruction is wrong for any DNS host, Squarespace included; ask the provider for the A-record or TXT alternative.

SPF flattening and Squarespace. "Flattening" means replacing include: lookups with the literal IP ranges they resolve to, so you stay under the 10-lookup limit. You can paste a long flattened SPF string into the single Squarespace TXT Data field. The problem is that flattened SPF is a frozen snapshot: the moment Google, Microsoft or any sender changes the IP ranges behind their include, your hard-coded list is wrong and legitimate mail starts failing SPF, silently. Squarespace will not warn you, because Squarespace is a DNS host, not a monitoring service. If you are flattening to dodge the 10-lookup limit, you have taken on a maintenance burden. This is exactly the failure our hosted SPF product removes: it keeps a single flat record correct automatically as upstreams change. Read how SPF flattening works before you commit to a hand-frozen list.

TTL on Squarespace

Squarespace assigns a default TTL to records you create and historically has not exposed a per-record TTL field in the way some DNS hosts do; you generally get a fixed default (commonly around one hour, sometimes four). Two practical consequences:

Changes are not instant. After you add or edit a record, resolvers that previously cached the old answer keep serving it until the TTL expires. If you are testing and the DMARC checker still shows the old value, wait out the TTL before concluding the change failed. Most propagate within an hour, occasionally longer.
Do not panic-edit. Repeatedly changing a record because it "has not updated yet" only resets the clock and confuses your testing. Make the change once, then check after the TTL window.

If your Squarespace plan or interface does expose a TTL setting, a moderate value (3600 seconds) is sensible for stable records like SPF and DKIM. There is no benefit to a very short TTL on records you rarely change, and it adds lookup load.

A complete worked example

Here is the full set of records for example.com on Squarespace DNS, with Google Workspace as the mailbox provider, CNAME-delegated DKIM, one extra third-party sender folded into SPF, and DMARC in monitor mode. Remember the Host column is what you type into Squarespace's Host field, with your domain already stripped off:

; SPF (Google Workspace + one extra sender, single record, softfail)
Host: @            Type: TXT    Data: v=spf1 include:_spf.google.com include:servers.mcsv.net ~all

; DKIM (CNAME delegation, two selectors from the provider)
Host: google._domainkey   Type: CNAME   Data: <target string from Google admin console>

; DMARC (start in monitor mode)
Host: _dmarc       Type: TXT    Data: v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1;

Once everything verifies and reports look clean, the only line you change to move toward enforcement is the _dmarc TXT record's Data value, walked up through quarantine to p=reject. SPF and DKIM stay put.

Verification checklist

Do these in order. Each has a tool so you are not guessing, and each checks the full record name, which is how you catch the doubled-domain Host error:

SPF resolves, is a single record, and is under 10 lookups. Run the SPF checker on example.com. Confirm one v=spf1 line and a lookup count below 10.
DKIM resolves at your real selector and signs live mail aligned to your domain. Use the DKIM checker with your provider's selector name, then send yourself a real message and confirm dkim=pass with d=example.com in the received Authentication-Results header.
DMARC is published at _dmarc.example.com and parses, with a working rua mailbox. Confirm with the DMARC checker. If it reports "no record found", the doubled-domain Host error is the first thing to suspect.
Aggregate reports show every legitimate sender passing with alignment, Squarespace's own mail included if you send campaigns from your domain. Feed the XML into the DMARC report analyzer and read your first DMARC report.
Only then raise the policy from none toward reject.

Once you are at enforcement, hardening is worthwhile: set up encryption-in-transit policy with MTA-STS and, if you want a verified logo in inboxes, BIMI. BIMI requires p=quarantine or p=reject first, so it is a natural follow-on to this work.

Squarespace-specific mistakes to avoid

Typing the full name in the Host field. _dmarc.example.com instead of _dmarc produces _dmarc.example.com.example.com. Strip your domain off every Host entry.
Adding a second SPF record for Squarespace campaigns or a third-party tool instead of merging includes into the one v=spf1 line.
Wrapping TXT values in quotes yourself. Paste the bare value; let Squarespace store it.
Manually chunking a long DKIM key with your own quotes or spaces. Paste it whole, or better, use the CNAME-delegated form and avoid TXT keys entirely.
Editing DNS in the Squarespace editor when your nameservers point elsewhere. Records there are ignored. Confirm Squarespace is authoritative first.
Hand-freezing a flattened SPF record and forgetting it. When upstream IPs change, it fails silently. Let it be maintained for you.
Forgetting the provider-side signing toggle (notably Microsoft 365). DNS records alone do not start DKIM signing; the provider has to be told to sign.
Panic-editing during the TTL window and concluding a correct record is broken. Make the change once and wait.

The takeaway

The Squarespace DNS editor will hold a clean DMARC, SPF and DKIM setup without complaint, as long as you respect its conventions: one SPF TXT record at @, DKIM as CNAMEs at the selector (or a single un-chunked TXT key if your provider is old-school), DMARC at _dmarc, every Host entered with your domain stripped off, no manual quotes, no manual chunking, and patience for the TTL. The values describe your mail provider, not Squarespace; Squarespace just stores them. Add the records, verify with real delivered mail and the tools above, watch the aggregate reports for a few weeks, and walk the DMARC policy up in stages to p=reject.

If you would rather not manage the Host-field quirks, the chunking, the lookup limit and the policy timing yourself, that is exactly what we do. The done-for-you DMARC service takes a Squarespace-hosted domain from p=none to p=reject safely, with continuous monitoring and change alerts so a future DNS edit in Squarespace never silently breaks your authentication. Start by running your domain through the DMARC checker to see exactly where you stand today.

How to add DMARC, SPF and DKIM records on Squarespace