Will Switching Website Builders Break My Email?

Switching website builders does not have to touch your email at all — but it will, by accident, if you don't know which DNS records belong to the website and which belong to email. A domain name points to several services at once through different DNS record types. Change the wrong one, or let a migration wizard "clean up" your DNS, and mail stops flowing while the website looks fine. This is how the pieces fit together, which records to protect, and a cutover order that keeps mail running.

Which parts of my domain does a website move touch?

• Domain registrar — where you registered the domain name and who you pay to keep it (GoDaddy, Namecheap, Squarespace Domains, and others).
• DNS host — whoever's nameservers answer for your domain and hold its records. This is often the registrar by default, but not always; a domain can be registered at one company and have its DNS managed somewhere else entirely.
• Website host — the server or platform that serves your actual pages, pointed to by an A record (an IP address) or a CNAME record.
• Email host — the mail service (Google Workspace, Microsoft 365, your builder's own mailboxes, or another provider), pointed to by MX records and authenticated by a few TXT records.

The trap: many all-in-one builders bundle all four into one dashboard, so it's easy to think of "changing my website" as one action, when it's really one DNS zone with several independent record sets. Moving the website only requires changing the records that point to the website. Everything else, correctly left alone, keeps working.

Which DNS records keep email working?

• MX (Mail Exchange) — tells the internet which mail server accepts email for your domain. GoDaddy's own explainer puts it simply: "an MX record... tells email services where to deliver emails for a specific domain" (GoDaddy). If you use Google Workspace, Google's current MX value is smtp.google.com with priority 1; older accounts may still use aspmx records, which Google says keep working (Google Workspace Admin Help).
• SPF (Sender Policy Framework) — a TXT record listing which servers are allowed to send mail as your domain. Your email provider publishes the exact include: value to add; copy it from their setup page rather than from a generic guide.
• DKIM (DomainKeys Identified Mail) — a TXT record holding a cryptographic key your mail provider uses to sign outgoing messages so receiving servers can verify they weren't altered.
• DMARC (Domain-based Message Authentication) — a policy record that tells receiving mail servers what to do with messages that fail SPF or DKIM. Google's setup guidance says to allow 48 hours after setting up SPF and DKIM before setting up DMARC (Google Workspace Admin Help).

None of these four record types is an A, CNAME, or website-related record. A clean website migration edits only the records that point to your pages and leaves MX, SPF, DKIM, and DMARC exactly as they were.

What order should I change things in?

1. Before touching anything, export or screenshot your domain's full current DNS zone — every record, not just the ones you think matter. This is your rollback copy.
2. Identify every MX, SPF (TXT starting v=spf1), DKIM (TXT, usually with a ._domainkey host), and DMARC (TXT at _dmarc) record, and mark them "do not touch."
3. Set up the new website host and get its required A/CNAME records without submitting them yet if your control panel allows a staged change; test the new site on a temporary or staging subdomain first if the platform supports it.
4. Change only the website-pointing records (A/CNAME for the root and www) to the new host, at the DNS host that actually controls your zone — which may or may not be your registrar.
5. Wait for DNS propagation (commonly up to 48 hours, per most registrars' own guidance) before assuming a record change has failed.
6. Re-check your mail records immediately after the change using any DNS lookup tool, and send a real test email in both directions.
7. Only then cancel the old website host, once the new site is confirmed live and mail is confirmed unaffected.

What traps come with a domain or email bought through the builder?

Changing nameservers moves your whole DNS zone. Some builders ask you to point your domain's nameservers at them instead of adding a few records. The moment nameservers change, the old DNS host's records stop being used, mail records included. Before you switch nameservers, recreate every MX, SPF, DKIM and DMARC record in the new DNS zone, check them with a lookup tool, and only then make the switch. If the builder offers record-level connection (pointing only A/CNAME records at it), that is the lower-risk option for email.

Squarespace + Google Workspace. If you signed up for Google Workspace through Squarespace, Squarespace automatically tries to add Google's MX records to the domain's DNS, and warns that any other MX records already present will block your mail from sending or receiving — they need to be removed, not layered on top (Squarespace). If you later move your website off Squarespace but keep the domain and Google Workspace, be careful that whatever migration tooling you use only touches the A/CNAME records for the site and leaves those Google MX records alone.

Wix Mailboxes. Wix ties your email setup to how the domain connects to Wix: if the domain uses name servers, you add your provider's MX records inside the Wix DNS panel; if it's connected by "pointing" instead, Wix says you must configure those records with your actual domain host, not inside Wix, because Wix isn't the DNS authority for a pointed domain (Wix). Know which connection method your domain uses before you start, or you'll edit records in a panel that isn't actually authoritative for your DNS.

GoDaddy email. If your site was built in GoDaddy Websites + Marketing and your email is also bought through GoDaddy, both hang off the same domain's DNS records. When you point the domain at a new website host, edit only the A/CNAME entries and leave the MX entries (the Name, Priority, Value and TTL fields GoDaddy documents) as they are (GoDaddy).

What should I check before the switch?

• Full DNS zone exported or screenshotted, dated, and saved somewhere outside the DNS panel itself.
• Every MX, SPF, DKIM, and DMARC record identified and labeled "do not touch."
• Confirmed which company actually hosts your DNS (not assumed from who you pay for the domain), and whether the new builder wants a nameserver change.
• New website host's required records gathered in advance.
• A test email sent and received successfully right before the cutover, so you have a known-good baseline.
• A named person responsible for re-checking mail records within the hour after the DNS change goes live.

What if my email breaks anyway?

If mail stops flowing after a change, restore the exact MX, SPF, DKIM, and DMARC records from your saved pre-cutover export at whichever DNS host is authoritative for your domain — this is reversible as long as you kept that copy and you know where DNS is actually managed. Don't guess new values from memory or from a generic guide; use the exact strings your provider issued, since a single missing character in an SPF or DKIM record silently fails authentication rather than throwing an obvious error. If you're not sure which DNS host is authoritative, a dig MX yourdomain.com or any public DNS lookup tool from a few different locations will show you which servers are actually answering, which tells you where the real fix needs to happen.

If you're moving off Squarespace, Wix, or GoDaddy's builder as part of this, our migration guides cover the website side of the move: migrate from Squarespace, migrate from Wix to an AI website builder, and migrate from GoDaddy's website builder.