Microsoft 365 basic auth shutdown — Kintone mail after April 2026

On April 1, 2026, Microsoft 365 completes its shutdown of basic SMTP authentication for Exchange Online. This affects most Kintone mail plugins on the market, which have historically relied on this authentication method. This post explains what actually breaks, what the observable symptoms are, and the real migration options — written from the perspective of a Kintone consultancy that has worked with production environments since 2019.

What's actually shutting down

As part of a multi-year Exchange Online security hardening program, Microsoft is removing basic authentication entirely. The authentication methods going away:

• SMTP AUTH (basic-auth SMTP sending)
• IMAP and POP3 basic auth (mail receiving)
• Exchange ActiveSync basic auth
• EWS basic auth
• PowerShell basic auth

These all share the same pattern: a username/password pair Base64-encoded and sent to the server. Simple, but vulnerable — a leaked password creates a direct send-path for attackers. Microsoft began the phased shutdown in October 2022 and hits the final deadline in April 2026. For SMTP AUTH specifically, if your tenant admin has already opted out, you may have lost access earlier.

Google did the equivalent for Gmail back in September 2024. The industry direction is clear.

Impact on Kintone mail sending

There are four common patterns for sending mail from Kintone. Each has different exposure:

Sending method	After April 2026	What happens
SMTP basic-auth plugin	Broken	Password auth is rejected by server
OAuth 2.0 plugin	Unaffected	Uses Microsoft Graph API, works normally
Kintone native notifications	Unaffected	Inbound-only, no auth needed
Custom JavaScript + SMTP	Needs rewrite	Must rebuild on OAuth

The two common cases are the SMTP basic-auth plugin and custom JavaScript implementations. Both fail the moment April 1 arrives.

Symptoms you might already be seeing

Microsoft has been progressively disabling SMTP AUTH at the tenant level in the months leading up to the full shutdown. Typical symptoms:

• Mail sending fails for specific users but not others (tenant admin is mid-rollout of the opt-out)
• Error logs show 5.7.30 ClientSubmitTime is required or SmtpClientAuthentication is disabled for the Tenant
• Kintone process-management actions that send mail stop working, but other actions keep functioning
• Send timeouts increase, with intermittent failures that look unstable but follow a pattern

If you're seeing these symptoms, the shutdown is already partially in effect on your tenant.

Your migration options

Option 1 — Re-enable basic auth temporarily (not recommended)

In the Microsoft 365 admin center, you can technically re-enable SMTP AUTH on a per-user basis. This is a stopgap, not a solution. On April 1, 2026, this option disappears. There's no reason to choose this path unless you need a few weeks or months to plan a real migration.

Additionally, basic auth has poor security posture — a single phished password gives an attacker full send access. Security auditors flag it. In financial, healthcare, and public-sector Kintone environments, admins may refuse to re-enable it regardless of convenience.

Option 2 — Migrate to an OAuth 2.0 mail plugin (recommended)

The cleanest and fastest resolution. OAuth 2.0 plugins send through Microsoft Graph API. Instead of storing a password, they use token-based authorization: the user authenticates once on Microsoft's own consent screen, and the plugin holds a renewable token afterward.

Concrete benefits:

• Fully unaffected by the basic-auth shutdown
• Send As support — send from shared mailboxes with proper delegation
• SPF/DKIM/DMARC work correctly because sends originate from Microsoft's own infrastructure
• Audit logs show exactly which user sent what
• API rate limiting is managed by Microsoft, not your mail server

Option 3 — Stay inside Kintone native functions

Kintone has native notification functionality: process-management status notifications, app-permission change notifications, comment notifications. These send from Cybozu's own mail infrastructure and are unaffected by the Microsoft shutdown. They're fine for system-originating notifications.

But they can't automate custom customer-facing mail — quote delivery, project updates, thank-you emails. For that, you need a plugin.

What a migration actually looks like

Migrating from an SMTP basic-auth plugin to an OAuth plugin generally follows this path:

1. Install the OAuth plugin (don't remove the existing plugin yet)
2. Authorize your sending account via OAuth — one time, on Google or Microsoft's consent screen
3. Port your mail templates, recipient logic, and process-management actions to the new plugin
4. Run test sends to verify correct behavior
5. Disable the old plugin and switch traffic to the new one
6. Run both in parallel for ~2 weeks to confirm no edge-case failures
7. Remove the old plugin

Typical migration time in our experience is 3–8 hours of actual work, depending on template count and logic complexity. Environments with complex process-management integration take 1–2 days.

Things to watch during migration

Send As requires Exchange admin delegation

If you send from a shared mailbox (e.g., [email protected]) using an individual user's OAuth token, the Microsoft 365 admin must explicitly grant Send As permission in Exchange Admin Center. This isn't something any plugin can configure — it's an admin-level setting. Plan for this before starting the migration.

Gmail "app passwords" don't exist anymore

The Gmail app password mechanism that used to work was retired in September 2024. If your old plugin relied on Google Workspace app passwords, you're already in migration territory — OAuth is the only path forward on Google side too.

Multi-subdomain environments need per-subdomain scoping

If your organization runs multiple Kintone subdomains (e.g., sales.kintone.com and ops.kintone.com), OAuth connections should be scoped per subdomain. Sharing connections between subdomains creates cross-domain misuse risk. Kinplug Mail stores OAuth connections in a Kintone app with the subdomain recorded, and enforces scoping at runtime.

Where Kinplug Mail fits

Kinplug Mail was designed on OAuth 2.0 from the beginning. We never supported SMTP basic auth, which means the Google and Microsoft auth-method changes don't affect our architecture.

• Gmail and Microsoft 365 support
• Shared mailbox Send As delegation
• Per-subdomain OAuth connection scoping
• Free migration support from any SMTP-based plugin
• 14-day trial lets you verify in your real environment
• Configuration lives inside Kintone — no external portal login

Demand for OAuth-native mail plugins spikes in the weeks approaching April 2026. If you're planning a migration, earlier is easier.

Related resources

• Kinplug Mail product page
• Migration documentation
• Comparison with other mail plugins

For OAuth migration inquiries, contact [email protected]. If it's urgent, please mention so — we respond same-day during JST business hours.