Email-Sending Agents in 2027: Moving SMTP to OAuth

SMTP OAuth is the migration I’d plan for any email-sending AI agent that still logs in to a Microsoft 365 mailbox with a password. At the end of December 2026, Exchange Online disables SMTP AUTH Basic authentication by default for existing tenants. SMTP itself can stay. What has to change is how the agent proves who it is.

A common pattern: an automation finishes a task, drafts a message and hands it to a mail-sending node. That node has a mailbox address and password saved in its settings, often copied from an older integration nobody has looked at since.

This note is for founders and operators running agents, background jobs, scanners and business apps that send through Microsoft 365 or Google Workspace. It covers what’s been announced, how to inventory senders, which OAuth option fits, how to handle credentials and what I test.

What is changing for SMTP, and why does it hit AI agents?

SMTP is how software sends email. OAuth is how that software gets and uses an access token instead of a mailbox password. They’re different layers. A workflow can keep using SMTP and only change how it authenticates; the job is removing the password dependency, not necessarily the mail transport.

That matters because many automations treat email as a minor last step:

1. An agent receives an event from a form, CRM or another app.
2. It works out what should happen next.
3. It drafts a notification, summary or request for human review.
4. A workflow node connects to a mailbox and sends it.
5. The workflow marks the step as done.

The agent’s real work might be classification or scheduling. Email is just how the result reaches a person.

My AI voice agent build shows the kind of handoffs involved: booking through n8n, a human handoff path, and fallback to voicemail with an automatic callback. I’m using it to show where notifications sit in an agent workflow, not to claim it sends through SMTP or any particular provider.

The trouble starts when a separate mail-sending component relies on a password the provider no longer accepts. Microsoft has already removed Basic authentication for protocols such as POP, IMAP and Exchange ActiveSync in Exchange Online, and it already disabled SMTP AUTH in tenants that weren’t using it. SMTP AUTH Basic authentication is on its own, later timeline.

What exactly has Microsoft announced, and what is still open?

Microsoft has published a staged transition, not a final removal date.

The Exchange Team’s 27 January 2026 update sets out:

• Now to December 2026: SMTP AUTH Basic authentication behaviour stays the same.
• End of December 2026: it’s disabled by default for existing tenants. Administrators can still turn it back on if needed.
• New tenants created after December 2026: Basic authentication is unavailable by default, and OAuth is the supported method.
• Second half of 2027: Microsoft will announce the final removal date.

That last line matters. Microsoft has not set the final removal date. So I don’t describe the December change as permanent removal. Equally, the option to re-enable Basic authentication is a short-term fallback, not a reason to keep an agent on a password.

Google Workspace is already further along. Its transition guidance says that from 14 March 2025, access to less secure apps was turned off and IMAP, SMTP and POP no longer work with legacy passwords. Third-party apps must use OAuth, with app passwords as the exception. For devices such as scanners, Google lists three options: configure OAuth, use another way to send, or set up an app password.

If you use both platforms, don’t assume one approach works the same everywhere. The practical target is an inventory of senders and a supported method for each.

Where do agents and automations still send mail with a password?

I start with the sending path, not the agent’s prompt or model.

A common pattern: the workflow looks modern, but its final email node still holds credentials copied from an older app. Another: a scanner, background service or line-of-business app sends through the same mailboxes as the agents. The inventory needs all of them.

For each sender I record:

• App or device: what creates the message?
• Mailbox: which address appears as the sender?
• Authentication: password, OAuth or something else?
• Execution: does someone sign in, or does it run unattended?
• Recipient: who needs the message, and why?
• Owner: who can change and test the integration?
• Dependency: which business process relies on it?

Include scheduled jobs and rarely used workflows, not just the agents getting attention. And treat “the workflow ran” and “the message was delivered” as two different facts to test.

Do your agents still send email with a password?

I can help map every sender and plan the OAuth move before the December 2026 default change.

Book a conversation

Which OAuth option fits an unattended agent?

The main decision is whether the app acts for a signed-in user or as itself. Microsoft covers both in its OAuth guide for IMAP, POP and SMTP.

Delegated access: a user signs in

Delegated OAuth fits when the app sends on behalf of a person who can authorize it. The user signs in and consents, and the app gets tokens for the permitted operation. For SMTP AUTH, Microsoft’s delegated scope is https://outlook.office.com/SMTP.Send, and the app can also request offline_access for refresh tokens.

I use this when sending belongs to a particular user’s identity. The trade-off: a background workflow shouldn’t depend on someone signing in again, and token renewal still needs handling.

Application access: the agent runs unattended

For an unattended sender, I look at the OAuth client credentials flow. Microsoft documents it as an alternative to the authorization code and device code flows: the app authenticates with its own identity, with no interactive sign-in.

The setup Microsoft describes:

1. Register the app in Microsoft Entra and add the SMTP.SendAsApp application permission.
2. Have a tenant admin grant consent.
3. Register the app’s service principal in Exchange Online with the New-ServicePrincipal cmdlet.
4. Grant that service principal access to the specific mailbox it will send from.
5. Request a token through the client credentials flow and use it for SMTP authentication, handling token expiry and auth failures without breaking unrelated work.

The delegated SMTP.Send scope and the SMTP.SendAsApp application permission aren’t interchangeable. I follow the documented setup for the chosen flow rather than copying a delegated configuration into an app-only sender. That’s the practical meaning of OAuth client credentials SMTP: no human sign-in, but an explicitly configured identity and mailbox access.

For an Exchange Online SMTP OAuth migration, I confirm the sender mailbox and the authorization model before changing anything in production.

How do I store and scope the agent’s email credentials?

