Blog

The easiest way to break your business email is to change the wrong DNS setting while launching a new website.

If your domain, website, and email are all handled by the same company, it can feel like “pointing the domain” should be one simple switch. Sometimes it is. But if your email is hosted somewhere else, changing nameservers or deleting DNS records can stop mail from arriving, break outgoing authentication, or cause messages to land in spam.

This guide explains how to point your domain to a new website while keeping email working. We’ll keep it practical and focus on the decisions that matter before you touch DNS.

The short version

If you want your domain to show a new website but you want email to keep working, you usually want to update only the website-related DNS records.

That usually means changing records like:

• A record — points your root domain, such as example.ca, to a server IP address.
• CNAME record — often points www.example.ca to another hostname.

You usually do not want to touch email-related records unless you are also moving email.

Email records commonly include:

• MX records — tell the internet where to deliver your email.
• SPF records — help authorize which servers can send email for your domain.
• DKIM records — cryptographic signatures used to verify outgoing email.
• DMARC records — tells receiving mail servers how to handle failed authentication.

Rule of thumb: If you are only moving the website, change the web records only. Leave MX, SPF, DKIM, and DMARC alone unless you know exactly why they need to change.

First, understand what you are actually moving

Before changing DNS, separate these three services in your mind:

• Domain registration — where you bought or manage the domain name.
• DNS hosting — where the DNS records are controlled.
• Website hosting — where the website files and database live.
• Email hosting — where mailboxes and email delivery are handled.

These may all be with one company, or they may be split across several providers.

For example, a Canadian small business might have:

• The domain registered at a Canadian registrar.
• DNS managed at the registrar.
• The website hosted with Ambrite.
• Email hosted through Microsoft 365, Google Workspace, or another mail provider.

That setup is completely normal. The key is knowing which provider controls which piece before making changes.

Nameservers vs DNS records: the part that trips people up

When someone says “point the domain,” they might mean one of two very different things.

Option 1: Change individual DNS records

This is usually the safer option when you only want to move the website.

You keep DNS hosted where it already is, then update the records responsible for website traffic. For many small business sites, that means updating the A record for the root domain and the CNAME record for www.

Your email records stay exactly where they are. This reduces the chance of accidentally breaking mail.

Option 2: Change nameservers

Changing nameservers moves DNS control from one provider to another. This can be fine, but it is riskier if you do it without copying every existing DNS record first.

If your old DNS zone had MX, SPF, DKIM, DMARC, verification records, subdomains, calendar records, or other service records, they all need to exist at the new DNS host before the nameserver change.

If they are missing, email and other services may stop working.

When not to change nameservers: Do not change nameservers just to launch a new website unless you are prepared to recreate the full DNS zone accurately. Updating the A and CNAME records is often enough.

What DNS records affect your website?

Most websites rely on two common records.

A record

The A record points a hostname to an IPv4 address. In plain English, it tells browsers where to find your website server.

For example, your root domain might be represented as:

• example.ca
• @
• blank host field, depending on the DNS control panel

Different DNS providers label this differently, so check the help text in your control panel if you are unsure.

CNAME record

A CNAME points one hostname to another hostname. It is commonly used for the www version of your domain.

For example, www.example.ca might point to example.ca, or to a hostname provided by your web host.

Do not guess here. Your web host or web developer should tell you exactly what the new A record or CNAME value should be.

What DNS records affect your email?

Email depends on more than just your inbox password. A few DNS records are involved in making sure mail arrives and passes spam checks.

MX records

MX records tell other mail servers where to deliver messages for your domain.

If you delete or overwrite MX records, people may get bouncebacks when emailing you, or messages may disappear into delivery delays.

If your email is staying where it is, leave MX records alone.

SPF, DKIM, and DMARC

SPF, DKIM, and DMARC help prove that your outgoing email is legitimate. They are especially important for businesses sending quotes, invoices, appointment reminders, contact form replies, or WooCommerce order emails.

If these records are missing or incorrect, email may still “send,” but more of it may land in spam or get rejected.

For a deeper explanation, see our guide: How to Set Up SPF, DKIM, and DMARC for Your Business Email.

Before you change anything, take an inventory

Do this before launch day, not five minutes before the new site is supposed to go live.

Create a simple list of your existing DNS records. You can usually export them from your DNS provider, or copy them into a document or spreadsheet.

