Scope and provider-specific configuration
Email Campaigns sender verification is a different workflow from hosting a website or publishing arbitrary DNS records. The current Squarespace guide says Squarespace-purchased domains and domains migrated from Google Domains are automatically verified. Third-party domains require the records shown by Email Campaigns. Verify the actual sender configuration even when the website works.
Open Email Campaign settings, add the sender name and email address if needed, and complete the inbox-code verification. Under Sender details choose Authenticate. The window supplies a CNAME and TXT record. The documented DKIM CNAME is squarespace._domainkey pointing to squarespace-domainkey.squarespace-mail.com; use the values actually shown in the account. The TXT record is at _dmarc and its Data value comes from that window. Review an existing domain-wide DMARC policy before changing it. Do not publish competing DMARC records or weaken an established policy merely to reproduce a setup example.
Publish through the actual DNS host. For Nameserver Connect, Squarespace describes Domains managed by third-party, Edit, DNS settings and Custom Records. For DNS Connect, use the external provider. After saving, check whether Domain is unauthenticated disappears from sender details. The guide allows up to 48 hours for resolution, which is an operational estimate rather than proof of universal propagation.
A material change from older instructions is that Squarespace has removed the SPF-record requirement from this verification workflow. Do not add a stale Squarespace SPF include taken from another tutorial. The guide also warns that a p=reject domain cannot use those sender details until verification is complete. Preserve that policy and finish authentication rather than treating enforcement as the defect.
The decision that matters
Test an actual campaign route after domain verification, especially when the domain already has DMARC enforcement.
Verify the published records and the real sending path
Record the change owner, sending product, domain, approved maintenance window and prior DNS answers before editing. Obtain the current record values from the named account or documented provider workflow. Separate values supplied by the provider from choices your organization controls, such as DMARC policy and reporting recipients. Existing mailbox MX, unrelated verification TXT records and active DKIM selectors are not cleanup candidates merely because a new service is being added.
Query the authoritative name servers for each exact owner and record type after publication. Record the query time, responding server and complete answer. Compare TXT strings as one logical value where the DNS response splits them into character strings. Check CNAME targets as well as the starting alias. Then compare a recursive-resolver answer to identify caching differences. A successful provider validation is useful evidence of configuration, but it does not establish what an actual recipient received.
Send only an authorized test to a controlled recipient using the intended product route. Retain the raw message and the trusted receiving system's Authentication-Results. Record the visible From domain, SMTP MAIL FROM or observed Return-Path domain, every DKIM d= and s= value, SPF and DKIM outcomes, and the receiver's DMARC result. A passing SPF or DKIM check supports DMARC only when its authenticated domain aligns with the visible From domain under the applicable policy. Reply-To and a branded display name are not alignment identities. RFC 7208, RFC 6376 and RFC 9989 provide the protocol basis for these distinctions.
Acceptance worksheet, recovery and evidence limits
This is an original acceptance worksheet, not a report of live testing. Mark each gate pending until evidence exists: account scope confirmed; previous DNS captured; exact new owner/type/value published; provider verification complete; intended route exercised; received identities recorded; aligned authentication confirmed; other senders unaffected. Assign a person and evidence file to every gate. A red gate blocks rollout even when the provider dashboard is green.
If a test fails, first distinguish missing publication, stale cached data, inactive provider configuration, wrong outbound route and nonaligned authentication. Correct the smallest demonstrated defect and test again. Do not weaken DMARC or delete other senders' records simply to make one test pass. If a change harms existing mail, use the approved recovery plan and the captured pre-change configuration, coordinating any provider-side sender change as well as DNS. Retain old keys while queued messages or an approved overlap still require them.
No customer tenant, authoritative before/after change or real received message was available for this manuscript. The retained sources support the documentary workflow; they do not satisfy the commissioned live-evidence gate. Independent checker review and human SME approval remain pending. Do not describe this guide as field-validated or publish it as having passed those gates.
Resolve the pending sender without weakening policy
Written case SQ-01 assumes hello@example.com completed inbox-code verification, but its third-party domain still shows unauthenticated and has an existing p=reject policy. The generated DKIM record has not been published; current SPF and received-message results are unknown. The campaign owner should keep the release pending while the DNS owner completes and verifies the approved record set. Do not replace p=reject with a monitoring policy to bypass the activation problem. Squarespace’s removed SPF requirement concerns this verification workflow, not permission to delete a policy used by other senders. No account, DNS edit or campaign was executed.
For a Squarespace domain connected to a different site, its sender-details guide directs verification on that site first or use of the third-party-domain route. Automatic verification is therefore not a reason to ignore the actual site association or pending status.
Preserve the enforcement boundary
RFC 9989 Section 7.4 requires valid DKIM, not SPF alone, for domains publishing p=reject, and warns about indirect-mail and mailing-list interoperability. A single successful direct-message test is not proof that every legitimate route is ready for stronger policy. Keep existing approved protection while diagnosing the actual gap; any policy change needs its own decision.