Using an external mail provider while your website stays on your hosting account is a normal arrangement and a common source of confusion: mail and the website are pointed by different records, and changing one without understanding the other breaks something quietly.
What actually moves
Only mail. Your website keeps working exactly as before, because it follows the A record and you are not touching that.
What changes is the MX records, which say who accepts mail for the domain, plus some TXT records for verification and authentication.
So the sequence is entirely in DNS. Nothing about the hosting account changes except that its own mail service stops being used, and that is a step people forget, covered below.
Do the migration before the switch
The order that avoids losing mail.
Create every mailbox at the new provider first, matching the addresses that exist now: including ones nobody uses. An address that exists today and not tomorrow starts bouncing the moment MX records change, and the sender is told it does not exist.
Then copy the existing mail across, using the provider's migration tool or an IMAP sync. Do the bulk of it before the cutover and run it again afterwards to catch what arrived in between. How to Migrate Email to a New Host walks through that gap in detail.
Lower the MX TTL first
A day or two before, at whoever currently answers DNS for the domain.
The old TTL has to expire before a new value applies, so lowering it on the day accomplishes nothing. At 300 seconds the split period, where some senders deliver to the old server and some to the new, is minutes rather than hours. Understanding DNS Propagation explains the timing.
Replace the MX records, do not add to them
The mistake that produces half your mail going to a server nobody checks.
Delete the existing MX records and add the provider's. Leaving the old ones in place means mail is delivered to whichever has the lowest priority number, and if the old server still accepts mail, some messages land there and are never seen.
Priorities matter: the provider gives you several records with different numbers, and all of them belong in the zone exactly as supplied. Understanding MX Records for Email explains how they are chosen.
Turn off local mail delivery on the hosting account
The step that is missed most often, and it produces a genuinely confusing symptom.
By default a hosting account assumes it handles mail for its own domains. So when your website sends a message to an address at your own domain. A contact form to info@, an order notification; the server delivers it internally instead of sending it out to your new provider.
The result: mail from outside arrives correctly, and mail your own site sends to your own domain disappears into a mailbox on the hosting account that nobody opens.
In cPanel this is the mail routing setting for the domain. Set it to remote so the server respects the MX records. Email Routing and Track Delivery in cPanel deals with where it is.
Update SPF, and keep it to one record
Your SPF record must now authorise the new provider to send for your domain, or your outgoing mail fails authentication.
The provider supplies an include mechanism to add. What you must not do is create a second SPF record. Two SPF records make both invalid, which is a worse position than having none.
Merge it into the existing one instead. And keep the hosting server included if your website sends mail through it, because that is a separate sender from your mailboxes. Understanding SPF, DKIM and DMARC Records sets out the syntax.
Publish DKIM, and check DMARC still fits
The provider gives you DKIM records to publish, usually as CNAMEs or a long TXT record. Publish them before you rely on the mail, not afterwards.
If you have a DMARC record with an enforcing policy, confirm the new arrangement passes before the policy starts rejecting your own mail. A DMARC policy set to reject, with SPF not yet updated, silently discards messages you sent, and the reports are where you would see it.
What your website sends is still separate
Worth stating plainly, because it causes tickets.
Moving mailboxes to an external provider does not change how your website sends mail. A contact form or a shop still hands its messages to whatever it was configured to use.
The clean arrangement is to have the site authenticate to a mailbox at the new provider over SMTP, so everything from your domain comes from one place. How to Fix WordPress Email Not Sending goes into configuring that.
Check both directions, then check the headers
Send a message from outside to an address on the domain, and one from a mailbox at the new provider to an external address.
Then open the received message and read the authentication results in the headers. SPF and DKIM passing is the confirmation that matters: a message that arrived is not the same as a message that authenticated, and the difference shows up weeks later as mail drifting into spam folders.
Keep the old mailboxes for a fortnight
Do not delete them on the day. Senders holding the old MX record keep delivering there while caches expire, and some retry for days.
Leave them, check them once or twice, and remove them when nothing new has arrived for a week: then reclaim the disk, which on a long-standing account is usually more than expected.
The MX record is only half of it: the hosting server may keep delivering locally regardless. How to Split DNS Between Website and Email Providers explains that trap.