Technology

Email Hosting Choices Explained: Self‑Hosted, Shared Hosting or Google Workspace / Microsoft 365?

When businesses plan a new website, migrate a domain or modernise their IT stack, email hosting is usually decided with a quick “we’ll sort it later.” Then a few months pass, spam starts slipping through, invoices land in spam folders, and someone realises that email is actually the system that quietly runs everything. Choosing where and how your email lives is not just a technical detail; it affects deliverability, compliance, costs, support workload and even how professional your brand looks to customers.

In this article, we will walk through the three main approaches we see every day at dchost.com: running your own self‑hosted mail server on a VPS or dedicated server, using email that comes bundled with shared hosting, and moving to SaaS suites like Google Workspace or Microsoft 365. We will look at what each option really feels like in practice, which trade‑offs you are making, and how to think about cost, security, uptime and administration. By the end, you should have a clear, realistic picture of which path fits your team, your skills and your risk tolerance.

What “Email Hosting” Actually Means

Before comparing options, it helps to clarify what is really included when we say “email hosting.” Many people assume it is just a mailbox sitting somewhere on a server, but in reality email involves several moving pieces:

  • DNS and MX records: Tell the world which server accepts mail for your domain.
  • MTA (Mail Transfer Agent): Software like Postfix or Exim that sends and receives mail between servers.
  • Mailbox storage and access protocols: IMAP/POP3 for reading email in clients and SMTP for sending.
  • Authentication and security: SPF, DKIM, DMARC, rDNS, TLS, and often MTA‑STS or DANE.
  • Spam and virus filtering: Anti‑spam engines, reputation systems and blocklists.
  • Webmail and collaboration: Browser access, calendars, contacts, shared mailboxes, etc.

Where these components run, who configures them and who is responsible for keeping them secure defines the three main models we will compare:

  • Self‑hosted email on your own VPS, dedicated server or colocated hardware.
  • Shared hosting email bundled with your web hosting account.
  • Hosted suites such as Google Workspace and Microsoft 365.

Option 1: Self‑Hosted Email on VPS, Dedicated or Colocation

Self‑hosting means you run your own mail server software on infrastructure you control. That may be a VPS, a dedicated server or a colocated machine in our data centres. You own the full stack: MTA, IMAP, spam filtering, TLS certificates, DNS records and monitoring. We see two main profiles that gravitate to this option:

  • Technical teams that want fine‑grained control (agencies, SaaS providers, hosting resellers).
  • Businesses with strict compliance, localisation or integration requirements.

What Running Your Own Mail Server Really Involves

If you have never hosted your own mail server, it is easy to underestimate the operational side. In our guide about building a mail server with Postfix, Dovecot and rspamd on a VPS we walk through a full real‑world setup. In summary, you will need to:

  • Secure the server itself (firewall, SSH hardening, system updates).
  • Install and configure the mail stack (SMTP, IMAP/POP3, spam filtering, antivirus if needed).
  • Set DNS: MX, A/AAAA, PTR (reverse DNS), SPF, DKIM, DMARC and often CAA records.
  • Obtain and renew TLS certificates for encrypted connections (SMTP, IMAP, webmail).
  • Monitor queues, logs, disk usage and reputation (blocklists, feedback loops).
  • Plan and test backups and restores for mailboxes and configuration.

For many teams, that is perfectly manageable, especially if you are already running other services on a VPS or dedicated server. For others, it is simply more responsibility than they want to absorb.

Advantages of Self‑Hosted Email

  • Full control over data and configuration: You decide where data resides, how long it is retained, which logs are kept and how spam filtering behaves.
  • Flexible integration: Easier to tie into custom apps, internal tools or specialised workflows (e.g., piping emails into ticketing systems or CRMs).
  • Cost efficiency at scale: For dozens or hundreds of mailboxes, per‑user SaaS pricing can become expensive; your own server may be more economical.
  • Advanced security options: You can implement modern features such as MTA‑STS, TLS‑RPT and DANE/TLSA. We explain these in detail in our article about SMTP security with MTA‑STS, TLS‑RPT and DANE/TLSA.
  • Data localisation and compliance: If you must keep data within a specific jurisdiction (for example due to GDPR or local regulations), self‑hosting on a VPS or server in a particular region gives you clear control.

