How to Add SPF, DKIM, and DMARC Records in Squarespace

Adding SPF, DKIM, and DMARC records in Squarespace is a necessary step before sending transactional or campaign email from your own domain. The DNS work is straightforward once you know which values belong at the root domain, which belong on a subdomain, and how Squarespace treats the Name field.

This guide covers the full setup for a domain bought through Squarespace or managed there through Nameserver Connect. It explains where to find DNS management, what each email-authentication record does, how to enter it safely, and how to avoid the Squarespace-specific host-name mistake that can quietly break DKIM or return-path setup.

Before you add email DNS records: confirm Squarespace controls DNS

A domain can be registered with Squarespace without Squarespace necessarily being the place where its live DNS records are hosted. That distinction matters because publishing records in the wrong dashboard does nothing for recipient mail servers.

As of writing, Squarespace says you can edit DNS records in Squarespace when the domain is registered through Squarespace or connected to a Squarespace site through Nameserver Connect. If the domain is connected through DNS Connect, uses custom nameservers, or is delegated to a DNS provider such as Cloudflare, the authoritative DNS zone is elsewhere. Add the records at that DNS provider instead.

A quick way to think about the setup is:

• Registrar: the company through which the domain was purchased or renewed.
• DNS host: the service whose nameservers publish the records the internet actually sees.
• Email provider: the service that sends mail, receives mail, or both.
• Squarespace website: the place your site may be hosted; it does not automatically determine who hosts your email or DNS.

Do not assume that changing a record in Squarespace will take effect merely because your website is built with Squarespace. If you previously changed the domain to custom nameservers, Squarespace’s DNS panel is no longer authoritative. The zone must be edited at the provider named by those nameservers.

Before making changes, save a copy of the records currently visible in the DNS panel. Screenshots are useful, but a text list is better for long TXT values. You are unlikely to need to remove website records, MX records, or existing verification records to add email authentication. The safer rule is to change only the specific records your sending provider instructs you to add or replace.

Where to find DNS management in Squarespace

For a Squarespace-managed domain, the current navigation path is:

1. Open the Domains dashboard in your Squarespace account.
2. Select the domain name you want to authenticate.
3. In the side panel, select DNS.
4. Select DNS Settings.
5. Scroll to Custom Records.
6. Select Add record.
7. Reauthenticate if Squarespace requests your password or two-factor authentication confirmation.

The labels can change as Squarespace updates its dashboard, so treat the sequence above as the current path rather than a permanent UI guarantee. The important landmarks are the domain-level DNS section and the Custom Records area; that is where TXT and CNAME records for email authentication are added.

If you manage a third-party domain through Nameserver Connect, Squarespace may group it under Domains managed by third-party before you open its DNS settings. If you cannot find DNS controls for the domain, stop before adding records anywhere else and determine whether the domain is using Squarespace nameservers or an external DNS provider.

What fields Squarespace shows for a custom record

Squarespace custom DNS records generally use these fields:

• Type: the DNS record type, such as TXT or CNAME.
• Name: the host or label to the left of your domain.
• Data or Text: the value supplied by your email provider.
• TTL: the cache lifetime. Squarespace custom records use a four-hour default TTL, although it can be changed.
• Priority: used for some record types, particularly MX; it is not normally relevant to SPF, DKIM, DMARC, or return-path CNAME records.

For email authentication, do not improvise a value because it looks similar to an example. Copy the value from your sending platform exactly. Selector names, DKIM public keys, and return-path destinations are account-specific.

For Volanea, retrieve the current domain-authentication values from the sending domain setup flow or the email API reference and setup guides. The records shown there are the source of truth for your account, especially for DKIM selectors and custom return-path targets.

The SPF, DKIM, DMARC, and return-path record table

The table below shows the expected shape of the records. It intentionally uses placeholders rather than provider-specific credentials or hostnames. Replace every bracketed placeholder with the exact value your sending provider supplies.

There are two important qualifications:

