A mail program on a reception desk stops working on a Tuesday and says the password is wrong. The password is fine. Nobody has changed it in four years, which is the actual problem: the program can only offer a username and a password, and the platform stopped accepting that as proof of anything.
That is a common shape of email software trouble in 2026, and no comparison table is built to show it to you. The tables compare features. What decides whether a program still works next quarter is duller and more consequential: what form the thing takes, where it runs, which protocol it speaks, and who in your company is allowed to say yes to it.
So this article is about form rather than features. If you are still working out which category of product you are actually shopping for, start there and come back. This page assumes you know roughly what you want the software to do and are trying to work out what kind of thing to install or connect.
The short version
- An email management program comes in one of four forms: installed client, add-in inside a client you already have, a service connected to the address, or a setting in the platform you already pay for.
- The desktop form is being rebuilt, and the replacement drops a long list of things the old one could do.
- Password-only connections are gone on both major platforms for the protocols an email program uses. The surviving exceptions are narrow and are not something to buy software on.
- Exchange Web Services starts being switched off in October 2026 and is fully disabled in April 2027. Ask any vendor which API it uses.
- A program is installed and authorized per person on a device. A company address is not a person, which is where the program form quietly fails.
The four forms an email management program comes in
An email management program is software that connects to a mailbox and does something to the mail before or after a person reads it: sorting, filing, assigning, drafting, archiving. Almost everything sold under that description is one of four things, and they look similar in a feature list while behaving nothing alike once installed.
| The form | What it runs on | Serves a person or an address | Who has to approve it |
|---|---|---|---|
| Installed client | One machine, one operating system, one login | A person | The person, if they can install software |
| Add-in inside your existing client | Inside the client, so the client decides what it may do | A person, sometimes a whole tenant | An administrator, for anything deployed centrally |
| Connected service | The vendor's servers, reaching your mailbox over an API | Either, and this is the only form that does an address properly | An administrator, because it needs consent to the mailbox |
| A setting you already own | The platform you already pay for | Whatever the platform supports | Often nobody, which is why it is worth checking first |
The fourth row is the one that gets skipped, and it is also the free one. Filters, rules, delegation and the shared mailbox are already inside a subscription you pay for, so the honest first move is to find out whether they cover it before pricing anything else. The other three forms are separately priced, and in units that do not compare cleanly with each other, so two quotes can look close and cost very different amounts a year later. What each category actually charges you for is worth reading before you put any two side by side.
The three paid forms differ mainly in who is on the hook for them. An installed client is a person's decision until it is not. An add-in is the client's decision. A connected service is the administrator's decision, and that is not a formality: it is the only form that can be authorized against an address instead of against a human being.
Which forms are even available to you is decided one level up, by the platform you are on. The add-in form exists only where the client does, so a company standardized on the browser has three options rather than four. That is worth settling before you shortlist anything, because it removes a whole column.
The desktop program is turning into a web app
If your mental model of an email program is an application that lives on your hard drive and works when the network does not, check that model against what the flagship one has become.
Microsoft's own overview of new Outlook for Windows describes it as an experience "provided by Outlook on the web" running inside a Native Windows Integration Component and using WebView2, delivered as an MSIX package, with Windows-integration updates arriving from a content delivery network roughly every week. That is a browser view in a native frame that updates itself, and it is the direction of travel for the category.
The consequences are published, not rumored. Microsoft's new and classic Outlook feature comparison lists COM add-ins, VBA macros, custom forms, rules import and export, voting buttons and access to files on a network share as Not supported in new Outlook. Offline support, rules, conditional formatting, search folders, public folders, Quick Steps, delegate access to shared mailboxes and PST file support are all listed as Partially available, which is a longer list of asterisks than most people expect to find on the default mail client.
Read that against the way software gets sold to you. "Works with Outlook" is now an incomplete sentence. The honest version of the question is which Outlook, and if the answer is the classic one, you are buying into the client your IT department will eventually migrate off.
This is a direction, not a deadline. The same overview says new Outlook "is currently offered as a preview for commercial accounts and is generally available for consumer accounts", so business tenants are not being moved this week and classic Outlook still does the things on that list. But the direction is settled, and anything you buy today should work in the client you will be using in two years, not only in the one you have open now.
If it plugs into your client, check which client
The add-in form has split into two incompatible platforms, which is the most expensive detail in this article for anyone about to standardize a team on one.
Microsoft's guidance on moving from COM add-ins to web add-ins puts the split in one sentence: "In new Outlook for Windows, web add-ins are fully supported, with no other work required from partners. COM add-ins aren't supported in the new Outlook for Windows, but continue to work in classic Outlook for Windows." Since classic Outlook supports both kinds, a web add-in is the only choice that survives either way, and that asymmetry is the whole buying rule. Microsoft also notes that by default, users are offered web add-in counterparts of their existing COM add-ins when they switch, which helps only if the vendor has built one.
One line to put in an email to any vendor selling you something that lives inside Outlook: is your add-in a web add-in or a COM add-in, and is it supported in new Outlook for Windows today? An evasive answer to that question is itself the answer.
How a program is allowed to connect, and what has already been switched off
Every program in the first three forms has to authenticate to a mailbox. Both major platforms have removed the old way of doing that, and the change is finished rather than pending.
On the Microsoft side, the deprecation of Basic authentication in Exchange Online is blunt about how final it is: "Basic authentication is now disabled in all tenants", and "Now no one (you or Microsoft support) can re-enable Basic authentication in your tenant." The removal covered Exchange ActiveSync, POP, IMAP, Remote PowerShell, Exchange Web Services, the Offline Address Book, Autodiscover, Outlook for Windows and Outlook for Mac. The same page adds a detail worth carrying into the next section: "There's no plan for Outlook clients to support OAuth for POP and IMAP, but Outlook can connect using MAPI/HTTP (Windows clients) and EWS (Outlook for Mac)."
Google made the equivalent change on its own schedule. Its guidance on the transition from less secure apps to OAuth states that "CalDAV, CardDAV, IMAP, SMTP, and POP will no longer work with legacy passwords (basic authentication)", with access to less secure apps turned off for all Google Accounts on 14 March 2025. It also names the symptom, which is the useful part: affected users get an error saying their username and password combination is incorrect. It is not a password problem and no amount of resetting will fix it.
There is a prerequisite underneath all of this that catches small teams. Google's instructions for setting up Gmail with a third-party email client require an administrator to turn IMAP on in the Admin console before any client can connect, and Google recommends using Gmail only with third-party clients that support OAuth. If nobody at your company holds that console, the connection is not a support ticket for the vendor. It is an internal decision that has not been made yet.
The exceptions are real and narrow, and knowing them is what keeps this from being a slogan. Google still allows an app password where a device genuinely cannot do OAuth, and for a scanner that mails documents it lists exactly three options: configure the device for OAuth, find another way to send, or "Configure an app password for use with the device". On the Microsoft side, SMTP AUTH is the loose end: the same deprecation page says that while SMTP AUTH is currently available, Microsoft has announced plans to retire Basic authentication for it and that the retirement timeline has been updated, so it is pending rather than done.
Neither exception is a foundation to buy software on. Both exist for hardware that cannot be changed, and both are shrinking. Two readings for a shortlist follow from that. An email program whose only answer to "how do you authenticate" is a password belongs to the previous decade. And an old program that suddenly claims your credentials are wrong has almost certainly been retired out from under you, not broken.
Exchange Web Services goes dark starting October 2026
This is the fact worth acting on this quarter.
Microsoft's deprecation notice for Exchange Web Services publishes the timeline as two dated entries: "October 2026: EWS starts to be disabled globally for all organizations" and "April 2027: EWS is fully disabled." EWS stopped receiving functionality updates back in 2018 and the shutdown date was set in 2023. The January 2024 Midnight Blizzard security incident involved EWS, raised the urgency, and, in Microsoft's words, the scope "was also widened from third party applications to include all Microsoft applications". Microsoft lists Outlook, Office, Teams and Dynamics 365 among its own products it is removing EWS dependencies from. That is also where the Outlook for Mac connection above lands, since EWS is the protocol it uses.
Under Call To Action the same page tells customers, among other steps, to "Work with your vendors to prioritize their migration from EWS."
Turn that into one question you ask before signing anything: which API does your product use to reach our mailboxes? Microsoft Graph is the current answer on that platform. EWS is a dated one, and a vendor still building on it in late 2026 has a migration ahead of it that you would be paying for during. This matters most for the connected-service form, because that is the form whose entire value depends on a server-to-server connection continuing to work while nobody is watching it.
Per person, per device, or per address
Here is the structural limit of the program form, and it has nothing to do with quality.
A program is installed by a human being on a machine and authorized as that human being. Everything it holds is downstream of that identity. A company address is not a human being. It has no laptop, no login of its own, no consent to give.
That mismatch shows up in the same four places every time. Somebody leaves and the mail history leaves with their profile. A laptop is replaced and the only local copy of two years of correspondence is on the old one. A password gets shared so a colleague can cover a week of holiday, which is the moment your audit trail stops meaning anything. And nobody can answer the ordinary question of who is handling the message that arrived twenty minutes ago, because the program was never designed to have an opinion about that.
Microsoft's own comparison table carries a quiet marker of this: delegate access to shared mailboxes is one of the features listed as only partially available in new Outlook. The shared-address case sits at the edge of what a personal client is built to do.
If the mail you are trying to manage arrives at an address several people answer, the form you want is the connected service, because it is the only one that attaches to the address instead of to a person. A shared inbox tool like TriageFlow connects to the mailbox itself and holds ownership and history against the address, so a departure or a reimaged laptop takes nothing with it.
Do the process before the purchase, though. Deciding what the sorting is supposed to achieve is cheaper than buying something to do it, and how a team runs email triage on a shared address is where that starts. Once you know that, the criteria that decide a shared inbox shortlist is the comparison to run.
What the program you already have does, before you add another one
The fourth form deserves an honest look, because it is already paid for and it is more capable than most buyers assume.
Filters and rules do real work: sort on arrival, label, forward, mark, file. They run whether your machine is on or off, because they run at the platform and not in the client. They are also the free way to find out whether sorting is your problem at all. Give them a week. If nothing feels different afterwards, the problem is not where messages land, and no program you buy will fix it either.
The team features are the part that gets missed. A Google Collaborative Inbox already puts real states on a group address: a member can take a conversation or assign it to a colleague, close it out as complete, as no action needed, or as a duplicate, and filter the queue by what is assigned to whom. What it does not add is a service level, waiting-time reporting or automatic routing, which is where teams outgrow it.
The client-level settings people go hunting for are usually already there too. The compose fields are a good example: where the Bcc field went in new Outlook is a setting, not a missing feature, and the same is true of most of what looks absent after a migration.
Offline behavior is worth checking before you write the browser off as a lesser client. Google documents that Gmail offline works only in a Chrome browser window that is not in Incognito mode, and lets you choose how many days of messages to sync. That is narrower than an installed client and wider than most people assume.
Where all of this stops is at proof of ownership under load. A rule can file a message. It cannot tell you that a colleague opened it four minutes ago and is halfway through a reply. If that is the failure you keep hitting, the difference between a shared mailbox and a distribution list is the distinction to get straight before you spend anything.
A checklist before you install or connect anything
This is the plumbing list. It tells you whether a program can work here, not whether it does what you need, and those are separate questions: what a tool has to do that a rule cannot covers the second one. Run this list first, because it is faster and it disqualifies more.
Eight questions, each with a one-line answer.
- Which of the four forms is this? Installed client, add-in, connected service, or a setting we already own. If the honest answer is the fourth one, stop here and go configure it.
- Does it serve a person or an address? If several people answer the mail and the tool authenticates as one of them, it will be worked around within a month.
- If it is an add-in, is it a web add-in? COM add-ins do not run in new Outlook for Windows.
- Which Outlook does it support, today? New, classic, or both. Ask about today, not the roadmap.
- What does it authenticate with? OAuth. A password-only answer is disqualifying for software, whatever the exceptions are for hardware.
- Which API does it use to reach the mailbox? Treat EWS as a dated answer given the October 2026 start of the shutdown.
- Who at our company has to approve it? Anything that connects to mailboxes needs an administrator. If nobody here holds that console, three of the four forms are unavailable to you today, and that is the thing to fix before the trial rather than during it.
- What happens to its copy of our mail when we stop paying? A good answer is a self-service export in a standard format and a stated retention window. A vague one is a switching cost you have not priced yet.
Frequently asked questions
What is an email management program?
It is software that runs somewhere and connects to a mailbox in order to sort, file, assign or reply to mail. Where it runs turns out to matter more than what it claims to do, because that decides who has to approve it, what happens when a laptop is replaced, and whether it survives the next platform change. There are four places it can run: your machine, inside your existing client, on a vendor's servers, or inside the platform subscription you already have.
What is the difference between an email client and email management software?
The client is where one person reads and writes mail. A management layer sits on top of it, beside it, or in place of it, and it deals with what happens to messages before and after a person looks at them. Ask who the software thinks the user is. A client is always built around one person's mailbox. Software built for a shared address treats the address as the thing that owns the conversation, which is why the two categories cannot be swapped for each other even when the feature lists overlap.
Why did my email program stop connecting and say my password is wrong?
Almost certainly because password-only authentication was withdrawn, not because anything is wrong with your account. Microsoft removed Basic authentication from Exchange Online for protocols including POP, IMAP and Exchange ActiveSync and states that nobody can re-enable it, and Google turned off less secure app access for all accounts in March 2025, with an incorrect-password error as the documented symptom. The fix is a client that supports OAuth, not a new password.
Can I just use Outlook or Gmail rules instead of a separate program?
For one person's mailbox, usually yes, and it is the right thing to try first because you have already bought it. On a group address, look at what your platform gives you before you conclude the answer is no: a Google Collaborative Inbox adds assignment and a resolution state to a group at no extra cost. What rules and group settings do not give you is a service level, waiting-time reporting or automatic routing, so the ceiling arrives when you have to prove what happened rather than just handle it.
Do any of these work without leaving Gmail or Outlook?
Yes, and the form determines how. An add-in puts the software inside the client, subject to whether it is a web add-in and which Outlook you are running. A connected service leaves the client alone and works against the mailbox over an API, so people carry on in the interface they already know. Both avoid a migration. The difference is that only the connected service can be authorized against the address itself, which is what you need if the mailbox outlives the people answering it.
Is an email management program the same as a mail triage tool?
They overlap without being the same. Triage is the specific decision about what each incoming message needs and from whom, and a program is one of the places that decision can be made. Many management programs sort and file without ever making a triage call, which is why a full inbox can be extremely tidy and still leave the urgent message unanswered. What email triage is and how to run it is the better starting point if that is the failure you recognize.