Squarespace DKIM: Review the Right Sending Service

A Squarespace website and a sending service do different jobs. Your site can look correct while the service sending its emails still needs authentication work. Before changing a template or adding a record from a tutorial, identify who sends the message and where the domain's active DNS is managed.

Use Migma to prepare and review the email creative. Give the domain owner a separate task: verify the exact sending service and its current authentication instructions. This Migma-published guide describes a review process, not a promise that design changes or DKIM alone will place messages in the inbox.

Write down the actual sending path

Consider a fictional studio with a Squarespace website, a staff mailbox, and a separate platform for subscriber campaigns. Those three surfaces may share a brand name and domain, but that does not make them one sending system.

Ask which system sends the particular email under review. A staff reply, a website notification, and a marketing campaign can follow different paths. Record the visible From address, the sending platform, the person who owns it, and the evidence that platform provides about domain verification.

Avoid using a screenshot from an unrelated mailbox as proof for the campaign sender. If the complaint concerns one campaign platform, inspect that platform's status and the relevant delivered test message. Keep the creative version fixed while investigating so several simultaneous changes do not obscure what happened.

Confirm the DNS host before preparing changes

Squarespace's official DNS guidance says editing DNS there requires a domain registered through Squarespace or connected through Nameserver Connect. Other configurations require changes with the relevant provider. The page was last updated September 22, 2026, when checked for this guide on October 17.

That makes “our website is on Squarespace” an incomplete answer. Have the domain owner confirm which nameservers are active and where changes belong. If the owner uses a different DNS service, stop preparing a Squarespace-specific change and follow that service's current instructions.

Preserve the existing setup while reviewing. Do not delete mailbox, website, or authentication records merely because another sending service has supplied new ones. DNS changes can affect working services, so the person responsible should review the proposed additions and any genuine conflicts before applying them.

Copy values from the service you will use

Brevo's new Squarespace DKIM article highlights a useful trap: example values are not your account's records. Its walkthrough concerns Brevo. Do not reuse those values for a Migma sending domain, another provider, or a second account.

Ask the sending owner to obtain the current record names, types, and values from the intended platform. Keep each row intact. A correctly copied value under the wrong name is still wrong, and a record saved in an inactive DNS console does not establish that it is publicly available.

For a Migma campaign, use Migma's current domain setup instructions and the records shown for that domain. For a campaign sent elsewhere, use that destination's instructions. Exporting Migma creative into another platform does not transfer authentication approval between the two services.

Keep creative approval useful during the investigation

You can continue preparing a clear Migma draft while domain work is reviewed. Check the sender-facing language, main action, footer facts, and reply invitation against the approved brief. Avoid changing the visible From name repeatedly in the hope that it substitutes for fixing the sending configuration.

Migma's review workflow lets the team inspect the prepared copy and design. Use Email Preflight to review relevant writing, links, inbox previews, and delivery-risk warnings, then rerun checks after edits. These checks reduce avoidable faults; they do not certify a separate provider's DNS setup.

Create a short handoff note with two decisions: the creative is approved for a specified version, and sending is ready only when the responsible owner has verified its configuration. A finished design should not be confused with a completed authentication task.

Ask for evidence at three separate points

First, request confirmation that the intended records are published at the active DNS host. Second, request the sending platform's verification result. Third, review authentication information from a controlled message sent by that actual platform through the owner's established test process.

Treat a pending verification as pending. Record the observation time and follow the current provider guidance for rechecking. Do not invent a fixed propagation deadline or keep replacing records just because the first status check has not changed.

Authentication success also does not settle every delivery question. Audience permission, message content, list health, and receiving systems still matter. If a message is rejected, preserve its full error and assign the investigation to the sending owner rather than making unrelated creative changes.

Keep the final note small: which sender was checked, where DNS lives, who approved the records, what evidence was reviewed, and which creative version is ready. Start the design in Migma, then connect its release to verified sending readiness rather than to the website's hosting brand.

Frequently Asked Questions