Scope and provider-specific configuration
Squarespace is the DNS publishing surface in this guide, not the system that signs mail. A Squarespace registration or website does not by itself establish that Squarespace hosts the authoritative zone. The TXT guide covers Squarespace domains and third-party domains connected through Nameserver Connect. With DNS Connect, make the change at the third-party DNS provider instead.
Open the domains dashboard, select the domain, then DNS and DNS Settings. Under Custom Records choose Add record and complete the account reauthentication requested by Squarespace. Select TXT for an SPF policy, a TXT-form DKIM public key or a DMARC policy. The Name field is relative: Squarespace appends the domain. Use @ for the apex, _dmarc for the DMARC owner, and the supplied selector._domainkey label for a DKIM key. A full owner name entered into a relative field can publish a record at the wrong doubled domain.
Copy the sending service's value, rather than borrowing a key or SPF policy from a different account. For a service that supplies a DKIM CNAME, use CNAME rather than TXT and retain the precise supplied target. A selector already used by another sender is a conflict to investigate, not permission to overwrite it. This guide does not claim a universal TXT chunking or rollback behavior for the editor; inspect the saved authoritative answer and retain the previous records independently.
The decision that matters
Publishing the intended owner name is the central acceptance test; a saved editor row alone is insufficient.
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. This educational guide is not field-validated. Content review, live integration checks and owner release approval are separate gates.
Confirm the provider boundary
For a CNAME target, enter the provider-supplied DNS hostname, not an https URL or path. The current editor does not allow an apex @ CNAME. If custom nameservers are active, publish there rather than resetting delegation as a quick fix. Do not disable DNSSEC or remove website defaults to solve an unrelated email record issue. A long key requires provider-compatible formatting that still produces one logical DKIM TXT record; ask for support if the editor rejects it.
Work through a fictional diagnostic case
Fictional written case only: SQ-01 assumes authoritative nameservers belong to an external DNS provider but the operator saves a DKIM TXT in the Squarespace panel. A lookup at the authoritative server lacks the expected selector. No message signatures or SPF results are known. The DNS owner must publish the approved record at the active provider, without moving nameservers solely to satisfy the panel. Then the mail owner tests the actual sender. No tenant, DNS, server command or message was exercised for this case.
Separate a passing message from enforcement readiness
RFC 9989 Section 7.4 requires valid DKIM for a domain publishing p=reject and cautions about indirect-mail interoperability. A single aligned SPF result does not by itself justify a reject-policy rollout. Review all legitimate routes and policy ownership separately from this provider setup.