Why we do not run email on the same server as your website
Old hosting packages put mailboxes next to the website. We never do, and we move clients off it. The four reasons and the setup we use instead.
The short answer
Traditional hosting packages bundle mailboxes with the website on one server, under one control panel, on one account. We never set clients up that way, and when we inherit it we move them off it. Four reasons: a web server is a public, code-running target and a mail server holds your private correspondence, so one compromise becomes two; shared web hosts have poor sending reputations, so your mail lands in spam; migrations of either one endanger the other; and the email on such packages is an afterthought with weak filtering and support. The alternative is four services, each doing one thing well.
The four reasons
| Reason | What goes wrong on a shared server | Separated |
|---|---|---|
| Security | A compromised website, through a plugin or upload, gives access to mailboxes, outgoing mail and password resets for every account you own | The website incident stays contained |
| Deliverability | The server’s IP is shared with hundreds of sites, some sending spam; providers score the IP, and your mail pays for it | A provider whose reputation is their business |
| Migrations | Moving the website means touching the control panel and DNS where the mail lives; one wrong record and mail stops for days | Web records and mail records are independent |
| Quality | Basic spam filtering, weak two-factor, poor mobile sync, hosting support that does not do email | Modern filtering, security, sync and specialist support |
What we see when we inherit it
- Mail records pointing at the web server, so any website migration is also an email migration nobody planned.
- Sending authentication missing or wrong, because the hosting panel set it up once in a default way years ago.
- Mailboxes with weak passwords and no two-factor, accessible from the same panel as the website’s files.
- Deliverability complaints that turn out to be the shared IP’s reputation.
- A website compromise that also read email, discovered when a customer received a convincing invoice fraud from a real thread.
The setup we use instead
Website on a modern static platform with a network layer in front. Mailboxes at a dedicated email provider with two-factor and proper filtering. Transactional email from the website, form notifications and confirmations, through a sending service with its own authentication records. DNS managed at a layer that is fast to change, with the mail and web records documented separately. Each piece can be moved or replaced without touching the others.
What this means for you
If your mailboxes live on the same package as your website, plan the separation: a dedicated email provider, a careful DNS change with the records written down first, transactional mail through a sending service. It is an afternoon with a plan. The alternative is discovering the shared blast radius on the day a plugin is compromised or a migration goes wrong, and by then the email is already gone.
Frequently asked questions
It has worked for years. Why change it?
Because the risk is not visible until it is: a website compromise that reads the mailboxes, a migration that silently drops mail for a weekend, or a deliverability decline nobody connects to the shared server. The move is an afternoon with a plan; the incident is a week without one.
Is a dedicated email provider expensive?
A modest amount per mailbox per month for a business plan with proper filtering, two-factor, mobile sync, retention controls and support. Compared with the cost of one lost week of email or one compromised inbox, it is not a close call.
Can the website still send emails, like form notifications?
Yes, through a transactional sending service with its own authentication records on your domain. The website never touches your mailboxes; it sends through a service built for delivery. That separation is also better for deliverability.