What Happens to My Email When My Website Is Rebuilt?
Business email can usually continue unchanged during a website rebuild when its provider and DNS records are identified and preserved.
Part of our guide: How to Replace an Existing Website: A Step-by-Step Guide
Your business email can normally keep working unchanged while your website is rebuilt. Email and the website may use the same domain, but they are often provided by different systems. The launch team must identify and preserve the mail-related DNS records.
Problems occur when name servers or DNS zones are replaced without copying those records. Good preparation makes email continuity a specific launch requirement rather than an assumption.
Understand how the services relate
Your domain is the shared name. DNS directs website visits and email messages to different providers. Website records often include A, AAAA or CNAME entries, while email depends on MX and authentication records.
Replacing the website should not require new mailboxes, addresses or passwords. It usually changes only the web destination.
Ask the provider to explain whether DNS, hosting or the domain registration will change. Each carries a different risk.
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.
Identify the email provider
Find where mailboxes are administered and billed. It may be Microsoft 365, Google Workspace, the current website host or another specialist provider.
Do not judge from the application staff use to read messages. Outlook and Apple Mail can connect to many underlying services.
Record the administrator, renewal, support contact and recovery method. Confirm that the business controls the account.
Export the current DNS configuration
Before any change, record the complete DNS zone. Include MX, SPF, DKIM, DMARC, verification and autodiscovery records as well as website entries.
Some records have unfamiliar names but support important services. Do not delete them because they do not appear connected to the website.
Keep the export securely with the launch plan. It provides a comparison and rollback reference.
Avoid unnecessary name-server changes
If the registrar and DNS provider already work well, the new website can often launch by changing one or two web records. Moving name servers replaces responsibility for the whole zone.
An unnecessary move creates more opportunities to omit email or verification records. Make it only when there is a clear operational benefit.
The guide to what happens to a domain during replacement explains these layers in more detail.
Preserve MX records
MX records identify servers that accept incoming mail. They should remain exactly as required by the email provider unless the email service is intentionally changing.
Priority values matter. Copying only the visible server names may produce a different configuration. Follow the provider’s official instructions.
After launch, confirm that external senders can reach several business addresses and that messages do not bounce.
Preserve authentication records
SPF indicates which systems may send for the domain. DKIM adds a cryptographic signature. DMARC defines policy and reporting based on authentication results.
These records help recipients assess messages and protect the domain from abuse. Damaging them may not stop mail immediately, but it can reduce delivery or create security problems.
Do not create duplicate SPF records. Ask the email specialist to review changes when several sending platforms are involved.
Check website-generated email separately
Contact forms and transactional messages may send through the old website host, an SMTP provider or an API. A mailbox continuing to work does not prove that website forms still deliver.
Document each form’s recipient, sender method, confirmation and failure handling. Configure the new site’s authorised sending service before launch.
Submit realistic tests and verify both the customer response and the message received by the business.
Keep the old site live during development
The current website and email can continue while the replacement is built in a separate environment. Avoid changing public DNS merely to share a preview.
Use fictional addresses and data in staging. Prevent test submissions from reaching customers or polluting production systems.
Read how to build a new site while the old one stays live for the wider process.
Plan an intentional email migration separately
If the business also wants to change email provider, treat that as its own project. Inventory mailboxes, aliases, groups, calendars, contacts, archives and device settings.
Plan data transfer, identity, retention, security and user support. Define a migration window and coexistence where necessary.
Combining both projects may be appropriate, but the scope and rollback must be explicit rather than hidden inside website launch.
Protect mailbox data
A website rebuild does not normally move or delete mailbox contents. Those remain with the mail provider. Confirm backup and retention arrangements rather than relying on assumptions.
Do not export personal mail into development folders. Restrict administrator access and remove supplier accounts after the project.
Follow the organisation’s data-protection and retention requirements throughout any intentional migration.
Test sending and receiving
Use an external address to send to the business, then reply. Test major aliases and shared mailboxes. Check spam folders and provider logs where available.
Send form submissions through every public route. Confirm the expected team receives them and the sender sees an honest confirmation.
Check delivery to more than one external provider when practical. Authentication or reputation issues may appear differently across recipients.
Test devices and applications
If the provider is unchanged, phones and desktop applications should normally need no reconfiguration. Still ask a representative user to send and receive after launch.
Check webmail and any customer-management integrations. Confirm that signatures, shared calendars and forwarding rules still behave as expected.
Do not ask every employee to change settings unless the mail service itself has changed.
Check aliases, groups and forwarding
Email is not limited to named mailboxes. Sales, accounts and support addresses may be aliases, distribution groups or forwarding rules managed in a different part of the provider’s administration.
List these routes before launch and test each from outside the organisation. Confirm who should receive the message and what happens when a team member is unavailable.
Also review catch-all addresses. They can conceal misspellings during testing and attract unwanted mail, so their behaviour should be an intentional business decision.
Coordinate DNS timing
DNS changes can be cached for a period determined partly by their time-to-live value. If the website launch needs a record change, plan that timing rather than expecting every network to update at the same instant.
Lowering a time-to-live in advance may make a later change propagate more quickly, but it should be done by somebody who understands the current zone. Restore an appropriate value once the launch is stable.
Email records usually do not need to change at all. The objective is a precise web update, not a broad replacement of everything associated with the domain.
Keep an incident record
If a message fails, record the sender, recipient, time, bounce response and test method. These details help the mail provider distinguish DNS, authentication, filtering and application problems.
Use an alternative contact channel while investigating. Do not repeatedly change records without allowing the last change to take effect and checking the provider’s evidence.
After resolution, document the cause and final configuration. That record makes the next website, email or domain change safer.
Keep it accessible to the responsible team.
Monitor after launch
Watch for bounce reports, delayed messages, authentication failures and missing form notifications. Keep a known contact route outside the affected domain for escalation.
Compare DNS with the approved record. Correct mistakes deliberately rather than making several speculative changes at once.
Retain the old website configuration until the new forms and mail-related functions are proven.
Common causes of email interruption
Replacing name servers without recreating the zone is the most serious mistake. Others include deleting verification records, changing MX priorities and cancelling a bundled hosting account that also provides mail.
Forms may fail because the old server sent mail locally, the new domain is not authorised or recipients reject forged sender addresses.
Account-access problems can also delay repair. Confirm administrators and recovery before launch day.
Questions to ask the website provider
- Will the domain registration or name servers change?
- Which exact DNS records will be edited?
- Who hosts our email now?
- How will existing records be preserved?
- How will contact forms send messages?
- Who tests incoming, outgoing and form email?
- What is the rollback plan?
The answers should be recorded in the launch checklist.
Frequently asked questions
Will my email address change?
No, not for a website-only rebuild. Existing addresses can remain with the current provider.
Will old emails disappear?
They should remain in the existing mail system. A separate provider migration needs its own backup and transfer plan.
Can website hosting and email hosting be separate?
Yes. This is common and often useful because each service can be managed independently.
Why did email stop after a DNS change?
Mail records may have been removed or changed when the DNS zone moved. Compare the current zone with the provider’s required configuration.
How soon should email be tested?
Test immediately after public changes and continue monitoring during the following days.
Treat email as a protected dependency
The safest website launch changes only what the website needs. Record the whole DNS zone, preserve mail services and test real messages and forms before declaring the migration complete.
Afterworks includes domain, DNS and form checks within website rebuilds so customer communication is protected alongside the new site.
