A website move can leave your existing email service in place. The risky moment is often a change of DNS provider or nameservers, when mail records may be missed. Treat the move as two checks: the new website must open, and the existing mail routes must still work.
Make a before-and-after DNS worksheet
Save the active zone before the move. For every MX record and email-related TXT or CNAME, record its name, type and value, then compare it with the new zone. Ask whoever handles the website to identify form and order-notification senders too. Keep mail settings unchanged unless you are deliberately moving email. After switching, test an external enquiry, a reply and a website notification. Changing nameservers does not copy messages, and adding two providers’ MX records does not assign individual users to different services.
Find out who manages each service
Four companies may be involved: the domain registrar, DNS provider, website host, and email provider. Sometimes one company sells all four services, but each still has a separate role.
The registrar renews the domain name. The DNS provider holds its settings. The website host serves the site. The email service receives and stores messages. Saying that a domain is “with a provider” doesn't tell you where its email records need to be edited.
Find the dashboard for your active DNS zone and save a copy of its current values. If a contractor manages the website, ask which records support the store, help desk, payment notifications, and any other services you use.
Recognise the records you need to preserve
A typical website uses A, AAAA, or CNAME records. MX records direct incoming email. To host email separately, you can usually change the relevant records in the existing DNS zone. Moving all DNS management to another company is often unnecessary.
TXT records can also relate to email. They can verify domain ownership and hold sender settings. SPF identifies permitted sending sources. DKIM allows a message's signature to be checked. DMARC describes the policy for checking the domain in the sender's address.
The values depend on the services you use. Your store might send receipts through a separate platform while business correspondence stays with TrekMail. Account for both sending sources. Do not delete records simply because their names are unfamiliar. The email DNS guide explains their purpose.
Agree exactly which change the website needs
Ask the website provider whether it needs an individual DNS record or a complete nameserver change. These are different jobs. Updating the site's A record can leave the rest of the existing zone in place. Changing nameservers hands authority for the whole domain to another zone, which must already contain the mail records you intend to keep.
Use a short worksheet with one line per record: purpose, current name, type, value, new value if any, and the person approving the change. Include priorities for MX records. Save the actual record values, not just a screenshot saying that the domain is connected. A provider's green status may describe its website connection while saying nothing about another company's mail service.
Record ownership too. The web developer may know the site configuration, while an office administrator knows the mail service and a finance colleague pays for domain renewal. Choose one person to collect approval before the nameservers change. That person should be able to reach both providers through a contact method outside the domain being moved.
Do not cancel a bundle until you know which services the cancellation removes. An old website package may still contain mailboxes, DNS hosting or the domain registration. Keeping the email provider means keeping the required service active, even if nobody uses its website builder any more. Check the contract and account screens rather than assuming every part of a bundle can be cancelled separately.
Check the mail people actually use
Choose a small set of representative addresses before the move. Include an ordinary employee mailbox, a public alias, a shared address if you use one, and the address receiving contact-form notifications. Note which person can verify each result. The aim is to cover different delivery arrangements rather than sending the same test to every employee.
Send from an unrelated external mailbox, check where the message arrives, and reply. At the outside receiving account, inspect the sender address and the destination used when replying again. Repeat the check for a website form or order notification after the new site goes live. A form that displays “thank you” has accepted a browser submission; that message alone doesn't confirm email delivery.
If the new site uses a different application to send notifications, preserve its existing approved sending arrangement or configure the new one deliberately. Changing the site's host does not automatically transfer SMTP credentials. Record who can update those credentials without putting passwords into the DNS worksheet or a broadly shared handover document.
Keep website rollback separate from mailbox migration
If you only moved the website, there should be no reason to copy mailbox contents or change everyone's mail password. Changing DNS sends future connections to the configured destination; it does not move stored messages between providers. If email is also moving, give that work its own inventory, transfer plan and acceptance checks.
Keep the saved DNS zone until the move is accepted. If a rollback is needed, identify the records responsible for the failing service before restoring a whole zone. Restoring an old website record may be enough for a site problem, whereas replacing every record could undo a valid mail change made in the meantime. Agree the recovery steps with whoever controls the active zone and repeat the same outside-to-inside-and-back tests after any correction.
If one check fails
Keep the old hosting and mail access available while you investigate. If only the contact form fails, inspect the application’s sending settings before changing the domain’s incoming MX. If messages do not arrive anywhere, compare the active mail records with your saved zone and ask the responsible provider to check the route. When the mail provider stays the same, employees normally keep the same app settings. Delay cancelling the previous website-hosting package until the checks and any separately planned archive transfer are complete.
Further setup
For domain verification and DNS setup, follow the TrekMail setup guide.
Related reading
- Keeping email separate from website hosting
- Set Up Email on My Domain: Fix Login Works, Mail Doesn't
- Get your business email ready before the website launches
- How do we keep old email addresses after a company rebrand?
- Portal emails arrive, but customer replies vanish. What now?
