Redesign
Can you redesign your website without changing your business email?
Your website can change while your email stays where it is. Here’s what to check before anyone moves your domain settings.
The starting point
Yes, in many cases. Website hosting and email hosting are separate services. A redesign does not, by itself, require a new mailbox or a different email address. The important step is to identify what your domain currently connects to and preserve the records your email provider needs.
One domain, several separate services
A business domain can point visitors to one website provider and send incoming mail to a different email provider. The domain registrar is a third role: it manages the registration. These services sometimes appear on a single invoice, which makes them look inseparable, but they do different jobs.
That distinction matters when replacing an old site. “We need to move the website” should not automatically become “we need to move all your email”. First establish where the site runs, where the mailboxes live and who manages the domain’s DNS settings. If the old supplier bundles these together, ask which services will continue after the website contract ends.
Ask for a short written launch plan
- Domain registration: who owns the account, when does it renew and can you access it?
- DNS: who manages it, and is there a current export of the records?
- Website: which existing pages, downloads, forms and booking tools must continue working?
- Email: which provider receives your mail, and are there other services that send for the domain?
- Launch: who makes each change, what will they test and how will they restore the previous setup if necessary?
Use the names of the actual services rather than a broad instruction to “move everything”. Have the person responsible for the change confirm the plan before editing live settings. Share access through an appropriate account invitation or secure method; do not put passwords into an enquiry form.
Keep the records that support your email
MX records tell other systems where to deliver incoming mail. SPF and DKIM help authorised services identify outgoing mail; DMARC sets the domain’s handling policy for authentication failures. A domain may have more than one legitimate sender, such as a mailbox provider and a separate contact-form delivery service.
A website move should preserve these records unless the email service itself is intentionally changing. There should not be competing SPF records for the same hostname; any necessary change needs to account for all authorised senders. Do not copy a provider’s sample settings blindly over a working configuration. The correct values depend on the services you actually use.
Treat a domain change as a separate decision
A new design can normally keep the existing domain. A new company name or domain adds more work: incoming mail to the old address, staff sign-ins, invoices, customer bookmarks and links may all need attention. Agree how long the old domain and mailbox routing will remain available, rather than assuming the website redirect forwards email too.
If the DNS provider or nameservers are changing, first prepare a complete record set at the destination. Moving only the website record is not enough. Keep an export of the old settings and confirm that the new setup includes the mail records and any other services the business still uses. Avoid making unrelated changes during the same launch window.
Check the customer journey as well as the homepage
Make a list of useful existing URLs before launch. Keep those addresses where practical. When a page moves, map it to the relevant replacement instead of sending every old link to the home page. Test important service pages, downloads and the enquiry journey on the public address.
Email deserves its own checks: send a message from an external account into the business mailbox, reply from the mailbox and test the website form. Those tests cover different routes. A successful form notification does not prove that ordinary incoming mail works. Also check any booking or CRM notifications the business relies on.
Allow for cached DNS answers while changes take effect. Agree a launch window, check results and retain access to the previous configuration until the migration is settled. No supplier should promise that every visitor sees a DNS change immediately.
Know what stays with the business
After launch, you should know who owns the domain, where the mailboxes live and who pays each renewal. Keep a short record of the services and the right contact for changes. A website care agreement should say whether mailbox administration is included, rather than leaving it assumed.
If replacing your current site feels risky because domain and email access are unclear, start by finding those accounts. A redesign can be scoped around preserving the services that already work. Use the project brief to list them, or discuss a website replacement with Charlie.
Further reading
- Cloudflare: email routing and authentication records
- Google Search Central: moving pages and preserving useful URLs
These references explain the technical background. Your launch plan should use the current instructions from your actual website and email providers.
