You can move your restaurant website while keeping email on the same domain. The key is to change the website’s DNS records without removing or replacing the records your email service needs. If the new website requires a nameserver change, copy and verify the mail records in the new DNS zone before making the switch.
Start by identifying who controls your domain, DNS, website, and email. Those may be four different companies. Give each provider a written list of the changes it is responsible for, and arrange a way to restore the previous settings if something goes wrong. A careful plan reduces risk, but it cannot guarantee uninterrupted email.
Inventory the domain and email setup
Your domain is the address guests recognize, such as a restaurant’s name followed by .com. DNS is the set of records that directs different kinds of traffic for that domain. Website visitors and email can use the same domain while relying on different records and providers.
Before approving a website change, collect the following information:
- Domain registrar: Where is the domain registered, and who can sign in? Confirm the account is accessible to the restaurant, not only to a departing designer or agency.
- DNS host: Which provider currently holds the active DNS zone? The registrar and DNS host may be the same company, but they do not have to be.
- Website host: Who controls the current site, and what records does the new provider want changed?
- Email provider: Who hosts your mailboxes, and who can provide the required mail records and help troubleshoot delivery?
- Other senders: Which services send mail using your domain? Consider reservation confirmations, ordering notices, newsletters, and contact forms.
Export the current DNS zone if the host allows it. Otherwise, save a complete record-by-record copy, including names, types, values, priorities, and TTLs. TTL is the time a DNS answer may be cached; it affects how quickly a change may be picked up. Record the current nameservers too. Store the backup somewhere the people handling the change can reach it, without exposing account passwords.
Also list the addresses and aliases the restaurant relies on: for example, a general inbox, a catering address, and an address that forwards to a manager. Ask the email provider how those addresses are configured. DNS alone is not a complete backup of mailbox contents or forwarding rules.
If access is uncertain, sort that out before scheduling the move. The domain ownership guide covers questions to ask about control of the address itself.
Separate website changes from mail changes
First ask the new website provider for the exact DNS changes in writing. A website move might need changes only to website-related records, such as an A record or a CNAME. That can be simpler than moving the entire DNS zone. Do not assume every record at the root of the domain is a website record: mail and verification records can also use that name.
Use the table to review the current zone with your providers. It is a checklist, not a substitute for the values required by your particular services.
| Record or setting | Common purpose | Action before the website move |
|---|---|---|
| A, AAAA, or CNAME | Directs a website name or another host to its destination | Confirm the exact hostnames and values the website provider needs; check for conflicts before editing. |
| MX | Directs incoming email for a domain | Keep the email provider’s required values and priorities unless it instructs you otherwise. |
| TXT, including SPF | Can identify permitted senders or verify services | Preserve existing entries and ask the email provider how any new sending service should be added. |
| DKIM and DMARC records | Support email authentication and handling policies | Copy the exact names, types, and values; confirm requirements with the email provider. |
| Nameservers | Identify where the domain’s DNS zone is hosted | If changing them, prepare and verify the complete new zone before switching. |
Other records can matter too, including records for subdomains and service verification. Do not delete an unfamiliar entry just because it does not look like part of the website. Ask its owner what it does. In particular, a CNAME cannot coexist with other record types at the same hostname, so the provider should check the proposed configuration before you apply it.
There are two common paths. In the first, you keep the current DNS host and edit only the agreed website records. In the second, you change nameservers and move management of the whole DNS zone. The second path requires a fuller copy and review because the new zone must contain the mail and other records you still need.
Hypothetical example: A restaurant uses an outside email provider for hello@maplebistro.example and hires a new company for its website. The existing DNS host can accommodate the new website records, so the owner keeps DNS there. The website provider supplies the precise website edits; the email provider confirms the existing mail records. That choice avoids a full DNS-host move while meeting the stated website requirement. If the new provider instead requires different nameservers, the owner must prepare the complete new zone first.
Ask about connected services as well. A new contact form or online ordering setup may send messages differently from the old website. Identify the sending address and who configures its authentication before relying on it for guest communication.
Arrange support and a rollback plan
Choose a change window when the people with DNS access and the providers’ support teams can respond. Avoid the dinner rush and other periods when the restaurant depends heavily on incoming catering or reservation requests. Tell managers which inboxes and forms are being checked, who owns the change, and where to report a problem.
Before the window, share the current record inventory and proposed changes with the relevant providers. Ask each one to confirm its part in writing. Useful questions include:
- Can the website move be completed without changing nameservers? If not, who will build and verify the new DNS zone?
- Which exact records must change, and which existing records must remain?
- Who is responsible for email authentication for the website’s forms and other domain-based senders?
- How will we check the new zone before a nameserver switch, and who can investigate a failed check?
- What are the support hours, escalation contact, and expected response process during the change?
Write down the rollback steps before making changes. For a website-record edit, that may mean restoring the previous website values. For a nameserver move, it may mean returning to the previous nameservers, provided the old zone is still available and its records remain correct. Confirm the steps with the providers rather than assuming that switching back will instantly fix every problem.
DNS answers can remain cached, so different networks may see changes at different times. If you restore old settings, allow for that delay as well. Keep the old website and DNS arrangements available until the responsible providers agree it is safe to retire them. Do not cancel the email service simply because the website has moved.
Agree on a stop condition: for example, if the agreed mail checks fail and the email provider cannot resolve the issue within the planned window, the change owner contacts the providers and follows the documented rollback decision. Keep a note of what was changed and when; it gives support a useful starting point.
Check sending and receiving after the change
Run checks before the move to establish that the addresses work, then repeat them after the change. Use accounts controlled by the restaurant or its authorized helpers. A simulated check should not trigger a real payment, guest message, or courier dispatch. If a form or ordering flow cannot be safely simulated, ask the provider for a sandbox or a way to check the configuration without submitting a live guest transaction.
- Review the live DNS records. Check the website records and compare MX, authentication, verification, and other retained records with the approved inventory. After a nameserver change, confirm the active zone is the intended one.
- Receive a controlled email. From an authorized external test account, send a message to an important restaurant inbox. Confirm it arrives in the right mailbox and that any expected forwarding works.
- Send a controlled email. Reply from the restaurant inbox to the authorized test account. Confirm receipt, including whether it lands in spam. Ask the email provider to investigate authentication or delivery errors.
- Check other senders safely. With the relevant provider, verify how website forms, reservations, and ordering messages are configured. Use a sandbox or disabled-send mode where available; do not send a practice message to a guest.
- Recheck and record. Repeat the agreed checks as DNS changes are picked up. Note the time, address, result, and any error for the provider. A successful message is useful evidence, not proof that every sender and recipient will work.
If an inbox fails, avoid making unrelated DNS edits while troubleshooting. Contact the email provider with the record inventory, change log, and test result. Use the agreed rollback process if needed. For an active service problem, staff can also use a prearranged alternative contact channel while the provider investigates.
Next, use this checklist to map your current setup and get the proposed DNS changes in writing. If you are considering a Fleksa restaurant website, ask Fleksa about current US availability, domain setup requirements, and who will help coordinate the change with your email provider. Compare that response with the questions in the restaurant website builder comparison before committing.
Frequently asked questions
Do I need to move my email when I move my website?
Not necessarily. Your website and email can use different providers on the same domain. Confirm the new website’s DNS requirements and preserve the records required by your email service.
What happens if I change nameservers?
The domain begins using the DNS zone at the new nameservers as the change is picked up. Prepare the complete new zone first, including mail and other needed records, and keep the old setup available for the agreed rollback period.
Is one successful test email enough?
No. Check both sending and receiving with authorized accounts, verify important aliases or forwarding, and review other services that send using your domain. A few successful checks cannot cover every delivery path.