At minimum, record:

• Record type, such as A, CNAME, MX, TXT, SRV, or CAA.
• Host/name, such as @, www, mail, or a provider-specific value.
• Value/target, such as an IP address or hostname.
• Priority, if shown, especially for MX records.
• TTL value, if shown.

This gives you a rollback reference if something goes sideways.

It also helps your web host or IT provider see what services are connected to the domain. Many domains have old verification records, mail security records, or subdomains that the business owner forgot existed.

Lower the TTL before launch if you can

TTL stands for “time to live.” It tells DNS resolvers how long they should cache a record before checking again.

A lower TTL can make DNS changes appear faster. A higher TTL can cause old records to stick around longer.

If your DNS provider allows it, lower the TTL for your website records ahead of the launch. Many teams do this earlier the same day or the day before a planned launch.

Do not obsess over exact timing. DNS caching still varies across internet providers, networks, and devices. Lowering TTL helps, but it does not make propagation instant everywhere.

The safest process for pointing your domain to a new website

Here is the practical workflow we recommend for most small businesses.

1. Confirm where email is hosted

Before touching DNS, find out where your email lives.

Check whether your team uses Microsoft 365, Google Workspace, cPanel email, Zoho Mail, your internet provider, or another service.

If you are not sure, check the current MX records. They usually give a strong clue about the mail provider.

If you need a refresher on business email setup, read Email Hosting: Setting Up Professional Email.

2. Confirm where DNS is managed

Your domain registrar is not always your DNS host.

Log in to your domain registrar and look at the nameservers. Those nameservers tell you which company is currently authoritative for DNS.

If you are working with a .CA domain, the same general DNS rules apply. The Canadian angle is mostly about registrar management, ownership, and avoiding unnecessary downtime if the domain is transferred. If you are changing registrars too, review How to Transfer a .CA Domain to a New Registrar Without Downtime.

3. Back up the existing DNS zone

Do not skip this. A DNS backup is boring until you need it.

If your DNS provider has an export option, use it. If not, take screenshots and copy the records into a document.

Pay close attention to TXT records. Many email, security, marketing, CRM, and analytics tools rely on TXT records for verification and authentication.

4. Get the correct website DNS values from your new host

Your new web host should provide the values you need.

For Ambrite hosting clients, this may include the server IP address for your site and guidance on the www record. Ambrite cloud web hosting uses LiteSpeed, NVMe SSD storage, and Imunify360, with hosting plans starting at $7.99/month CAD. You can learn more here: Ambrite cloud web hosting.

Do not copy DNS values from another site or an old email thread unless you know they still apply.

5. Update only the website records

If email is staying put, change only the records needed for web traffic.

Common changes include:

• Updating the root A record to the new web server IP.
• Updating the www CNAME to point to the correct host.
• Removing an old website CNAME only if it conflicts with the new setup.

Leave MX records alone. Leave SPF, DKIM, and DMARC alone unless your email provider or IT team specifically tells you to change them.

6. Test the website on both versions

Check both:

• example.ca
• www.example.ca

One version may work while the other still points to the old site. That usually means the root and www records are not aligned properly.

Also test HTTPS. If the new site loads with a browser warning, the SSL certificate may not be installed, issued, or matched correctly for both the root and www versions.

7. Test email immediately

After the DNS change, send test messages both ways:

• Send from your business email to an outside address.
• Send from an outside address back to your business email.
• Reply to the message and confirm the reply arrives.

Use more than one outside mailbox if possible. For example, test with a personal Gmail, Outlook, or ISP-based address if you have access to them.

If your website has contact forms, submit a test form too. Contact forms often fail for different reasons than regular email, especially after a hosting move.

What if your old website and email are on the same hosting account?

This is common with cPanel-style hosting. Your old host may have both the website and email mailboxes under one account.

If you point the domain to a new website host but keep email on the old host, email can still work if the MX records continue pointing to the old mail server.

There are two catches:

• Your old hosting account must remain active if it is still handling email.
• The DNS records must still direct mail to that old provider.

Do not cancel the old hosting account until you know whether it is hosting your email. Many businesses accidentally delete their mailboxes by cancelling “old hosting” too quickly.

Launch tip: Keep the old hosting account active for a short overlap period after the website move, especially if you are not fully sure where email, DNS, or backups are located.