Challenges and Risks of Self‑Hosting

  • Deliverability and reputation are your job: You must keep a clean IP reputation, manage blocklist incidents and configure SPF, DKIM and DMARC correctly. Our guide on SPF, DKIM, DMARC and rDNS is a must‑read if you go this route.
  • Maintenance never stops: Security updates, TLS renewal, disk monitoring and log checks are continuous tasks.
  • Spam and abuse handling: Compromised passwords, forwarding loops and outdated web applications can all cause spam outbreaks that damage your IP reputation.
  • Complexity of modern standards: IPv6, MTA‑STS, ARC, SRS and other newer standards are powerful but add complexity. Our article on email deliverability over IPv6 shows how deep this can go.
  • 24/7 responsibility: If something breaks, there is no external provider to escalate to; your team is the provider.

Who Self‑Hosted Email Is (and Is Not) For

In our experience, self‑hosting works well when:

  • You already operate servers for web apps or databases and have Linux expertise.
  • You need advanced control (custom routing, in‑house compliance, specific retention rules).
  • You have enough mailboxes that per‑user SaaS cost becomes significant.

It tends to be a poor fit when:

  • The business has no technical admin who can respond quickly to issues.
  • You only need a handful of mailboxes and do not want extra operational burden.
  • Your priority is a familiar collaboration suite with calendars and document sharing, not server‑side configuration.

From the dchost.com side, self‑hosting usually sits on top of our VPS, dedicated or colocation offerings. We can help with the infrastructure layer, while you (or your managed service partner) own the mail stack itself.

Option 2: Email Included with Shared Hosting

This is the most common starting point for small businesses. You buy a shared hosting package for your website, and it includes email accounts under your domain: info@, sales@, support@ and so on. Mail is handled by the same hosting platform, often with cPanel or a similar control panel.

How Shared Hosting Email Works Day‑to‑Day

On a typical shared hosting plan, you can:

  • Create mailboxes and aliases via the control panel.
  • Access email using webmail, IMAP/POP3 and SMTP (with TLS).
  • Use built‑in spam filters and basic forwarding rules.
  • Rely on the provider for server maintenance, TLS renewal and basic IP reputation work.

The main appeal is simplicity: one bill, one panel, one support contact. For many brochure‑style websites, small local businesses or side projects, this is more than enough.

Strengths of Shared Hosting Email

  • Low cost, especially for a few mailboxes: You are already paying for shared hosting; email often comes bundled or at minimal extra cost.
  • No server administration required: You do not have to install a mail stack, manage firewalls or handle system‑level updates.
  • Quick setup: Create mailboxes in minutes through the control panel and start using them in clients like Outlook or Apple Mail.
  • Unified management: Website, email and DNS can be managed from the same account, which simplifies many small business workflows.

Limitations You Should Be Aware Of

  • Resource sharing: CPU, RAM and disk I/O are shared with other customers. Heavy email use (large attachments, many accounts) can push you against limits. Our article about cPanel resource limits and the “Resource Limit Reached” error explains how those caps work.
  • Storage constraints: Mailboxes on shared plans often have storage limits; large archives with many attachments can fill up quickly.
  • Less customisation: You generally cannot install custom spam filters or deeply customise SMTP routing.
  • Basic collaboration features: You usually have mail and sometimes calendars/contacts, but not the full collaboration environment of a suite like Google Workspace or Microsoft 365.
  • Shared IP reputation: Outbound mail typically goes out through shared IPs. If another customer abuses the service, it can momentarily impact reputation, though responsible providers work hard to mitigate this.

When Shared Hosting Email Fits Well

In our experience, shared hosting email is ideal when:

  • You need a small number of professional addresses (e.g. 3–10 mailboxes).
  • Your website traffic and email volumes are moderate.
  • You prefer minimal management overhead and a single provider.
  • You do not need advanced compliance features or deep integration with internal systems.

At dchost.com, a common pattern is: start with shared hosting email while the business is small, and later graduate to a VPS‑backed mail server or a hosted suite once needs become more sophisticated.

Option 3: Google Workspace / Microsoft 365