1. DKIM can be either CNAME or TXT. Many modern email providers use CNAME records because they can rotate or manage DKIM keys without asking you to publish a new public key. Some providers instead give you a TXT record containing a v=DKIM1 public key. Add the type you were given, not both alternatives for the same selector.
2. A return-path record is provider-specific. Some platforms configure it automatically, some call it a custom MAIL FROM domain, and others require one or more CNAME or MX/TXT records. Do not create a generic bounce record unless your provider’s domain-authentication instructions explicitly ask for it.

SPF in Squarespace: authorize senders without creating duplicates

SPF is a TXT record that states which sending systems are allowed to use a domain in the SMTP envelope sender, often called the return-path or MAIL FROM address. Receiving servers evaluate SPF against that envelope domain, not merely the visible From address.

A typical SPF value looks like this:

v=spf1 include:spf.example-email-provider.com ~all

The parts mean:

• v=spf1 identifies the record as SPF.
• include: authorizes a sending provider’s published SPF policy.
• ~all is a soft-fail instruction for senders not otherwise authorized.
• -all is a hard-fail instruction and should be used only after you have inventoried every legitimate sender.

Use one SPF record at the root domain

The most common SPF failure is not an invalid string. It is publishing two separate SPF TXT records at the same root host.

For example, this is wrong:

@ TXT v=spf1 include:_spf.google.com ~all
@ TXT v=spf1 include:spf.example-email-provider.com ~all

A receiving server can see multiple SPF policies and return a permanent SPF error. The fix is to merge legitimate mechanisms into one record:

@ TXT v=spf1 include:_spf.google.com include:spf.example-email-provider.com ~all

Do not delete an existing SPF include just because you are adding a transactional-email platform. Your domain may use Google Workspace, Microsoft 365, a help desk, a CRM, an invoicing system, or another service that also sends as the domain. Removing its authorization can cause its mail to fail SPF after the next DNS cache refresh.

What to enter in Squarespace

For a root-domain SPF record, choose TXT, enter @ in the Name field, and paste the full SPF policy into the Text or Data field. Do not wrap the whole record in quotation marks unless the provider explicitly provides them as part of the value. Squarespace’s interface treats the field as a TXT value; the DNS presentation layer handles the necessary quoting.

If you already have an SPF record, edit that existing root TXT record rather than adding a second one. Check the exact existing text first. A plain TXT record at @ is not necessarily SPF; SPF is identified by its v=spf1 prefix.

SPF has practical limits

SPF evaluation has a DNS lookup limit. Excessive include, a, mx, redirect, exists, or other lookup-causing mechanisms can lead to a permerror, even when the record looks logically correct. This is why an ever-growing collection of includes is not a long-term email architecture.

A custom return-path subdomain can reduce complexity. For example, a service might send with an envelope sender under bounce.example.com while users see billing@example.com in the From field. SPF for bounce.example.com can then be specific to the sending service, while the root example.com SPF remains focused on mailbox providers and other root-domain senders. Whether this is appropriate depends on how your email provider implements alignment and its domain-authentication workflow.

DKIM in Squarespace: publish the selector exactly

DKIM adds a cryptographic signature to each message. The sending server signs selected headers and content; the recipient retrieves the public key from DNS and verifies the signature. A valid DKIM result helps prove that the message was authorized by the signing domain and was not materially modified in transit.

DKIM records live below a selector, not directly at the root domain. A selector is an identifier chosen by the sender, such as s1, mail, k1, or a provider-generated string. The lookup name has this pattern:

[selector]._domainkey.example.com

In Squarespace, you normally enter only the portion before your root domain:

[selector]._domainkey

CNAME DKIM versus TXT DKIM

A CNAME-based DKIM setup might be presented by your provider like this:

Host: s1._domainkey.example.com
Type: CNAME
Value: s1.example.provider-dkim.net

For a Squarespace domain, enter:

Type: CNAME
Name: s1._domainkey
Data: s1.example.provider-dkim.net

A TXT-based DKIM setup might instead look like this:

Type: TXT
Name: s1._domainkey
Text: v=DKIM1; k=rsa; p=MIIBIjANBgkqh...

The public key can be very long. Copy it as one continuous value unless your provider specifically documents a split format. Do not add line breaks, alter punctuation, replace semicolons, or truncate the key. A single missing character makes DKIM verification fail.

