Maintenance
Part of Business email: a complete practical guide for 2027
Best business email software 2027: practical details
A practical 2027 guide to best business email software 2027: practical details with current definitions, decisions, checks, and review steps.
There is no honest answer to "which business email service is best", and the pages that give you one are usually ranking by affiliate commission rather than by fit. What there is, is a method for finding out which one is best for you: in about a week, using free trials, without taking anyone's word for anything.
That method is this page. It replaces a ranking with a process, because a ranking gets stale and a process does not.
What to take away
- The purpose is to stop a demo from setting your criteria.
- Trials are usually spent clicking around an empty account, which tells you nothing.
Why a list cannot answer this
The category is mature. Delivery works. Spam filtering works. The web client, mobile apps, calendar, and contacts all exist everywhere and are broadly comparable. If your requirement is "reliable mail on our own domain", almost every serious offer meets it, and choosing between them on features is choosing between rounding errors.
What differs is not the mail. It is:
- Whether the administrative controls match how your organization actually works.
- Whether the price shape suits your seat count and how many non-human addresses you need.
- Whether the things you already use connect to it.
- Whether you can get your data back out.
None of those are properties of the product alone. They are properties of the product paired with you. A ranking cannot know your side of that pair, which is why every ranking is written in generalities and every generality is useless at decision time.
Cut the field fast with disqualifiers
Do not start by comparing. Start by eliminating. Four questions will usually reduce a long list to two or three candidates in an afternoon.
1. Does it meet your constraints on where data is stored and how long it is kept? If you have an obligation about data location, retention period, or legal hold, ask about it first. It is the requirement least likely to be negotiable and most likely to be absent from the tier you were planning to buy.
2. Does the tier you can afford include the administration you need? Work out whether you need single sign-on, automated provisioning, audit logging with meaningful retention, and enforced multi-factor authentication. Then check which tier contains them. Very often the answer is "not the one in the comparison table", and that single fact reorders the whole field.
3. Do your non-human addresses cost money? Count the addresses you need that no individual reads: inquiries, invoices, support, system notifications, per-department addresses. Then find out whether aliases and shared mailboxes consume paid seats. This can change the real price by more than any discount.
4. Does it connect to what you already run? List the systems that currently send mail as your domain or read from a mailbox: your CRM, your accounting software, your website's contact form, your ticketing system, anything with a scheduled report. Every one of those is a connection you will have to re-establish. If a candidate makes one of them hard, that is a strong signal.
Anything that fails one of those four is out, regardless of how good it looks. Comparing survivors is a much better use of your week. This order, need first and product second, is the whole of the advice in the public sector guidance on choosing technology, and starting from a shortlist quietly reverses it.
Write the requirement sheet before the first trial
The purpose is to stop a demo from setting your criteria. Write it before you look at anything, and change it only for a reason you can state.
Split every requirement into one of three buckets:
- Veto. If it is missing, the candidate is out. Keep this list short: three or four items. If everything is a veto, you have no criteria, you have a wish list.
- Weighted. Things that matter in proportion. Give each a weight before you know which candidate does well on it, because afterwards you will unconsciously weight toward the one you already like.
- Ignore. Things that sound good and will not change your working life. Write these down too. Naming them is what stops them creeping back in during the demo.
Be specific about the veto items in particular. "Good security" is not a veto criterion. "Enforced multi-factor authentication for every account, on the tier we can afford" is.
The trial protocol
Trials are usually spent clicking around an empty account, which tells you nothing. Use the time to answer questions you cannot answer any other way.
Load real data. Import a genuine mailbox with years of mail, folders, and attachments. An empty inbox is fast and searchable in every product ever made. A large real one is where search quality, threading, and performance become visible.
Put more than one person in it. Email is a group activity. Test the things that involve other people: a shared mailbox worked by two colleagues, calendar availability across the team, a delegated mailbox, a distribution address, a message sent from a shared address rather than a personal one.
Run the administration, not just the mail. Create a user. Suspend one. Reset someone's second factor as if they had lost their phone. Grant one person access to another's mailbox and then remove it. Read the audit log for what you just did and see whether it tells you anything useful.
Test the boring failure paths. Send yourself a large attachment. Send a message that should be caught by the spam filter and see where it lands and how you release it. Have someone outside the organization reply to a shared address. Try to find a message you deleted.
Connect one real integration. Not the most important one, the second most important one. See what the connection actually requires: which account it authenticates as, what permissions it demands, and what happens to it when that account is disabled.
Use it on the worst device someone has. The mobile client on an old phone, or the web client on a slow connection, is the experience some of your colleagues will have every day.
Check the exit during the trial, not at renewal
This is the step everyone skips and the one that costs the most.
While you still have a trial account, run a real export. Not a request to support, the export an administrator can run themselves. Then check:
- What formats come out. Mail, calendar, and contacts each have widely readable standard formats. Getting one of the three in a proprietary format is a warning.
- Whether you can open it without the vendor. Take the export file to a machine that has never touched the product and see whether the data is readable.
- What is missing. Folder structure, read and unread state, flags and labels, delegation rules, filters and forwarding rules, and calendar attendee responses are all things that commonly do not survive an export.
- How long it takes. At trial volume it will be quick. Ask what it looks like at your real volume, and whether there is a size at which it has to be done in batches.
- What happens after you cancel. How long is data retained, how long do you have to retrieve it, and what is deleted immediately.
A useful benchmark for what counts as an adequate export is the standard applied when a person asks for their own data: the regulator's description of data portability is about receiving information in a form that can actually be used, rather than merely delivered.
A vendor that answers these clearly is more trustworthy than one with a better feature list. Difficulty leaving is the single largest hidden cost in this category, and it is entirely knowable in advance.
Score it without lying to yourself
At the end you will have opinions. Convert them into a decision you can defend.
| Step | What it prevents |
|---|---|
| Score against the weights you set beforehand | Retrofitting criteria to justify the candidate you enjoyed using |
| Apply vetoes absolutely, never as a heavy penalty | A high total score burying a disqualifying failure |
| Have the people who ran the trial score separately, then compare | One confident voice standing in for the group |
| Write down the strongest argument for the runner-up | Forces you to name what you are giving up |
| Record what would make you reverse the decision | Gives the next review something to check against |
That last row is worth the effort. Two years on, the question is not whether you chose correctly; it is whether the reasons still hold. A short written record of why turns renewal from a rehash into a five-minute check.
What the decision usually comes down to
After the disqualifiers and the trial, most organizations find the choice resolves on one of three things, none of which appear in a ranking:
- The administration matches how you work, or it does not, and you feel it every week.
- The price shape fits your seat count and your address count, or it charges you for structure you cannot avoid.
- The things you already run connect cleanly, or every integration becomes a small project.
If two candidates are genuinely close on all three, they are close, and the honest conclusion is that either would be fine. Pick the one with the easier exit and move on to a decision that matters more.
Where to read next
Two of the four disqualifiers are settled outside the mail product entirely. The administration questions belong to the administration layer, the arrangement underneath the mailbox is covered in the hosting decision, and the connections you will have to re-establish are worth listing in the connection register before the trial rather than after it.
Common questions
Is the mail included in an office suite good enough?
For most organizations, yes, and it should be the first candidate rather than the fallback. Run it through the four disqualifiers like anything else. If it passes, the money and the attention are better spent elsewhere.
How long should a mail trial run?
Long enough to include a real week of work and at least one external correspondent who is not helping you test. Two weeks is usually enough, because mail problems appear quickly and loudly, unlike storage problems.
Should we ask for a reference customer?
Yes, and ask them what broke rather than whether they are happy. For mail specifically, ask what happened the first time delivery failed and how long it took to get a person on the phone.
What if we cannot answer the retention question?
Then that is the first piece of work, before any product decision. The retention period is set by what your organization is obliged to keep, and choosing a product before knowing it means choosing a tier at random.