The third major option is to move email into a hosted productivity suite such as Google Workspace or Microsoft 365. In this model, you do not manage any mail server software. Instead, you configure your domain’s DNS MX records to point to the provider, and they handle everything from mail storage to spam filtering and webmail.

What You Get with a Hosted Suite

Beyond email, these suites typically include:

  • Calendars, contacts and shared resources (rooms, equipment).
  • Office applications (online and sometimes desktop licences).
  • Cloud storage and document collaboration.
  • Mobile device management and security policies on higher‑tier plans.

Administrators manage users, groups and security settings from a web console, while the provider maintains infrastructure, scales storage and fights spam at global scale.

Advantages of Google Workspace / Microsoft 365

  • Excellent deliverability out of the box: Their sender IP ranges have strong reputations and sophisticated anti‑spam systems. You still need correct DNS (SPF, DKIM, DMARC), but the heavy lifting of reputation management is offloaded.
  • Rich collaboration tools: Shared calendars, video meetings, live document editing and integrated chat can transform how teams work day‑to‑day.
  • No server operations: No patching, no TLS renewal, no firewall tuning. You handle configuration in the admin panel, not at the OS level.
  • Predictable per‑user pricing: Costs scale linearly with user counts; easy for finance teams to forecast.

Trade‑Offs and Things to Consider

  • Per‑user cost: For small teams, the price can be very reasonable; for large organisations with simple email needs, it may be more expensive than shared or self‑hosted.
  • Data location and compliance: You are bound by the provider’s data centre locations and legal frameworks. For some industries or jurisdictions, that may need careful review.
  • DNS complexity when migrating: Moving MX, SPF, DKIM and related records must be done carefully to avoid downtime. Our guide on why domain transfers break email and how to avoid it is relevant here, even if you are not changing registrars.
  • Less infrastructure‑level flexibility: You cannot add your own spam engine, custom MTAs or unusual routing under the hood; you configure what the suite allows.
  • Vendor lock‑in considerations: Over time, you might build workflows around proprietary features. Migrating away later requires planning.

When a Hosted Suite Makes Sense

We often see Google Workspace or Microsoft 365 selected when:

  • The team values integrated calendars, meetings and document collaboration as much as email itself.
  • There is limited appetite for server administration or complex mail configuration.
  • Budget is available for per‑user subscriptions, and ease‑of‑use is a top priority.
  • Remote and hybrid work are the norm, and browser‑based tools fit the culture.

From the hosting side, you would typically keep your website on dchost.com (shared, VPS or dedicated) and delegate email to the suite via MX and related DNS records.

Deliverability, Spam and DNS: Non‑Negotiables Whatever You Choose

Regardless of which hosting model you pick, certain fundamentals must be in place to keep emails landing in inboxes instead of spam folders:

  • SPF (Sender Policy Framework): Declares which servers are allowed to send on behalf of your domain.
  • DKIM (DomainKeys Identified Mail): Cryptographically signs messages so receivers can verify they were not modified.
  • DMARC: Tells receiving servers how to treat messages that fail SPF or DKIM, and gives you reporting.
  • Reverse DNS (PTR): Maps your sending IP back to a hostname associated with your mail server.
  • Consistent HELO/EHLO, TLS and hostname setup: Part of your technical reputation.

We go in depth on these mechanisms in our article “Inbox or Spam? A Friendly, Step‑by‑Step Guide to SPF, DKIM, DMARC and rDNS”. Even when you use Google Workspace or Microsoft 365, you still must publish the correct DNS records; they just provide easier wizards and documentation to do so.

Forwarding is another subtle area. Naive forwarding can break SPF/DMARC and hurt deliverability. If you rely heavily on forwarding (aliases that pass mail to external providers), read our breakdown of how SPF/DMARC break during forwarding and how SRS/ARC fix it before finalising your design.

Cost, Responsibility and Flexibility: A Side‑by‑Side Comparison

To make the decision more concrete, it helps to compare the three options across a few key dimensions.