I keep the agent’s reasoning context separate from the credentials its tools use. An agent can decide an email should go out without ever seeing the credential that sends it.

Authentication stays in the integration layer:

• Secrets: store client secrets or certificates in a secret store or protected credential facility.
• Tokens: keep access tokens out of prompts, model context and ordinary workflow output.
• Configuration: reference protected credentials instead of pasting secrets into config files or workflow nodes.
• Access: give the sending app access to the mailbox it needs and nothing more.
• Rotation: plan how credentials change without hand-editing every workflow.
• Logging: record auth status and delivery errors without logging tokens or secrets.

An OAuth access token is still sensitive. Swapping a password for a token doesn’t remove the need to protect it.

I also keep the sender identity out of the agent’s general instructions. The agent produces a structured request with recipient, subject and body. A dedicated mail component validates that request and sends it. I go deeper on scope and authority in my note on agent permissions.

This is general engineering guidance, not security or compliance advice.

When should an agent not use SMTP at all?

I don’t keep SMTP just because the current workflow uses it. Sometimes replacing the sending component is cleaner than retrofitting its authentication. The agent doesn’t need to know whether delivery happens over SMTP, an email API or a platform-native connector.

Three paths I compare:

• Keep SMTP: when the app supports OAuth properly and SMTP meets the workflow’s needs.
• Use an email API: when a supported API, such as Microsoft Graph, which Microsoft lists as an alternative for sending authenticated mail, gives a clearer boundary, auth model and error handling.
• Use a native integration: when the workflow platform already maintains a connection to the mail system.

An email API isn’t automatically better; it brings its own permissions, credentials and failure modes. The same goes for a native integration, and I check which auth method it actually uses rather than assuming the platform has already made the move. This ties into the wider choice between visual workflows and custom apps, which I cover in n8n AI agent or custom code.

For an AI agent email integration, my preferred boundary is simple: the agent requests a message, the sending component authenticates, and the workflow records the result. That way I can change the mail transport without rewriting the agent’s decision logic.

What is on my SMTP-to-OAuth checklist for 2027?

I treat this as a dependency migration with a tested rollback path.

• Inventory senders: every agent, workflow, scheduled job, scanner and app that sends email.
• Identify mailboxes: the sender address and the process that depends on it.
• Check authentication: which connections still use passwords or Basic auth.
• Classify execution: interactive, user-driven sending versus unattended background sending.
• Choose the method: delegated OAuth, client credentials, an API or a native integration.
• Configure access: app permission, admin consent, service principal and mailbox access where needed.
• Protect credentials: move secrets into protected storage and remove copies from workflow configs.
• Test tokens: first authentication, renewal and expected authorization failures.
• Test delivery: send controlled messages and confirm the right people get the right content.
• Test failure handling: what happens when auth fails, delivery is rejected or a send is retried.
• Prepare fallback: keep the previous config and a supported recovery route while the new path proves itself.
• Update documentation: owner, auth method, sender identity and maintenance steps.

I test the sending step on its own before wiring it into the full agent workflow, then run the end-to-end path with controlled inputs. A working SMTP connection doesn’t prove the right recipient, content or business event was handled.

I also make retries deliberate. An auth error shouldn’t make the agent generate duplicate messages or keep retrying without a stopping rule.

For Microsoft 365, I aim to finish before the end-of-December default change. If an existing tenant has to re-enable Basic authentication for a while, I document that dependency and keep the OAuth work moving, since the final removal date is still to come.

Key takeaways

• SMTP OAuth changes how a sender authenticates, not necessarily how mail is transported.
• Microsoft disables SMTP AUTH Basic authentication by default for existing tenants at the end of December 2026 and will announce the final removal date in the second half of 2027.
• Unattended agents need client credentials with SMTP.SendAsApp and an Exchange service principal, not a user’s sign-in.
• Tokens, secrets and mailbox access belong in the integration layer, not the agent’s prompt.
• A sender inventory, controlled tests and a fallback plan matter more than replacing a password field.

If you’re planning an SMTP-to-OAuth move for your agents or business apps, book a conversation and I’ll help map the senders and plan the transition, or see my AI agents and automation work. You can also subscribe to The Production Notes using the signup box below this post.

FAQ

Is Microsoft removing SMTP AUTH completely in December 2026?

No. Microsoft says SMTP AUTH Basic authentication will be disabled by default for existing Exchange Online tenants at the end of December 2026, and administrators can still re-enable it. Microsoft says it will announce the final removal date in the second half of 2027. SMTP AUTH with OAuth isn’t affected. See the Exchange Team’s timeline.

Can an unattended AI agent send email through Microsoft 365 with OAuth?

Yes. Microsoft documents the OAuth client credentials flow for apps that run without an interactive sign-in. The app needs the SMTP.SendAsApp permission with admin consent, a service principal registered in Exchange Online and access to the sending mailbox. Test authentication and delivery separately. Microsoft’s SMTP OAuth documentation walks through the setup.

Can Google Workspace apps still send SMTP email with passwords?

Not with legacy account passwords. Since 14 March 2025, Google has turned off less secure app access, and SMTP, IMAP and POP no longer accept them. Google allows app passwords as an exception and lists OAuth or another sending method for devices. I treat an app password as a narrow stopgap, not a migration plan. See Google Workspace’s guidance.

Should I replace SMTP with an email API for my AI agent?

It depends on the app and the workflow. If SMTP with OAuth is supported and fits, keeping it is reasonable. An email API such as Microsoft Graph, or a native connector, can be easier to maintain when it offers clearer authentication and error handling. Compare the options, test the full sending path, and avoid changing the agent’s decision logic when you don’t have to.