Check what is already there
Squarespace auto-applies its own DKIM, SPF and DMARC records to domains it manages. So before you add anything, look at your DNS records for an existing TXT record on the host _dmarc.
If one exists, edit it. Adding a second DMARC record for the same domain does not give you two policies, it gives you an ambiguous mess that receivers may ignore entirely. The same warning applies even more sharply to SPF, where a duplicate record is an outright permerror.
What DMARC does
SPF and DKIM decide whether a message is authentic. DMARC is the part that tells inboxes what to do when the answer is no, and asks them to report back to you.
It is a TXT record published at _dmarc.yourdomain.com. The v=DMARC1 tag must come first. If the policy tag p is missing from an otherwise valid record, receivers treat it as p=none.
Start at p=none. This is not the lazy option.
Going straight to p=reject is how people accidentally block their own invoices, newsletters and booking confirmations. Monitoring first is the officially endorsed path, not a shortcut.
The progression is p=none, then p=quarantine, then p=reject. You only move up a step once your aggregate reports show your legitimate mail passing. Do not guess. Read the reports.
The record to publish
Start here. Replace the address with a real mailbox you will actually read.
Type: TXT
Host: _dmarc
Value: v=DMARC1; p=none; rua=mailto:[email protected]The host is just _dmarc, never _dmarc.yourdomain.com. Squarespace uses relative names and appends your domain for you, so the long form would create _dmarc.yourdomain.com.yourdomain.com, which never resolves. This is the single most common DMARC mistake there is.
Why most DMARC guides you will find are now wrong
Worth knowing, because it will save you from copying a broken record.
DMARC was rewritten in May 2026. RFC 9989 is now the core specification and it obsoletes the old RFC 7489. Nearly every DMARC article online, including ones from names you would trust, still reflects the old spec.
The headline change: the pct tag has been removed. If a guide shows you pct=100, it was written against a spec that no longer applies. Do not include it.
The tags that are valid under RFC 9989 are: v, p, sp, np, rua, ruf, adkim, aspf, fo, psd and t. If you see something else in a template, be suspicious of the whole template.
The 255-character limit on Squarespace
Squarespace caps non-SPF and non-DKIM TXT records at 255 characters. SPF and DKIM get up to 2048, but DMARC falls in the 255 bucket.
A normal DMARC record is nowhere near that, so you will probably never notice. You would only run into it by stacking several long reporting addresses into one record. If your record gets rejected for length, trim the reporting addresses down.
If your reports never arrive
This is the classic "I set up DMARC and heard nothing" problem, and it has a specific cause.
If your rua address is on the same domain as the DMARC record, everything just works. No extra setup.
If your rua points at a different domain, for example a third-party DMARC reporting service, that other domain has to authorise it. The receiving domain must publish a record at yourdomain.com._report._dmarc.theirdomain.com containing at minimum v=DMARC1, with v=DMARC1 appearing first. Some vendors publish a wildcard that covers any domain, so this is often already handled for you, but when reports go missing this is the first thing to check.
The order to do this in
SPF first, then DMARC, then tighten. Publishing p=reject before your SPF is clean is how legitimate mail disappears.
If you want the plain-English version of any of this, we have short explainers on DMARC and SPF. When you are done, run a free check to confirm what your domain is actually publishing.
Run your site through our free safety check to confirm the fix is live, and see what else a shopper would notice.
Run a free checkFrequently asked questions
Does Squarespace add a DMARC record automatically?
It can. Squarespace auto-applies its own DKIM, SPF and DMARC records to domains it manages. Check your DNS records for an existing TXT record on the _dmarc host before you add your own, and edit rather than duplicate.
Should I include pct=100 in my DMARC record?
No. The pct tag was removed from the DMARC specification in RFC 9989, published in May 2026. Most guides online still show it because they have not been updated. The valid tags are now v, p, sp, np, rua, ruf, adkim, aspf, fo, psd and t.
What do I put in the Host field on Squarespace?
Just _dmarc. Not _dmarc.yourdomain.com. Squarespace takes a relative name and appends your domain, so the long form produces _dmarc.yourdomain.com.yourdomain.com and never resolves. This is the most common DMARC setup mistake.
Can I go straight to p=reject?
You can, but you should not. Start at p=none, read your aggregate reports until you are confident every legitimate sender is passing, then move to p=quarantine and finally p=reject. Monitoring first is the officially endorsed approach, not a cautious detour.
I set up DMARC but I get no reports. What is wrong?
If your rua address is on a different domain from the DMARC record, that domain must authorise it by publishing a record at yourdomain.com._report._dmarc.theirdomain.com containing v=DMARC1. Missing that record is the usual reason reports never turn up. If rua points at your own domain, no authorisation is needed.