Moving Alert and Email-to-Ticket Mail off SMTP AUTH to Microsoft Graph API

Every monitoring alert, scheduled report, and email to ticket conversion in your stack depends on a mailbox. Most monitoring and helpdesk management tools still reach that mailbox the old way.

They log in with a username and password over SMTP or EWS. Exchange Online is closing both doors on a published schedule. The tools that fail will fail silently.

In this blog, you will:

• See the exact Microsoft dates for SMTP AUTH basic authentication and EWS.

• Learn which IT tools stop sending or reading mail, and how to find them first.

• Set up the Azure app registration that Microsoft Graph API needs.

• Migrate alert notifications, scheduled reports, and email-to-ticket processing in order.

By the end, you can run the change on a weekday afternoon and know nothing went quiet.

What Is Changing With SMTP AUTH on Exchange Online?

Exchange Online is removing basic authentication from Client Submission. Client Submission is the SMTP AUTH endpoint that applications and devices use to send mail.

Basic authentication for every other protocol ended in late 2022. SMTP AUTH was the one exception Microsoft kept open.

According to the Exchange Team's updated deprecation timeline, the schedule now runs in three steps:

• Now to December 2026: SMTP AUTH basic authentication keeps working unchanged.

• End of December 2026: Microsoft disables it by default for existing tenants. Administrators can re-enable it, for now.

• New tenants after December 2026: Basic authentication is unavailable by default and OAuth is the supported method. Microsoft will announce the final removal date in the second half of 2027.

A second clock runs alongside it. Microsoft starts disabling Exchange Web Services for Exchange Online in October 2026. EWS shuts fully by April 2027.

Any tool that reads a mailbox through EWS to create tickets sits on that clock. Its outbound mail does not matter. The next question is which tools those are.

What Breaks in IT Tooling When SMTP AUTH Is Disabled?

Anything that logs into smtp.office365.com with a stored password stops sending. Once basic authentication goes off, the server rejects every submission.

The reply is 550 5.7.30 Basic authentication is not supported for Client Submission. The sending tool logs a delivery error that nobody watches.

In an IT operations stack, that list runs longer than it looks:

• Monitoring alert notifications: The mail path most alert policies use by default. A CPU alert still fires inside the tool, and the email that would have woken someone never leaves.

• Scheduled reports: Weekly availability or SLA reports go out through the same connector, so a management report stops arriving.

• Service desk notifications: Ticket assignment, status change, and SLA breach emails from the ITSM platform.

• Inbound mailboxes: The support mailbox the desk polls to create tickets. If it connects over EWS, October 2026 is the date to watch.

• Everything else with an SMTP field: Backup jobs, scanners, UPS management cards, and scripts.

The failure stays quiet because the tool believes it sent the mail. An incident management process that relies on email for its first notification can lose its first responder. No dashboard turns red. So find these senders before the cutoff. The SMTP AUTH Clients Submission Report in the Exchange admin center shows which senders still use basic authentication. It has shown that since October 2024.

How Does Microsoft Graph API Replace SMTP for Sending Mail?

Microsoft Graph API sends mail as an HTTPS request to graph.microsoft.com on port 443, authorized by an OAuth token instead of a mailbox password. The exchange runs in three steps.

1. Get a token: The sending tool calls login.microsoftonline.com with its application ID and a client secret or certificate.

2. Send the message: It calls the mailbox's send endpoint on graph.microsoft.com with that token in the request.

3. Exchange Online delivers: The mail leaves the mailbox as if a user had sent it, and the token expires on its own soon after.

Three things improve in that exchange:

1. No stored password: Nothing in the tool's configuration file can be lifted and reused.

2. Short-lived credentials: A leaked token dies in about an hour, and a client secret has an expiry date you set.

3. One scoped permission: Access belongs to one registered application, which an administrator can limit to one mailbox and revoke in one click.

Graph is one of four routes Microsoft names for tools that must keep sending. The table shows where each one fits.

Whichever route you pick for the bulk senders, the alerting and ticketing tools land on Graph, and Graph starts with an app registration.

What Does the Azure App Registration Require?

The app registration is the whole migration, and everything after it is configuration. You need someone with Global Administrator rights for about twenty minutes.

You also need outbound HTTPS from the tool to login.microsoftonline.com and graph.microsoft.com.

Register the app in Microsoft Entra ID as single-tenant. Then collect three values: the Application (client) ID, the Directory (tenant) ID, and a client secret.

Copy the secret when you create it, because Azure will not show it again. Record its expiry date somewhere your team will see it.

Then grant the Microsoft Graph application permissions the tool actually needs. The table shows which permission does which job.

Add only the rows you need. A tool that sends alerts and never reads a mailbox gets Mail.Send and nothing else.

Two steps close the registration.

1. Click Grant admin consent so every permission shows a green checkmark. The tool cannot consent on its own.

2. Then restrict the app to the one mailbox it should touch. That takes an Application Access Policy in Exchange Online PowerShell (New-ApplicationAccessPolicy with -AccessRight RestrictAccess).

Without that policy, an application permission reaches every mailbox in the tenant. With the registration done, the two migrations can start, and outbound mail goes first.