1. Cost Structure

  • Shared hosting email: Typically included or low‑cost add‑on. Best for small mailbox counts and simple needs.
  • Self‑hosted on VPS/dedicated: You pay for server resources (and maybe a control panel licence) rather than per user. Costs scale with hardware needs, not user count.
  • Google Workspace / Microsoft 365: Per‑user, per‑month model. Costs scale linearly with number of accounts and features chosen.

2. Operational Responsibility

  • Shared hosting: Provider handles infrastructure and mail stack; you manage mailboxes, passwords and basic DNS.
  • Self‑hosted: You are responsible for the entire mail system plus the server OS, unless you explicitly work with a managed services partner.
  • Hosted suite: Provider runs mail infrastructure; you manage users, groups, security policies and DNS records as instructed.

3. Flexibility and Control

  • Highest control: Self‑hosted.
  • Medium control: Shared hosting (within the limits of the platform).
  • Lowest infrastructure control, high app‑level features: Hosted suites.

4. Collaboration Features

  • Shared hosting / self‑hosted: Primarily email; groupware features depend on the software you choose and configure.
  • Google Workspace / Microsoft 365: Full collaboration suites by design (documents, chat, meetings, calendars).

5. Compliance, Localisation and Data Residency

  • Self‑hosted: Maximum flexibility; you choose the region and can design for local regulations. This aligns well with the topics we cover in our guide to KVKK and GDPR‑compliant hosting.
  • Shared hosting: Similar benefits if your hosting provider offers data centres in relevant jurisdictions.
  • Hosted suites: You work within the provider’s regional options and contractual terms; often acceptable, but must be reviewed.

How to Choose: A Practical Decision Framework

Instead of trying to find the “best” solution in the abstract, frame the decision around your constraints:

Question 1: How Many Mailboxes and What Type of Use?

  • 1–10 basic mailboxes: Shared hosting email is often more than sufficient and cost‑effective.
  • Dozens of accounts with light collaboration: Self‑hosted (on a VPS or dedicated server) or shared hosting can be economical if you have technical skills.
  • Dozens to hundreds with heavy collaboration: Google Workspace or Microsoft 365 usually win due to shared calendars, meetings and docs.

Question 2: Who Will Operate the System?

  • No internal IT team: Prefer shared hosting email or a hosted suite. Avoid self‑hosting unless you work with a managed service provider.
  • Small but technical team: Self‑hosting on a VPS or dedicated server at dchost.com can be attractive, especially if you already run other services.
  • Large IT team or hosting agency: Self‑hosting gives you maximum control and the ability to standardise a stack across many customers.

Question 3: How Critical Is Uptime and Vendor Independence?

  • Mission‑critical email with strict SLAs: Hosted suites and carefully architected self‑hosted setups (possibly with multiple servers and redundant DNS) both work, but you must design resilience explicitly. Our guides on DNS records explained and TTL strategies for zero‑downtime migrations are very relevant.
  • Desire to avoid big‑vendor lock‑in: Self‑hosting or shared hosting email keep you closer to open standards and make migration easier.

Question 4: What Is Your Compliance and Localisation Story?

  • Strict data residency requirements: A VPS, dedicated server or colocation in a specific region is often the cleanest answer.
  • Standard SME requirements: Shared hosting or hosted suites with clear data processing agreements may be fully adequate.

Migration Tips: Moving Without Breaking Email

Whatever choice you make, at some point you will likely migrate: from shared to self‑hosted, from shared to Google/Microsoft, or the reverse. A few principles will help you avoid downtime and data loss:

  • Plan DNS changes carefully: Lower MX and related record TTLs in advance, then update MX, SPF, DKIM and other records in a controlled window. Our TTL playbook for zero‑downtime migrations is written exactly for this scenario.
  • Run both systems in parallel for a while: Keep the old and new systems active while DNS propagates. Ensure mail is being delivered to the new host before decommissioning the old one.
  • Migrate mailboxes with IMAP sync tools: For larger moves, use IMAP‑sync utilities to copy mail between servers rather than asking users to drag‑and‑drop everything manually.
  • Communicate client configuration changes: Document new IMAP/SMTP server names, ports and TLS requirements for users.
  • Test forwarding, aliases and mailing lists: These are often where subtle issues (like SPF/DMARC breaks) appear first.

