Most small businesses start with one hosting package: website and email in the same cPanel account. Mailboxes live next to WordPress. MX records point at the same provider. Life is simple until you migrate the website, outgrow shared sending limits, or need proper archiving for a compliance audit.
Separating email from web hosting is not mandatory on day one. It is a decision worth making before a rushed migration turns into "the site moved but nobody got invoices for a week."
When bundled email still makes sense
Keeping mail on your web host is fine when:
- You have a handful of addresses and low outbound volume
- Everyone reads mail on phones and webmail, not desktop sync
- You are not running marketing blasts from the same server as your contact form
- Your host includes decent spam filtering and you are not fighting deliverability daily
Canadian businesses on managed cPanel plans often stay here for years without drama. Simplicity has value.
Signals it is time to split
Website migrations. Moving WordPress to a new host should not require moving twenty mailboxes the same weekend unless you want that stress. Leave MX pointing at Google, Microsoft, or your current mail server while DNS for the website changes. We covered timing in moving email when you change web hosts.
Deliverability problems. If legitimate mail lands in spam because you share an IP with noisy neighbors, dedicated transactional email (SMTP relay) or a proper mailbox provider often fixes it faster than chasing cPanel tweaks.
Team growth. Shared calendars, Teams/Meet integration, shared drives, and mobile device management push you toward Microsoft 365 or Google Workspace. Those are email products, not hosting addons.
Compliance and retention. Legal hold, audit logs, and multi-year retention are weak on basic bundled mail. Regulated industries and professional firms often need a provider built for that.
High outbound volume. Newsletters, WooCommerce at scale, and CRM sync can hit hourly send caps on shared hosting. Split marketing sends (Mailchimp, etc.) from transactional mail (SMTP provider) from human inboxes.
Common split patterns
Website on Swift Host, mail on Microsoft 365 / Google Workspace. MX points at Microsoft or Google. A records for the site point at us. Clean separation, familiar admin tools for staff.
Website moves, mail stays on old host temporarily. Valid during a phased migration. Pay for the old account until mail is exported and DNS cut over. Set a calendar deadline so "temporary" does not mean eighteen months.
Website here, transactional SMTP elsewhere. Contact forms and order emails via SendGrid, Mailgun, or Amazon SES. Human inboxes still on Workspace. Reduces "forms work but mail is silent" when shared PHP mail() chokes.
DNS you cannot get wrong
Split hosting means split DNS responsibility. Document who owns the registrar and DNS panel.
- MX records follow the mail provider, not wherever the website lives
- SPF includes every service that sends as your domain
- DKIM keys come from Google/Microsoft and your SMTP relay
- DMARC starts at p=none for monitoring, tighten when confident
Changing web hosts without touching MX is normal. Accidentally deleting MX while editing A records is also normal, in the bad way.
Migration mechanics (mailboxes, not just DNS)
Export mail with IMAP migration tools or provider wizards. Move calendars and contacts if people use them. Update phones with new autodiscover or app passwords. Tell staff the cutover window.
Test send and receive from outside your office Wi-Fi before you announce success. Internal tests lie because cached DNS and old SMTP settings mask problems.
Cost reality
Workspace or M365 runs per user per month. Cheap compared to a week of missed client email. Staying on bundled mail is cheaper on paper until a migration double-bills you because you forgot to cancel the old host that still held MX.
Count total cost: web plan + mailbox licenses + SMTP relay if needed. Still often cleaner than one overloaded shared account doing everything poorly.
Canadian privacy angle
PIPEDA cares about personal information in email, not which server runs WordPress. Know where mail is stored (Canadian data residency options exist with some providers). Client contracts sometimes specify where communications live. Document it for RFPs.
Bottom line
Separate email from web hosting when migrations, team tools, deliverability, or compliance outgrow a single cPanel account. Stay bundled while it is simple and working. Either way, treat MX as its own system with its own cutover plan.
Planning a site move and want mail left alone? Talk with Swift Host. We migrate websites every week without touching inboxes unless you ask us to.
