Industry
Part of Shared, dedicated or self-run: comparing email hosting arrangements
Email hosting: how to read an operator's incident record
Email hosting software judged by the operator's bad-day record: status history, post-incident accounts, credit clauses, resellers and the support queue.
When you buy hosting you are not really buying software, because the software is largely settled. You are buying an operator: a company whose staff will be awake, or not, at the moment your mail stops, and whose habits under pressure the sales page does not show.
Features can be demonstrated; operational character has to be inferred from evidence, and there is more evidence available than most buyers collect. The same names appear on every shortlist: Google Workspace and Microsoft 365 at the platform end, Zoho Mail, Fastmail and Proton Mail below them, and a layer of resellers in between. The record behind each name is where they differ.
What to take away
- The thing you are evaluating is how a company behaves on a bad day. Look for the record of previous bad days.
- Find out who actually runs the platform. Plenty of providers resell someone else's, which changes who can help you and how quickly.
- Support is not a feature, it is a queue. Test the queue before you are in it with a real problem.
- Gather your evidence during the trial and write it down. None of it is available to you at renewal.
Read the incident record before the feature list
Every operator in this category, from Google Workspace and Microsoft 365 down, has had outages. The useful question is what happened afterward, and whether the operator has thought about interruption at all.
Ask each one to show the sequence for its own service: identify what must keep working, decide the acceptable interruption, then design around it.
Failure handling checks
- Status page with incident history
- Post-incident write-up published
- Maintenance announced with lead time
- Availability credit terms read
- Status page off same infrastructure
- Is there a status page, and does it have history?A status page that only ever shows green is a marketing page. Google's Workspace Status Dashboard and the service health dashboard inside Microsoft 365 both keep a dated record of past incidents; smaller operators such as Fastmail publish one as well.
- Do they publish anything after an incident?A short honest account of what broke and what changed is one of the strongest signals available. Silence is also a signal.
- How are planned maintenance and breaking changes announced, and how far ahead?Ask to see a recent example rather than the policy.
- What does the availability commitment oblige them to do, and at what uptime figure?Ask for the committed uptime and the service credit clause in writing, not from the pricing page. A credit is not a remedy: read what triggers it, who has to claim it, and within what window.
- How would you find out they were in trouble?If the answer is "we would see the status page", check whether the status page is hosted on the same infrastructure as the service.
A commitment you have to notice and claim yourself is worth less than the number implies. None of this needs a sales call. Most of it is public, and an hour spent reading it tells you more than a week of feature comparison.
Find out who is actually running it
A large share of the market resells someone else's platform. Rackspace is the clearest example: it sells Microsoft 365 and Google Workspace alongside its own hosted mail. Reselling is not disqualifying, but it changes three things you should know about.
Those three are who fixes a platform-level fault, how fast a problem escalates past the company you are paying, and what happens to you if the reseller relationship ends.
The UK National Cyber Security Centre's Cloud Security Principles are designed to help you choose a cloud provider that meets your security needs, which makes them a workable agenda for this conversation. They apply to both cloud platforms and software-as-a-service.
The two documents worth requesting before you sign are a current SOC 2 Type II report and an ISO/IEC 27001 certificate. Providers at this scale usually release both under an NDA.
Ask directly whose infrastructure the mailboxes sit on and where. Ask what the reseller can do without escalating, and what they cannot. Ask what happens to your service if the arrangement changes. A straight answer to all three is reassuring in itself; evasion on any of them tells you the escalation path is longer than you were about to assume.
Where the data lives, and whose law reaches it
The related question is where the data physically lives, which matters if you have any obligation about it and is much easier to establish before signing than after. It also decides which legal regime applies to a request for your mail.
EU and UK customers are covered by the GDPR and UK GDPR, while mail held by a US provider can be reached under the CLOUD Act. The United States enacted it in March 2018 to speed access to electronic information held by U.S.-based global providers. Worth knowing even when no obligation binds you, and worth getting in writing.
Test the support queue, not the sales team
The person selling to you will be responsive. That tells you nothing about who answers when your mail is not arriving.
Support queue test notes
- First reply time and hour
- Answered or restated documentation
- Replies before account-level help
- Channel usable under pressure
- Support available on your tier
During a trial, open a genuine support request. Not "does your product do X", which the sales team will answer. Something operational: a message that was rejected, a delivery that took an hour, a question about a specific log entry. Then record what happened.
Test the support queue
| What to note | Why it matters |
|---|---|
| How long the first reply took, and at what hour | The response time you get is the one on your tier, not the one in the brochure |
| Whether the reply answered the question or restated the documentation | A queue optimized for closing tickets behaves differently from one optimized for solving problems |
| How many replies before someone who could actually look at your account was involved | This is your real escalation path |
| Whether the channel is one you can use under pressure | A chat widget with a bot in front of it is not a channel for an outage |
| Whether they will talk to you at all on the tier you plan to buy | Support commitments frequently apply a tier above the quoted one |
Do this once with each finalist. It costs an afternoon and it is the closest you can get to a rehearsal.
Failure evidence to collect in the trial week
Everything below is obtainable in a trial week and unobtainable later. Write the answers down as you go, because at renewal you will remember your impression and not the evidence, and the impression is what marketing is for.
Trial week evidence tasks
- Run the export yourself
- Import a real mailbox
- Do the administration tasks
- Send something that should fail
- Connect one real system
- Ask a reference customer
- Read the status history.Pick two past incidents and note what was said while they ran.
- Read the post-incident accounts, if any exist, and note what changed afterward.
- Ask to see a recent maintenance notice, and note how far ahead it was sent.
- Get the uptime figure and the credit clause in writing, then note who has to claim and within what window.
- Send something that should fail.An oversized attachment, a message to a nonexistent address, a message that should be filtered. What you are learning is whether the failure tells you anything.
- Ask for a reference customer of roughly your size, and ask them one question: what has gone wrong, and how was it handled.
What incident evidence cannot settle
After the operational assessment, most of the remaining differences reduce to four, and none of them appear on a feature grid. The first is sending reputation, and whether you share it with strangers, which the email hosting overview sets out in detail.
Four honest differences
What to compare
- Sending reputation
- Shared with strangers?
- Administrative reach
- Self-service without ticket
- Cost shape
- Non-human addresses counted
- The exit
- Harder to assess later
Why it matters
- Sending reputation
- Deliverability risk
- Administrative reach
- Speed of control
- Cost shape
- Arithmetic, not opinion
- The exit
- Migration leverage
The others are administrative reach, meaning what you can do yourself without a ticket; the cost shape once your non-human addresses are counted; and the exit, which is the only one of the four that gets harder to assess the longer you wait. Cutting a field on those four is covered in choosing business email software.
If two operators are close on all four, they are close. Choose the one whose incident history reads like a company you would want to deal with at seven on a Monday morning. Record why, so the next review is a check, not a rerun.
Common questions
Do published reviews help?
For finding candidates, yes. For deciding, they are weak: reviews cluster around the moment someone bought and the moment someone was angry, and the middle years, which are the ones you will live in, are barely represented. Recurring operational complaints across many reviews are worth noting; individual verdicts are not.
Is a bigger provider safer?
Bigger usually means better engineering and worse individual attention. Smaller usually means the reverse. Neither is safer in general; they fail differently, and which failure you can tolerate is a question about you.
Is buying through a reseller a red flag?
Reselling is not disqualifying. It changes who fixes a platform-level fault, how fast a problem escalates, and what happens if the reseller relationship ends, so ask about all three before you sign.
What if the status page has no history?
Treat that as information. A status page that only ever shows green is a marketing page, and the post-incident accounts, the maintenance notices and a reference customer become your evidence instead.
