EWS deprecation and email signatures: what actually breaks

Exchange Web Services is being disabled in phases between October 2026 and April 2027. If your email signature tool relies on it, it will stop working somewhere in that window — and Microsoft Graph, the recommended replacement, cannot manage signatures at all.

The short version: EWS is not switched off on a single day. Microsoft begins disabling it globally in October 2026 and completes the shutdown in April 2027. Signature vendors built on EWS have no like-for-like migration path, because Graph has never supported signatures and is not scheduled to. The realistic replacements are an Outlook add-in, a transport rule, or outbound mail relay — and they are not equivalent.

The timeline, stated correctly

A good deal of the content circulating on this right now says everything breaks on 1 October 2026. That is not what Microsoft's documentation says, and the difference matters if you are planning a migration.

The mechanism is a tenant setting called EWSEnabled. Most tenants have never set it, so it sits at Null. As the rollout reaches a tenant, Null becomes False, and every EWS application in that tenant stops working at once. Because the rollout is progressive rather than simultaneous, two organisations on the same plan can lose EWS months apart.

This is a reprieve, not a solution. It keeps a specific application alive through the phased period; it does not survive April 2027.

Why Graph does not solve this

Microsoft's guidance for EWS migration is consistent and reasonable: move to Microsoft Graph. For calendars, contacts, mail and most mailbox operations there are direct mappings, and Microsoft publishes the operation-by-operation equivalents.

Signatures are the exception, and it is worth being precise about why.

Graph has never exposed an API for reading or writing Outlook signatures. This is not a gap awaiting a preview release. Microsoft publishes a roadmap of the EWS features Graph does not yet cover — mailbox import and export, public folders, Microsoft 365 Groups import/export, in-place archive, event delta for recurring events, sticky notes, user configuration, and a set of administration APIs. Signature management does not appear on that list, because signatures were never a first-class EWS mailbox object in the way calendars were. They live with the Outlook client.

The practical consequence: a signature vendor migrating from EWS to Graph is not porting an integration. They are choosing an entirely different deployment mechanism, with different coverage and different failure modes. When you are told a tool is "Graph-ready," the question worth asking is which of the mechanisms below it actually switched to.

Every remaining option, compared honestly

There are four ways to put a signature on outbound Microsoft 365 mail after EWS. None is strictly better than the others; they trade different things.

What "visible in Sent Items" is really about

Transport rules and relays both stamp the signature after the message leaves the client. The user composes without seeing it, and their Sent Items copy does not contain it. This sounds cosmetic and is not: it is the single most common source of support tickets in signature deployments, because users cannot tell whether the thing worked. Any evaluation that skips this will produce a tool your staff distrust.

Add-ins and client-side approaches show the signature in the compose window, which is why they persist despite the client matrix cost.

What outbound routing actually involves

Relay is the option most often misunderstood, usually in the direction of sounding more invasive than it is.

Signature insertion needs outbound routing only. In Microsoft 365 that is an Exchange Online outbound connector; in Google Workspace it is the SMTP relay or routing setting. Neither touches MX records. Inbound delivery is unaffected. Both are reversible from an admin console in minutes. This is how Exclaimer and Opensense already operate, and it is a smaller change than the phrase "route your mail through a third party" suggests.

The real cost is different and worth stating plainly: you are accepting a dependency in your mail path. If the relay operator has an outage, your organisation cannot send email. That is a genuine operational commitment on the vendor's side — 24/7 on-call, not a support queue — and it is a fair question to ask any vendor offering it. It is also why we would rather you did not start there.

What we would actually suggest

If EWS is what breaks for you, the temptation is to find the closest replacement and move on. We would push back on that for two reasons.

First, the phased rollout gives you more room than the 1 October framing implies. If your tenant has not been reached yet, you have time to evaluate properly rather than migrating twice.

Second, EWS-based tooling was usually chosen because it wrote signatures without touching the mail path. If you replace it with a relay, you have changed your risk profile substantially, and you should do that deliberately rather than as an emergency measure. A relay is the right answer when you need enforcement across every client including mobile, replies and forwards included. It is the wrong answer if what you actually needed was for signatures to be correct and current.

Worth separating before you choose: enforcement (nobody can send off-brand mail) and accuracy (signatures reflect current titles, current logo, current disclaimers). Most organisations describe an enforcement problem and, when the deployed signatures are examined, have an accuracy problem. Those have different answers, and the accuracy one does not require anything in the mail path.

How to check whether your tenant is affected

Three steps, none of which require a vendor. Do them in this order, because the first tells you how much time you have and the second tells you what you would break.

1. Read your current setting

In Exchange Online PowerShell:

Get-OrganizationConfig | Format-List EwsEnabled, EwsAllowedAppIDs,
    EwsApplicationAccessPolicy, EwsAllowList, EwsBlockList

EwsEnabled has three states, and the third is the one that catches people out:

Most tenants have never touched this, so most tenants read $null. That is the group the October rollout acts on.

2. Find out what is actually using EWS

Microsoft publishes this per tenant. In the Microsoft 365 admin center: Reports → Usage → Exchange → the EWS usage tab. It gives you, per application, the SOAP actions being called, the call volume, and the date of last activity, and it exports to CSV.

Two things about this report decide whether you get a true answer:

• Usage is aggregated weekly, not daily, and can take up to 10 days to appear. A 7-day window can therefore show nothing while an application is actively in use.
• Filter to 90 days, not 7 or 30. Anything that runs monthly — quarter-end exports, archiving jobs, a signature sync that only fires on directory change — will be invisible in a short window and will still break in October.

The report identifies applications by Entra application ID rather than by name. Resolve them under Enterprise applications in the Entra admin center; Microsoft also publishes a list of its own first-party application IDs. Expect a few that are Microsoft’s own — those are being remediated by Microsoft and are not your problem.

3. If something must survive October, allow-list it

Set-OrganizationConfig -EwsEnabled $true `
    -EwsAllowedAppIDs "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee,11111111-2222-3333-4444-555555555555"

Doing this before the end of August 2026 excludes your tenant from the automatic 1 October change. Leave it until September and Microsoft pre-populates an allow list for you based on observed usage — which inherits every blind spot in the point above.

Then ask your signature vendor one question

If a signature tool appears in your usage report, the useful question is not “are you ready for the deprecation” — everyone says yes. It is: which mechanism are you moving to? Graph cannot manage signatures, so the honest answers are an Office.js add-in, a transport rule, or an outbound relay, each with the trade-offs in the table above. A vendor who answers “we’re migrating to Graph” without naming one of those has not answered the question.

If you are on Google Workspace

None of this applies. EWS is an Exchange protocol; Google Workspace is unaffected by the deprecation entirely. Google's own limits are real but completely different in shape, and the Gmail API supports signature management directly as a server-side profile property — which reaches mobile without anything installed. We have written that up separately.