How Do You Migrate Alert Notifications and Scheduled Reports?

Outbound mail makes the easier half. It only needs Mail.Send, and nothing in the tool has to learn to read. Work through it in this order.

1. List the senders: Pull the SMTP AUTH Clients Submission Report and match each basic-auth sender to a tool and an owner.

2. Register once and reuse: One app registration with Mail.Send can serve several tools if they all send from the same mailbox. Keep separate registrations for separate mailboxes.

3. Add Graph as a delivery method: In the monitoring tool, add Microsoft Graph beside the existing SMTP server. Enter the client ID, tenant ID, and secret, and keep the SMTP entry for now.

4. Send a real alert: Trigger a test policy and confirm the email arrives, with links that resolve from outside the network.

5. Cut over the monitoring alerts and reports: Switch the default delivery method, and watch the next scheduled report land before you remove SMTP.

Set a reminder for the client secret expiry while you are in the portal. An expired secret produces the same silence as the deprecation, on a date you chose. Inbound mail is the harder half, and it comes next.

How Do You Migrate Email-to-Ticket Processing?

Inbound mail has two moving parts, and only one of them sits on the SMTP AUTH clock. The service desk reads the support mailbox through IMAP, POP3, or a Microsoft mailbox API, and it replies through an outgoing server.

Basic authentication for IMAP and POP3 ended in 2022, so a desk still reading a Microsoft 365 mailbox does it with OAuth or with EWS today.

If it uses EWS, you have found the migration. Work through it in this order.

1. Confirm how the desk reads the mailbox: Open the incoming email server settings and note the protocol and connection type. EWS is the one on the October 2026 clock.

2. Add the read permissions: Reuse the app registration from the alerting migration and add Mail.Read and Mail.ReadBasic.All as application permissions, then grant admin consent again.

3. Keep the access policy tight: A reading permission reaches further than a sending one, so confirm the Application Access Policy still names only the support mailbox.

4. Switch the connection type to Microsoft Graph: Change the setting on the existing server entry, and paste in the same client ID, tenant ID, and secret.

5. Run the connection test: A pass proves the token and the permissions work. It does not prove a ticket gets created.

6. Send a real email to the support address: Watch for the ticket, the right technician group, and the right category.

7. Check the auto-reply filters survived: The rules that discard out-of-office and automatic replies must still be active after the switch.

Step seven is the one teams skip. We have watched an out-of-office storm on cutover day, and it teaches that lesson fast. The same seven steps apply whatever service desk you run, and the next section shows what they look like on ours.

How Motadata Supports Microsoft Graph API

Both halves of the unified observability and ITSM platform added Microsoft Graph in the same summer, because the same customers asked for it on both sides. Here is where it landed in each product.

The monitoring side is the quicker of the two, so it comes first.

ObserveOps Infinity: Alerts and Reports

ObserveOps Infinity added Graph as an email delivery method beside the existing SMTP options in 8.2.7, and it carries into version 10.0.0. Three things matter for the cutover:

• Nothing else changes: Existing alert policies, notification templates, and recipient lists stay as they are. The migration is a delivery setting and a test alert.

• Fix the links in the same session: Version 8.2.7 also lets you set a hostname or FQDN for the links inside alert emails, so an on-call engineer at home no longer gets a raw internal IP address.

• The mail platform itself stays monitored: The Microsoft Exchange integration covers what the monitoring side sees of Exchange, separate from how ObserveOps sends its own mail.

The service desk side has more moving parts, because it reads mail as well as sends it.

ServiceOps: Email to Ticket and Outgoing Mail

ServiceOps added Graph to email-to-ticket processing in version 8.7.5, as an OAuth-based alternative to SMTP and EWS, and version 8.7.6 extended it to the outgoing server. Four details decide how smooth the switch is:

• Two connection types on MAPI: Microsoft Graph API and Exchange Web Services are both offered, on on-premises and SaaS deployments. EWS stays available where Graph is not yet supported.

• Switch without losing anything: You can change an existing server's connection type at any time, and no ticket data or email mappings get lost.

• Two ways to authorize: Sign in with Microsoft uses a pre-registered application through a consent prompt, with no Azure portal access needed. A manual app registration suits teams that must own the app and scope it to one mailbox.

• A status light on the mailbox: Each email server card shows Reachable or Unreachable with a last sync time, and the Super Admin gets notified when a server drops. The silent failure this whole change is about finally gets a light.

Either product takes an afternoon to switch once the app registration exists, and the trial is the quickest way to prove that on your own mailbox.

Finish the Switch Before the Mail Goes Quiet

The deprecation is a credential change, and it only looks like an outage if it arrives unannounced. Every tool that sends or reads Exchange Online mail with a password needs three things before December 2026.

Those are an app registration, a scoped permission, and a real test. The EWS readers need them before October.

The honest cost is admin time. Someone with Global Administrator rights has to register the app and grant consent. Someone else has to own the secret's expiry date from then on. A token that quietly expires recreates the same problem in eighteen months.

Done in order, the payoff is an alerting and email to ticket chain with no mailbox password anywhere in it. Closed-loop incident management keeps running, and Microsoft has steered every tenant toward exactly that since 2019.

FAQs