The Squarespace-specific host-name mistake

The most common Squarespace error is entering a fully qualified host name in the Name field when Squarespace automatically appends the root domain.

If the provider says the DKIM host is:

s1._domainkey.example.com

and your domain is example.com, enter:

s1._domainkey

Do not enter:

s1._domainkey.example.com

Otherwise, Squarespace can publish the record under a duplicated name such as:

s1._domainkey.example.com.example.com

The same rule applies to a return-path CNAME. If the requested host is bounce.example.com, enter bounce, not bounce.example.com. Squarespace explicitly documents that it automatically appends your domain after the Name value, even though the completed domain may not be shown in the panel.

The exception is the record Data field for a CNAME. The Data field is the destination hostname supplied by your provider, so paste that target exactly as instructed, without trying to shorten it to a local label.

Avoid selector conflicts

A hostname that has a CNAME record cannot also host another record type. If s1._domainkey is a CNAME, do not add a TXT DKIM record at s1._domainkey as well. If Squarespace reports that a name is already in use, check whether an older DKIM record exists for that exact selector.

It is normal to have multiple DKIM selectors for a domain when different email systems use different selector names. For example, Google Workspace might use one selector while a transactional platform uses another. The conflict occurs only when two records try to use the identical hostname in incompatible ways.

DMARC in Squarespace: start with visibility, then enforce

DMARC connects the visible From domain to SPF and DKIM results. It lets a domain owner tell recipient servers what to do when authentication does not align with the From address, while also providing a place to receive aggregate reports.

A starter DMARC policy is commonly shaped like this:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

In Squarespace, enter it as:

Type: TXT
Name: _dmarc
Text: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Do not enter _dmarc.example.com in the Name field. As with DKIM, Squarespace appends the domain.

Understand DMARC alignment

DMARC does not merely ask whether SPF or DKIM passed. At least one passing mechanism must also align with the domain in the visible From header.

For example:

• Visible From: receipts@example.com
• DKIM signing domain: example.com
• DKIM result: pass

That normally gives aligned DKIM.

But this can fail alignment:

• Visible From: receipts@example.com
• SPF envelope domain: mailer.other-domain.test
• SPF result: pass

SPF passed for mailer.other-domain.test, but it does not align with example.com. If DKIM is also missing or misaligned, DMARC fails even though the sending provider technically passed SPF.

That is why a verified DKIM setup is usually central to reliable delivery. A properly configured custom return-path can also allow SPF alignment, but the exact behavior depends on the provider and whether the return-path is a subdomain of the visible From domain.

Choose a DMARC rollout policy deliberately

DMARC has three principal policy directions:

Start with p=none if you are setting up DMARC for the first time. This is not a security endpoint; it is a measurement stage. Use reports to find systems that send mail as your domain, confirm that their SPF or DKIM passes and aligns, and correct unknown senders before moving to enforcement.

Avoid publishing multiple DMARC TXT records at _dmarc. Like SPF, DMARC expects a single policy record at its relevant location. If an old DMARC record already exists, update it carefully rather than adding a second one.

Make reports useful

The rua tag tells receivers where to send aggregate XML reports. The mailbox can be on your domain, such as dmarc-reports@example.com, or handled through a DMARC reporting service. Aggregate reports are not normal message copies; they are structured summaries of authentication outcomes and source IP addresses.

Do not use a personal inbox that nobody monitors. Create a dedicated address or use a reporting service capable of parsing XML and grouping results. The goal is to detect legitimate systems that need authentication and unauthorized systems that may be spoofing your domain.

Return-path and custom MAIL FROM records: what they solve

The return-path is the SMTP envelope sender address used for bounces and delivery-status notifications. It is separate from the human-visible From address. A recipient might see orders@example.com in the From header while bounces are sent to something like bounce@bounce.example.com.

Email providers may call the corresponding DNS feature a custom return-path, custom MAIL FROM domain, bounce domain, or envelope sender domain. The naming varies, but the purpose is similar: allow the platform to use a subdomain you control for bounce handling and, in some configurations, SPF alignment.

