Microsoft 365 email signatures after the move to Microsoft Graph

If you manage email signatures in Microsoft 365 with PowerShell, the ground has shifted under those scripts. The Azure AD and MSOnline PowerShell modules were retired through 2025, and Exchange Web Services begins switching off in October 2026. Microsoft Graph is the official path forward for both.

For most Microsoft 365 tasks, that migration is well documented. Signatures are the exception. The methods IT has leaned on to apply email signatures across a tenant sit directly in the path of these changes, and Microsoft Graph, the recommended replacement, has no API for managing email signatures at all.

So this is less a migration than a dead end for the scripted approach. The sections below cover what's changing, what it means for any signature script you still run, and the route that sidesteps the churn.

What the Azure AD and MSOnline PowerShell retirement means for signature scripts

The Azure AD and MSOnline PowerShell modules were retired through 2025, so any signature script that read user details through them stopped running until it's rebuilt on Microsoft Graph PowerShell. The modules managed identity in Microsoft 365. Neither ever set a signature, yet their retirement still reaches the scripts that build them.

Both modules handled user and group management: creating accounts, assigning licenses, configuring domains, and reading the directory attributes that describe each employee. A signature script leaned on them for that last task, querying names, job titles, departments, and phone numbers to drop into a template.

Microsoft deprecated the Azure AD, Azure AD Preview, and MSOnline PowerShell modules in March 2024 and retired them through 2025, directing admins to the Microsoft Graph PowerShell SDK as the replacement. The cmdlets no longer work.

The practical result for signatures is narrow but real. Any script that read employee details through the Azure AD or MSOnline modules has to be rebuilt against Microsoft Graph PowerShell before it will run again. The code that assembles the signature is untouched, but the directory data feeding it is what stopped flowing.

What is Microsoft Graph PowerShell, and why did Microsoft move to it?

Microsoft Graph PowerShell is a module built on the Microsoft Graph API, the single interface Microsoft now uses to reach data across Microsoft 365. Microsoft moved to it because one modern, consistent endpoint is easier to secure and maintain than the patchwork of older APIs it replaced.

Microsoft Graph connects the services in Microsoft 365. Rather than a separate interface for each one, it exposes users, mail, files, groups, and directory data through a single API and a single access token, reaching Microsoft Entra ID (formerly Azure AD), Exchange, SharePoint, and Outlook from one endpoint. Microsoft Graph PowerShell wraps that API in cmdlets, so admins can script across those services from one module instead of several.

Retiring the Azure AD and MSOnline PowerShell modules was part of that consolidation. Both ran on the older Azure AD Graph API, a set of fragmented interfaces that no longer met modern security and cross-platform demands, which is why Microsoft moved to the Graph-based SDK. Graph brings modern authentication, granular permission scopes, and wider platform support, and it leaves Microsoft with one surface to maintain rather than many.

For identity work, this is a real upgrade. A signature script that reads names, titles, and departments can have those queries rewritten in Microsoft Graph PowerShell and keep running. Microsoft Entra PowerShell, also built on Graph, is an identity-focused alternative with close compatibility to the retired modules. The limit shows up in the other half of the script's job: applying the signature.

What the move to Microsoft Graph means for existing signature scripts

A scripted signature does two jobs: it reads employee data from the directory, and it applies a signature to the mailbox. The move to Microsoft Graph changes both, and the harder problem is the second.

The “reading” job has a clear path forward. Queries that pulled names, titles, and departments through the retired modules can be rewritten in Microsoft Graph PowerShell and will keep working. That work is finite: update the queries, test, redeploy.

The “applying” job is where things get messy. When EWS is blocked by default on October 1, 2026, ahead of full retirement in April 2027, the one programmatic route some tools used to read and write Outlook signatures closes, and because the Graph API has no support for managing signatures, nothing replaces it. The remaining native option, Set-MailboxMessageConfiguration, still sets an Outlook on the web signature, but its SignatureHTML parameter stops working once Outlook roaming signatures are enabled, now the default in many cloud tenants.

So the transition doesn't modernize signature scripts. It narrows them. The data half needs rebuilding, the applying half loses its cleanest path, and every future platform change adds another round of testing on top of routine updates.

That upkeep is already costly: in Exclaimer's State of Business Email 2025 research, 35% of IT teams named email signature management one of their two most time-consuming tasks. A maintained signature script is an in-house build, and it carries the running cost of one. That’s worth weighing before you keep investing in it.

Can you still manage Microsoft 365 email signatures with PowerShell?

Partly. Two native methods survive the transition, the Set-MailboxMessageConfiguration cmdlet and Exchange transport rules, but each has real limits and both leave the upkeep on IT.

The cmdlet sets the Outlook on the web email signature one mailbox at a time, and you can script it across users. The constraint is scope: it governs Outlook on the web rather than desktop Outlook, and it stops applying once Outlook roaming signatures are turned on.

An Exchange transport rule takes the other approach, appending an HTML disclaimer to outgoing mail at the server so it reaches every user at once. The trade-offs are familiar to anyone who has run one. The disclaimer lands at the bottom of the entire thread instead of under the latest reply, it doesn't appear in the sender's Sent items, and it can't reliably pull per-user details or inline photos into a designed layout.

Neither method delivers what most organizations actually want: a consistent, on-brand email signature that renders the same everywhere and updates itself from the directory. Few teams manage to get there this way. According to the State of Business Email 2025 report, 80% of organizations still rely on manual methods or user self-service, and only 18% use centralized management.

Build vs buy: managing Microsoft 365 email signatures without scripts

A maintained signature script is a small in-house build, and the past two years show how exposed that build is to Microsoft's roadmap. The build-versus-buy question for email signatures comes down to who absorbs the next platform change: your team, or your vendor.

It's a familiar pattern. According to Exclaimer's Build vs Buy research, 71% of in-house IT builds are eventually abandoned. Signature scripts fit that arc closely. They start as a few tidy lines, then accumulate edge cases, dependencies, and rewrites every time the platform underneath them moves.

A managed service changes where that exposure sits. Rather than scripts that read the directory and write to each mailbox, a dedicated email signature management platform handles the whole job itself. It syncs the data fields from Microsoft Entra ID automatically and keeps rendering consistent across desktop Outlook, Outlook on the web, and mobile. When Microsoft retires a module or an API, absorbing that change becomes the vendor's job rather than a weekend of rework for your team.

Exclaimer has done this for more than 20 years, since building the first email signature software in 2001, and Exclaimer's cloud solution now manages email signatures for over 80,000 organizations. IT keeps full control of policy and deployment while delegating design and content to marketing or HR, with no scripts to rewrite when the platform shifts.

The scripted column is a list of future tasks. The managed column is a list of things you no longer have to think about.

The bottom line for IT teams

The scripted route to Microsoft 365 email signatures still works in places, but every Microsoft platform change makes it narrower and costlier to maintain.

If you run a handful of mailboxes and your email signatures rarely change, keeping a script going may be fine for now. For most organizations, the maintenance only grows: directory queries to rebuild, native methods losing ground, and a fresh round of testing with each platform shift.

A managed platform takes that work off IT's plate and keeps email signatures consistent while Microsoft's tooling keeps moving. The real decision is simply whether you want to keep maintaining the scripts, or hand the problem to something built to absorb these changes for you.

Next step: Take email signatures off the maintenance list with a free trial of Exclaimer.