If your domain is also moving between registrars or hosting providers at the same time, read our guide on avoiding email downtime during domain transfers before making changes.

Putting It All Together: A Calm Path to the Right Email Hosting

Choosing between self‑hosted email, shared hosting and Google Workspace / Microsoft 365 is less about “which is the best technology” and more about “which matches your team’s skills, risk tolerance and budget.” If your main goal is simple, low‑effort email for a small business website, shared hosting email with dchost.com is often the cleanest starting point. Everything lives in one place, and you are not forced into per‑user subscriptions before you are ready.

If you have a technical team and want deep control over deliverability, compliance and integration, running your own mail server on a VPS, dedicated server or colocated hardware gives you a lot of power. It does mean owning security, monitoring and reputation management, but we have seen many agencies and SaaS teams thrive with this approach, especially when they follow the patterns we share in our email‑focused guides.

Finally, when collaboration and user experience are the top priorities—and when your team already lives in browser‑based tools—a hosted suite like Google Workspace or Microsoft 365 can be worth every cent. In those cases, dchost.com continues to host your websites, databases and other workloads, while email and collaboration shift to the SaaS layer via DNS.

If you are unsure which path fits you today, or how to migrate without breaking anything, our team at dchost.com is happy to walk through your specific scenario: how many users you have, what tools you rely on, and how critical email is to your business. From there, we can help you design a calm, step‑by‑step plan—whether that means starting with shared hosting email, moving to a VPS‑backed mail server later, or integrating your hosting environment cleanly with a third‑party suite.

Frequently Asked Questions

It depends on your team and priorities. Running your own mail server on a VPS or dedicated server gives you maximum control over data location, retention, spam filtering and integrations. It can also be cost‑effective if you manage many mailboxes and have the skills to maintain the stack. However, you are fully responsible for security, monitoring, IP reputation and modern standards like SPF, DKIM and DMARC. Suites such as Google Workspace or Microsoft 365 remove most of that operational burden and provide strong collaboration tools, but you pay per user and accept more vendor lock‑in. If you lack in‑house technical expertise, a hosted suite or shared hosting email is usually safer.

A move from shared hosting email to a VPS or dedicated server makes sense when your email usage or requirements outgrow what shared platforms comfortably provide. Common triggers include: many mailboxes eating up storage, the need for custom spam filtering or routing, stricter compliance or localisation requirements, or performance issues caused by high volumes of large attachments. Another sign is when you want to centralise multiple domains and projects under a single mail infrastructure. If you already operate a VPS for applications, consolidating email there can also reduce complexity. Just be prepared to take on server administration, backups and deliverability tuning.

To avoid downtime, treat DNS carefully and plan a transition window. First, lower the TTL values for your MX and related DNS records a day or two before the change so updates propagate quickly. Next, set up the new email host (whether it is another hosting provider or Google Workspace / Microsoft 365) and test at least one mailbox. Then update MX, SPF, DKIM and any other required records, keeping the old system running in parallel for a while. Use IMAP‑based migration tools to copy existing mailboxes to the new service. Finally, update mail client settings and test aliases, forwarding and mailing lists. Our detailed guide on preventing email disruption during domain transfers also applies to these moves.

Yes. Even with Google Workspace or Microsoft 365, SPF, DKIM and DMARC remain essential. Those suites publish recommended DNS records, but it is your responsibility to add them correctly at your DNS provider. SPF tells the world that your suite’s mail servers are allowed to send on behalf of your domain. DKIM signs messages so recipients can verify they were not altered. DMARC lets you define how receivers should treat emails that fail SPF or DKIM and provides reporting on suspicious activity. Without these, you risk poorer deliverability and make it easier for attackers to spoof your domain.

Not necessarily. A well‑managed shared hosting platform with good monitoring and anti‑abuse controls can provide stable, reliable email for many small and medium‑sized businesses. The main differences are scale and control. On shared hosting, you share IP reputation and resources with other customers, and you have limited ability to customise the mail stack. A dedicated email service or self‑hosted solution offers more isolation and tuning options, which matter more as your volumes, security requirements or integration needs grow. For basic professional email—especially under 10 accounts—shared hosting is often perfectly adequate and cost‑effective.