How to Configure DNS for a New Website Without Breaking Email
Pointing a domain to a new website often requires changing only a few DNS records. The risk is that a domain’s DNS zone may also contain the records that deliver email, verify services, and authorize outgoing messages. Replacing the entire zone with a small set of web records can make the website work while silently breaking mail.
Before changing DNS, inventory the existing zone and identify which records belong to the website, email provider, and other services.
Understand the Records You Are Changing
| Record | Common purpose | Migration caution |
|---|---|---|
| A | Maps a hostname to an IPv4 address | Confirm the new server address |
| AAAA | Maps a hostname to an IPv6 address | Do not leave an obsolete IPv6 target |
| CNAME | Aliases one hostname to another | Check provider rules and existing records |
| MX | Routes email for a domain | Preserve the mail provider’s targets |
| TXT | Publishes verification and policy data | Keep SPF, DKIM, and DMARC records intact |
| CAA | Restricts certificate authorities | Ensure the new certificate issuer is permitted |
Record the Existing Zone First
Export the DNS zone or take a complete record inventory before making changes. Include the root domain, www, mail-related hostnames, verification records, and any subdomains used by applications. Record TTL values and the current authoritative nameservers.
If DNS is hosted by a registrar, CDN, or separate DNS provider, make changes in the authoritative zone, not in a control panel that is no longer active.
Change Only What Needs to Change
If the new website uses a different server, update the relevant A or AAAA record, or the CNAME target where appropriate. Leave MX and mail-authentication records unchanged unless the email service is also moving. A website migration does not automatically imply an email migration.
Be careful with the root domain. DNS providers differ in how they support aliasing at the zone apex. Use the provider’s documented method rather than assuming a CNAME is valid everywhere.
Plan Around TTL and Caching
TTL tells resolvers how long they may cache a DNS answer. Lowering the TTL before a planned migration can reduce the time some resolvers retain the old answer, but it does not force every cache to update instantly. Make the change early enough to account for existing cached values and monitor both old and new endpoints during the transition.
Check Email Before and After the Change
Save a copy of the mail-related records and compare them after the website cutover. Test both inbound and outbound mail, including messages sent by website forms if those forms are important to the business. A browser test cannot reveal a broken MX record or a missing DKIM selector, so verify mail as its own service.
Keep Email Working
Mail delivery depends primarily on MX records, while SPF, DKIM, and DMARC help receivers evaluate sending authorization and alignment. Do not delete TXT records simply because they look unrelated to the website. Some are used for domain verification, mail authentication, or third-party services.
After changing web records, send and receive test messages using the domain. Inspect message headers for authentication results and confirm that the mailbox provider remains the intended one. If the mail service is moving too, treat that as a separate migration with its own cutover plan.
Validate the New Website
Before switching traffic, confirm the new server responds correctly when requested with the intended hostname. Verify the TLS certificate covers the domain and that the application has the correct canonical URL. Test HTTP and HTTPS, www and non-www variants, redirects, forms, and important application workflows.
Cutover Checklist
- Export or document the complete current DNS zone.
- Confirm the new server’s IPv4 and IPv6 addresses.
- Verify the site and TLS certificate on the destination.
- Change only the records required for web traffic.
- Preserve MX, SPF, DKIM, DMARC, and service-verification records.
- Check authoritative DNS and several public resolvers.
- Test the website and send/receive email.
- Keep the old hosting environment available until the transition is verified.
Final Thoughts
DNS changes should be deliberate and minimal. Keep a record of the existing zone, update only the necessary web records, and test email independently. A successful homepage load is not proof that the domain’s other services survived the change.