SUKI SONG focus Sites — from $3,000 Book a call

Guide

Squarespace moved my domain and now my email goes to spam: the three records a platform move drops, and how to put them back

· A field guide by Suki Song

01 Read

The pattern is always the same. A domain moves: Google Domains to Squarespace, an old Wix site to a new Framer one, a designer's account to yours. The website comes up fine. Two weeks later a client says your quote went to their spam folder, then another does. Nothing about your email changed. What changed is that the DNS zone was rebuilt on the new platform and three text records did not come along.

Since February 2024, Gmail and Yahoo have made SPF, DKIM, and DMARC the baseline for inbox placement, and they require all three outright from anyone sending at volume. Miss one and a growing share of your mail is filtered, quietly, with no bounce to tell you.

Read one header first

Send an email from your business address to a personal Gmail. In Gmail, open it, click the three dots, choose "Show original." Near the top you will see a block like this:

SPF:   PASS with IP 209.85.220.41
DKIM:  'PASS' with domain yourbusiness.com
DMARC: 'PASS'

Three passes in that summary panel (the raw Authentication-Results header further down says the same thing in lowercase) means the records are there and the problem is elsewhere (content, a blocklisted IP, a shared host). Any FAIL, SOFTFAIL, or a missing line names the record you lost. In an Austin production studio's case in September the header read dmarc=none because the record had never existed on the new host; after the fix the same test read dkim=pass spf=pass dmarc=pass.

The three records

  • SPF is a TXT record on the bare domain listing who may send as you. For Google Workspace: v=spf1 include:_spf.google.com ~all. For Microsoft 365: v=spf1 include:spf.protection.outlook.com -all. One SPF record only; two produce a permanent error, which receivers treat as no SPF at all.
  • DKIM is a TXT record at a selector, for Google google._domainkey.yourbusiness.com, holding a public key your provider generates. You copy it from the provider's admin console (Google Admin: Apps, Google Workspace, Gmail, Authenticate email) and paste it as a TXT record at that exact name. Then go back to that same screen and click Start authentication, or Google never signs your mail. On Microsoft 365 it is two CNAME records instead, at selector1._domainkey and selector2._domainkey, which the Defender portal generates for you.
  • DMARC is a TXT record at _dmarc.yourbusiness.com. Start with v=DMARC1; p=none; rua=mailto:you@yourbusiness.com to get reports, then move to p=quarantine once the reports show only your real senders passing. The reports arrive as zipped XML, so plan on a free report reader or someone who can read them.

Put them back in the right account

This is where most fixes fail. The records must be added in the account whose nameservers the domain points at, which after a move is often not the account you are looking at. Run dig NS yourbusiness.com +short (or nslookup -type=NS on Windows) and add the records wherever those nameservers live. There is a full walkthrough in who actually serves your DNS records.

Type  Name                       Value
TXT   @                          v=spf1 include:_spf.google.com ~all
TXT   google._domainkey          v=DKIM1; k=rsa; p=MIIBIjANBg...   (from Google Admin)
TXT   _dmarc                     v=DMARC1; p=none; rua=mailto:you@yourbusiness.com

Wait an hour, sometimes a day, then send the test again and show original. All three should pass. Keep the header; it is your receipt.

What a move also drops

  • MX records, if your email provider is not the new platform. Missing MX means mail stops arriving, which people notice faster than spam-foldering.
  • Verification TXT records for Google Search Console, Bing, and any tool that verified your domain by DNS. They re-verify quietly when the record is back.
  • Subdomain records for booking tools, newsletter platforms, and anything else on something.yourbusiness.com.

When to hand it to someone

If you have more than two platforms in the picture, or the account that serves your DNS belongs to someone who is no longer around, the fix is still thirty minutes but the finding-out is not. Mapping the accounts, restoring the records, sending the test, and writing the register so it does not happen at the next move is the first month of website management.

Frequently asked

My email still goes to spam and all three records pass. What now?

Then authentication is not the cause. The usual next suspects are a shared sending IP with a bad reputation, a new domain with no history, or content and link patterns that trip filters. A warm-up period and a look at the sending platform's reputation tools come next.

Should I set DMARC to p=reject right away?

No. Start at p=none with a report address, confirm in the reports (zipped XML; use a reader) that only your real senders are passing, then move to p=quarantine, and to p=reject once nothing legitimate is being caught. Jumping to reject on day one can drop your own mail.

Does this apply if my email is through the same platform as my site?

Less often. A platform that hosts both usually publishes its own records when it sets up the zone. The pattern in this guide bites when email and site are on different providers, which is most small businesses.

// PALETTE ⌘K · Esc to close