How Do I Connect a Domain to a Website Without Breaking Email?

Connecting a domain to a new website does not necessarily require moving email. The safer approach is to identify which DNS settings direct website traffic, which support email and which other services depend on the domain before changing anything.

There is no universal set of values to paste into every account. Your website and email providers must supply the correct records for your setup. If the instructions are unclear or existing records conflict, pause and ask the providers to resolve them.

First identify the accounts involved

Find the domain registrar, DNS provider, website host and email provider. They may be four different organisations.

Confirm who can make changes, which account has recovery access and who is available if something stops working. Our guides to domains versus hosting and checking domain ownership help untangle those responsibilities.

Moving a website is a poor time to discover that the only person with DNS access has left the business.

Understand what you are changing

Website connections commonly involve A, AAAA or CNAME records, depending on the provider and hostname. Email delivery commonly depends on MX records, with additional records used for authentication and other functions.

Cloudflare’s email DNS documentation explains the roles of common mail-related records. Follow your own email provider’s exact requirements; do not copy illustrative values from an unrelated tutorial.

Do not assume every A record belongs to the website. A hostname used by a mail server may also depend on one. Nameserver changes can affect the whole DNS zone, not just the website.

Create a before-and-after change record

Export or securely record the current zone and take screenshots of relevant settings. Keep sensitive account credentials out of the worksheet.

Item	Before the change	Intended after the change
Root domain website record	Current type, value and TTL	Exact new provider instruction
www website record	Current type, value and TTL	Exact new provider instruction
MX records	Every value and priority	Preserved unless email is intentionally moving
Mail authentication	Existing SPF, DKIM and DMARC records	Preserved or provider-approved changes
Other services	Verification and service records	Explicit retain/change decision
Recovery	Previous values and responsible person	Tested access to restore settings

Add the date, approver and reason beside each intended change. This turns “I changed something in DNS” into a usable incident record.

Prefer the smallest authorised change

If the existing DNS service can point the website to its new host, ask whether changing only the necessary website records is sufficient.

If nameservers must change, the replacement DNS zone needs to include the required records before the switch. Ask the providers to coordinate the migration, including any DNSSEC implications. Do not disable unfamiliar security settings just to make an error disappear.

Keep email migration as a separate, explicitly planned task unless there is a clear reason to combine it. Our plain-English DNS guide provides the wider background.

Check the website and email separately

After the change, test the root address and www address over HTTPS. Confirm the intended site appears and that redirects behave as planned.

For email, send a message from an external account to the business and reply from the business account. Check more than one important mailbox where practical. Test the website enquiry form separately: a working mailbox does not prove the form’s sending service is configured correctly.

Keep the old website available for an agreed transition period where appropriate. DNS caches can retain earlier answers, so different visitors may temporarily reach different destinations.

Know when to stop and restore

Agree what counts as failure before starting: an unavailable website, missing incoming mail or a broken customer journey. Set a contact route that does not depend solely on the affected email domain.

Restoring earlier records is not guaranteed to produce an immediate recovery everywhere because cached answers may persist. That is another reason to have provider support available rather than improvising under pressure.

Finish with an updated handover

Record the final settings, test results and account responsibilities. Use the launch checklist for the rest of the site, and revisit your hosting access record if ownership changed.

Verify that the website has moved successfully and that the other services using the domain still work.

Thinking about your own rebuild?

Tell us about your business, your current website and what you would like to improve. We will help you work out the next step.

Tell us about your project↗

• Website technology
• Small business