A provider may request a CNAME in this general form:

Type: CNAME
Name: bounce
Data: [provider-specific-bounce-target]

That publishes bounce.example.com as an alias to the provider’s configured destination. Enter the provider’s target exactly. Do not replace it with your website URL, your root domain, or a guessed hostname.

Do not confuse return-path with reply-to

These fields have different jobs:

• From: what recipients see as the sender.
• Reply-To: where replies go when the recipient presses Reply.
• Return-Path / MAIL FROM: where SMTP bounce processing occurs.
• DKIM d= domain: the domain that cryptographically signs the message.

A customer-service reply address can be valid even if it is unrelated to the bounce domain. Likewise, a return-path setup does not substitute for DKIM or DMARC. It is one component of a broader authentication and delivery design.

Check whether the provider requires additional records

Not every custom MAIL FROM setup is one CNAME. Depending on the sender, it may also require TXT verification, MX records for handling bounces, or a provider-controlled subdomain. Follow the instructions for the sending domain exactly and do not delete a record simply because it is not one of the four types summarized in this article.

If you use separate systems for transactional mail and marketing campaigns, consider distinct subdomains such as notify.example.com and mail.example.com. This can simplify operational separation, reputation analysis, and SPF authorization. It does not eliminate the need for DMARC alignment; it makes the sending architecture easier to understand and govern.

A safe order for publishing the records

DNS changes are less risky when you add records in a controlled order and verify each one. Use this sequence:

1. Inventory current records. Identify existing SPF, DKIM, DMARC, MX, and vendor-verification records. Preserve a copy before editing.
2. Confirm the authoritative DNS provider. If Squarespace is not serving the active nameservers, make the changes elsewhere.
3. Add DKIM and provider verification records. These are usually additive and do not require changing existing root-domain records.
4. Add the return-path or custom MAIL FROM record. Use only the provider-assigned host and target.
5. Merge SPF if required. Edit the one existing root SPF policy rather than adding another.
6. Publish DMARC monitoring. Add one _dmarc TXT record with p=none and a monitored reporting destination.
7. Wait for DNS visibility, then verify in the sending platform. Do not assume the Save button means external DNS has propagated.
8. Send a controlled test. Inspect authentication results at a receiving mailbox before sending production traffic.

Squarespace notes that DNS changes can take 24 to 48 hours to update, and its custom records use a four-hour TTL by default. In practice, some lookups update sooner, but planning around the full propagation window avoids unnecessary troubleshooting. Repeatedly deleting and recreating records during that window can make diagnosis harder.

How to verify that the setup works

A green check in an email platform is useful, but it is not the only validation. Confirm both DNS publication and message-level authentication.

Verify the DNS record names

Use a DNS lookup tool or command-line query to inspect the exact names:

TXT example.com
TXT _dmarc.example.com
CNAME s1._domainkey.example.com
CNAME bounce.example.com

The returned names and values should match the provider’s instructions. A DKIM record found only at s1._domainkey.example.com.example.com is a clear sign that the fully qualified host was entered into Squarespace’s Name field.

For CNAME targets, Squarespace advises removing a trailing period from the Data value because its system cannot save values formatted with a final dot. This is a DNS-interface detail, not a reason to alter the hostname itself.

Verify the message headers

Send a test message to a mailbox where you can view original headers. Look for an Authentication-Results header. The desired outcome is generally:

spf=pass
dkim=pass
dmarc=pass

Also inspect the DKIM signing domain and the SPF envelope domain. A simple SPF pass is not enough if it does not align with the visible From domain for DMARC purposes.

If DMARC fails while DKIM passes, compare the DKIM d= domain with the From domain. If SPF passes but DMARC fails, compare the envelope sender domain with the From domain and check whether relaxed or strict alignment applies to your policy. Those comparisons usually reveal whether the issue is an unverified provider domain, an incorrect From address, or an incomplete custom return-path configuration.

Troubleshooting Squarespace email DNS problems

Most failures fall into a small set of patterns. Work through them before changing a policy or opening a support request.

The record saved but external tools cannot find it

