How do I point my domain at a new website without taking down my email?
Short answer: Your website and your email run on completely different DNS records, and the single most common way people break email during a website move is changing name servers before copying over their existing MX records (the ones that route email). Copy every existing DNS record, especially MX records, to the new provider first, confirm they're correct, and only then switch your domain's name servers. Done in that order, email never goes down. Done in the wrong order, even briefly, you can lose incoming mail during the gap.
You're ready to launch on a new host but you're worried that flipping the switch on your domain will take your email down with it, and you want the order of operations that actually keeps both working.
I'm Ranjit, and I run Blur Studio: 15+ years building software, 120 apps taken live, and clients who have gone on to raise $10M+. I build AI systems and processes that help businesses do a lot more with a lot less time. I also work differently from most of what else is out there, more on that further down this page. Say hello.
This page may contain affiliate links from which Blur Studio earns commissions.
Your website and your email both depend on the same domain name, but they're controlled by completely separate DNS records, and that's exactly why this goes wrong so often: people assume moving the website is one operation, when really it's two operations sharing a control panel, and skipping the right order on one of them breaks the other.
This comes up most often when moving a site to a new host, and one of the hosts people land on for this is Netlify, which can manage your domain's DNS directly if you choose to point your name servers at it rather than just adding an A record at your current registrar. Netlify is one option among several hosts that offer this, and the DNS mechanics below apply the same way regardless of which host you actually pick.
What an MX record actually does, in plain terms
An MX record is the instruction that tells the internet where to deliver email addressed to your domain. It has nothing to do with where your website lives; a completely separate record (usually an A record or a CNAME) does that job. The problem is that both sets of records usually live in the same place, your domain's DNS settings, and when you move your website to a new host, it's tempting to think of it as "update everything over here" rather than "update only the website records, leave the email records exactly as they are."
The safe order of operations
- Before touching anything, write down your current MX records exactly as they are, from your domain's current DNS settings. If you use Google Workspace, Microsoft 365, or any hosted email provider, this information is usually also available directly from that provider if you need to double check it.
- Set up your new host (for example, connecting your domain in Netlify) and, if you're moving to a new DNS provider rather than just repointing records at your current registrar, copy your existing MX records into the new provider's DNS settings before you switch anything over. This is the step people skip, and it's the one that actually matters.
- Update the records that control where your website lives (the A record or CNAME pointing to your new host), while leaving the MX records you just copied over untouched.
- Verify both things work before considering the move complete: load your website on the new host, and send a test email to your own domain from an outside account to confirm it still arrives.
- Expect some propagation delay. Netlify's own guidance says changes can take up to a day to fully propagate across the internet, and some registrars quote a wider window, up to 72 hours in less common cases, so don't panic if it's not instant, but do keep your old DNS settings untouched and available until you've fully confirmed the new ones are working everywhere.
The one mistake that causes almost every horror story
Switching your domain's name servers entirely to a new DNS provider, wholesale, before copying your existing records (MX included) over to that new provider first. When you switch name servers, you're not just moving your website's records, you're moving the entire DNS record set to a new, empty slate, and if the new slate doesn't already have your MX records on it, email delivery for your domain breaks the moment the switch takes effect, with no warning and no easy undo while the old setting is still cached around the internet. This is specifically why the order matters: copy everything important first, confirm it's correct, then flip the switch, never the other way around.
What I'd actually tell a business owner doing this themselves
If you're moving a live business website with active email, I'd treat this as a genuinely careful, deliberate step rather than something to rush through at the end of a long project, because the downside (email silently failing for hours or days) is disproportionately painful compared to the few extra minutes it takes to do the record copy properly first. Once your new host, whether that's Netlify or anywhere else, is set up and the records are copied, do this during a quiet period for your business if you can, not during your busiest sales week, purely so that if something does go slightly wrong, you have time to notice and fix it before it costs you a real customer interaction.
If you're not confident reading and copying DNS records correctly yourself, this is one of the cheaper, lower-risk things to hand to a developer for a single short session, specifically because the cost of getting it wrong (missed emails, sometimes for days before anyone notices) is high relative to the cost of having someone double check it.
A worked example: a consulting firm that lost two days of client emails
A small consulting firm switched hosts for their website and, following a generic tutorial that didn't mention MX records at all, pointed their domain's name servers directly at the new host's DNS without first checking what else was configured there. The website came up fine within hours. What nobody noticed for two full days was that incoming email had simply stopped, since the new DNS setup had no MX records at all and emails were silently bouncing or disappearing rather than generating an obvious error anyone would see immediately.
The firm only discovered the problem when a client called asking why nobody had responded to an email sent two days earlier, which the firm had never received. Recovering meant adding the correct MX records to the new DNS setup immediately, but the two days of already-bounced email were genuinely gone, not recoverable after the fact, since a bounced message doesn't sit somewhere waiting to be delivered late. The real cost wasn't the technical fix, which took ten minutes once someone finally looked; it was two days of client communication quietly vanishing with no way to know exactly what had been lost until clients started asking why nobody had replied.
A practical note on keeping a record of your DNS settings before you need it
Beyond this one migration, it's worth keeping a simple, current snapshot of your domain's full DNS record set, every MX, A, CNAME and TXT record, somewhere accessible outside the DNS provider itself, a password manager note or a shared document works fine. If you ever need to move hosts again, troubleshoot a sudden email problem, or hand this off to a new developer, having that record already written down saves real time over trying to reconstruct "what was actually configured" under pressure after something's already gone wrong.
How I'd approach this
When I'm moving a client's domain to a new host, I always treat the DNS record audit as its own separate step before touching anything live, specifically listing out every existing record (not just MX, sometimes there are other services like a help desk, a marketing tool or a verification record quietly depending on the same domain) before changing a single setting. That upfront caution is what actually prevents the "email stopped working and nobody noticed for three days" scenario, which is a genuinely common and genuinely avoidable failure mode in website migrations.
Questions people ask
What exactly is an MX record?
It's the DNS record that tells the internet where to deliver email sent to your domain. It's completely separate from the records that control where your website lives, which is why website and email problems during a move are usually two different, unrelated mistakes.
Will switching my website host automatically break my email?
Not if you do it correctly. Email breaks specifically when someone switches name servers to a new DNS provider without first copying over the existing MX records, leaving the new DNS setup with no instructions for where to deliver mail.
How long does a domain change take to fully go live?
Netlify's own guidance says changes can take up to a day to propagate fully across the internet. Some registrars quote wider windows, up to 72 hours in less common cases, so give it time and keep your old settings available until you've fully confirmed the new ones work.
How do I check my current MX records before I start?
Your domain's current DNS settings (through your registrar or current DNS provider) will list them. Your email provider, like Google Workspace or Microsoft 365, can usually also confirm the exact records it expects if you want to double check.
Should I do this move myself or hire someone?
If you're comfortable reading and copying DNS records exactly, you can do it yourself carefully, in the right order. If you're not confident, this is a short, relatively cheap task to hand to a developer for one focused session, given how costly a mistake can be if email goes down unnoticed.
What else besides email might depend on my current DNS records?
Other services sometimes quietly depend on the same domain's DNS, like a help desk tool, a marketing platform, or a domain verification record for a third-party service. List every existing record, not just MX, before making changes, so nothing unrelated breaks silently.