What if you actually want to move email too?

Moving website hosting and email hosting at the same time is possible, but it adds risk.

If your business depends heavily on email, consider separating the moves:

1. Move the website first.
2. Confirm forms, SSL, redirects, and analytics are working.
3. Move email later in a planned window.

This makes troubleshooting much easier. If you change everything at once and something breaks, you have more places to look.

Email migration also involves mailboxes, passwords, devices, signatures, aliases, forwarders, shared inboxes, and sometimes historical mail. DNS is only one part of it.

Common mistakes that break email during a website launch

Changing nameservers without copying email records

This is the big one.

A designer, developer, or business owner changes nameservers to the new host. The website starts working, but the new DNS zone does not include the old MX records.

Result: email stops arriving.

Replacing all TXT records

TXT records may look messy, but they often do important work.

They can contain SPF, DKIM, DMARC, domain verification, email service verification, marketing platform verification, and other settings.

Do not delete TXT records just because you do not recognize them.

Forgetting the www version

Some people update example.ca but forget www.example.ca.

Customers may see the old website, a parked page, or a browser error depending on which version they type or which version Google has indexed.

Assuming DNS changes are instant

DNS changes can appear quickly for some people and slowly for others.

You might see the new site from your office, while a customer across Canada still sees the old one for a while. That does not always mean something is broken.

Cancelling the old host too early

The old host may still contain email, backups, images, DNS records, or files needed for rollback.

Wait until the new site is stable, email has been tested, and backups are confirmed before cancelling anything.

How this applies to WordPress launches

For WordPress sites, DNS is only part of the launch.

You also need to think about:

• SSL certificates and HTTPS redirects.
• Permalinks and page redirects from old URLs.
• Contact form deliverability.
• Cache clearing.
• Image paths and mixed content warnings.
• Search engine indexing settings.
• Backups before and after launch.

If the new site is replacing an existing WordPress site, make sure you have a current backup before DNS is changed. If something unexpected happens, a backup gives you options.

Ambrite’s WordPress maintenance plans start from $49/month CAD and can help with updates, backups, security monitoring, and post-launch care. If you want help keeping the site healthy after launch, see WordPress maintenance and security.

Should you use Cloudflare or another DNS proxy?

Cloudflare and similar DNS/CDN services can be useful, but they add another layer to understand.

They can help with performance, caching, security rules, and DNS management. They can also confuse troubleshooting if records are proxied, cached, or managed separately from your registrar.

If you already use a DNS proxy or CDN, make sure your web host knows. The visible DNS value may not show the actual origin server, and SSL settings need to be configured correctly.

If you do not already use one, you do not need to add it just to launch a basic small business website. Keep the launch simple unless there is a clear reason to add another service.

When to ask for help

DNS is unforgiving because small changes can have big effects.

Ask for help if:

• You do not know where your email is hosted.
• You are being asked to change nameservers but email must stay live.
• Your domain has many TXT, CNAME, or SRV records you do not recognize.
• You use Microsoft 365, Google Workspace, CRM tools, booking systems, or email marketing platforms.
• You are launching during business hours and cannot afford missed email.
• You are transferring a .CA domain and launching a new site at the same time.

A careful DNS review is cheaper than cleaning up missed leads, bounced invoices, and broken contact forms later.

A practical launch checklist

Use this before changing DNS:

• Confirm who controls the domain registration.
• Confirm where DNS is hosted.
• Confirm where email is hosted.
• Back up or document all current DNS records.
• Identify the exact A and CNAME records needed for the new website.
• Do not change MX records unless email is moving.
• Do not delete TXT records unless you know what they do.
• Lower TTL ahead of launch if practical.
• Update only the needed website records.
• Test root domain and www domain.
• Test HTTPS.
• Test inbound and outbound email.
• Test website contact forms.
• Keep the old hosting account active until everything is confirmed.

Need Ambrite to handle it?

If your new website is moving to Ambrite, we can help review your DNS before launch so your website points correctly and your email records are preserved.

This is especially helpful if your domain, email, and website are spread across different providers. We’ll identify what should change, what should stay untouched, and what needs to be tested after launch.

If you are unsure before making a DNS change, contact us here: contact Ambrite.

This article was written with the help of AI and reviewed by the Ambrite team. Pricing, features, and technical details may change — always verify with official sources before making decisions.