First, verify that Squarespace’s nameservers are authoritative for the domain. If custom nameservers are configured, records entered in Squarespace may remain invisible because another provider is serving live DNS.

Second, allow for caching. Check the record at the precise hostname and confirm there was no typo in the Name field. A DKIM selector with one missing character is a different DNS name; it will not partially work.

Squarespace says the name is already in use

A CNAME cannot coexist with other DNS records at the same hostname. Look for an older CNAME, TXT, or other record using the same selector or bounce label. If the old record belongs to a retired provider, remove it only after confirming it no longer serves a live sending system.

For SPF and DMARC, the issue may be duplicate policies rather than a UI-level conflict. Review all TXT records at @ for v=spf1 and all TXT records at _dmarc for v=DMARC1.

DKIM verification stays pending

Check the record type first. A provider expecting a CNAME will not validate a TXT record, and a provider expecting a TXT public key will not validate a CNAME. Then compare the selected hostname and target character by character.

The two Squarespace-specific checks are especially important: omit the root domain from the Name field, and omit a trailing period from a CNAME Data value if Squarespace rejects it. Finally, make sure you are authenticating the same domain or subdomain used in the visible From address.

SPF fails after adding a new sender

Look for a duplicate SPF record or an accidental replacement of the old SPF policy. If you use multiple services, legitimate include: mechanisms usually need to be combined into one policy.

Also consider the envelope domain. A provider may send with a provider-owned return-path unless you configure its custom MAIL FROM option. That can make SPF pass without aligning to your From domain; DKIM may still provide the aligned path that DMARC needs.

DMARC fails after publishing p=reject

Do not treat p=reject as the first successful setup milestone. It is an enforcement setting. Roll back to a monitoring policy only if needed to restore legitimate mail, then use reports and header results to find the system that is failing alignment.

Common causes include SaaS tools sending as your brand without DKIM, an employee using an unauthorized SMTP server, a forwarded message that breaks SPF, or an old automated system using a different From domain than expected. Fix the sender configuration rather than weakening authentication indefinitely.

A practical final checklist

Before considering the domain ready for production sending, confirm all of the following:

• The domain’s authoritative nameservers point to Squarespace or you made the change at the actual DNS provider.
• The SPF record is a TXT record at @ and there is only one v=spf1 policy for that host.
• Each DKIM selector uses the exact record type, host, and value assigned by the sender.
• DKIM and return-path host names in Squarespace omit the root domain suffix.
• The DMARC record is a single TXT record at _dmarc.
• DMARC begins with a monitored reporting arrangement and an intentional policy.
• A custom return-path record exists only if the provider requires or supports it.
• External DNS lookups show the expected records.
• A real test message shows SPF, DKIM, and DMARC passing in the recipient headers.
• You have recorded which tools are authorized to send mail for each domain or subdomain.

Email authentication is not a one-time technical chore. Every new support tool, billing platform, product-email service, or marketing system can become another sender using your domain. Keep an inventory, review DMARC reports, and make domain authentication part of the launch checklist for every new email source.

FAQ

What should I enter as the SPF host in Squarespace?

For an SPF policy that applies to the root domain, enter @ in Squarespace’s Name field. Put the full v=spf1 ... string in the Text or Data field.

Should I enter my full domain in the Squarespace DKIM host field?

No. If the requested DKIM host is selector._domainkey.example.com, enter only selector._domainkey for a Squarespace-managed example.com domain. Squarespace appends the root domain automatically.

Can I have more than one SPF record in Squarespace?

No. You can have multiple TXT records at the root, but only one SPF policy beginning with v=spf1. Merge the authorized sending services into that one record.

Is a return-path record required for DMARC?

Not always. DMARC can pass through aligned DKIM even when SPF is not aligned. A return-path or custom MAIL FROM record is useful when your provider supports it and you want an envelope-sender subdomain under your control, but follow the provider’s exact setup instructions.

How long do Squarespace DNS changes take?

Squarespace says DNS updates can take 24 to 48 hours. Its custom records have a four-hour default TTL, but external caches and the prior TTL can affect when a change becomes visible everywhere.