Kintone mail and the SMTP basic auth deadline
If any part of your Kintone environment sends email using a stored username and password — a JavaScript customisation, a script, a scanner relaying through your tenant — it is on a clock. Google finished switching this off. Microsoft disables it by default for existing Exchange Online tenants at the end of December 2026.
What actually breaks
Basic authentication means sending a username and password to the mail server. Microsoft began removing it from Exchange Online in 2019 and finished for EAS, POP, IMAP, EWS and PowerShell by late 2022. SMTP AUTH client submission was the last exception, and it is now being closed.
When a client is rejected it receives 550 5.7.30 Basic authentication is not supported for Client Submission. That is a 5xx permanent failure — the sending server does not retry. Mail does not queue and arrive later; it is gone, and whether anyone notices depends entirely on whether something was watching.
The timeline
| When | What happens |
|---|---|
| Completed 2022 | Basic auth already removed from EAS, POP, IMAP, EWS and PowerShell in Exchange Online. SMTP AUTH was the last exception. |
| Now → Dec 2026 | SMTP AUTH basic authentication behaviour unchanged. |
| End of Dec 2026 | Disabled by default for existing tenants. Administrators can still re-enable it temporarily. |
| From Jan 2027 | New tenants cannot use it at all. OAuth is the supported method. |
| H2 2027 | Microsoft announces the final permanent removal date. |
Timeline as published by Microsoft (updated 27 January 2026). Dates have moved before — confirm current milestones in the Microsoft 365 Message Center before planning around them.
Why this hits Kintone environments specifically
Kintone has no built-in way to send arbitrary business email from a record, so almost every organisation that needs it has one of three things: a JavaScript customisation with SMTP credentials in it, a plugin that relays through a third-party sending service, or a scheduled script outside Kintone.
The first category breaks outright. The second keeps working but sends from the vendor's infrastructure rather than your corporate mailbox, which is a different problem — replies do not land in the mailbox your team actually watches, and the message never appears in anyone's Sent folder.
The migration options
Microsoft lists several supported paths: OAuth 2.0 with SMTP AUTH, the Microsoft Graph API, High Volume Email for line-of-business bulk sending, Azure Communication Services, or an on-premises SMTP relay in a hybrid configuration. For sending business mail from a Kintone record, OAuth 2.0 or Graph is the realistic choice.
The work is not the token exchange — that part is well documented. The awkward parts are refresh-token storage and rotation, and sending as a shared mailbox so replies arrive at sales@ rather than in one employee's inbox. That second requirement is the one most in-house implementations discover late.
What to do this month
1. Inventory. The Exchange admin center has an SMTP AUTH Clients Submission Report with an Authentication Protocol column showing basic auth versus OAuth. Start there — most organisations find senders they had forgotten, typically scanners and monitoring alerts.
2. Decide per sender. Devices that cannot do OAuth need a relay. Application senders should move to OAuth or Graph.
3. Do the Kintone ones deliberately. These are usually the ones with a person attached to the failure — a quotation that never arrived, an approval nobody was told about.
Common questions
When exactly does Microsoft turn this off?
Under the timeline published on 27 January 2026, SMTP AUTH basic authentication is disabled by default for existing Exchange Online tenants at the end of December 2026, though administrators can temporarily re-enable it. Tenants created from January 2027 cannot use it at all, and Microsoft will announce the final permanent removal date in the second half of 2027.
What error will we see when it stops working?
Clients receive 550 5.7.30 Basic authentication is not supported for Client Submission. Because it is a 5xx permanent rejection, the sending server will not retry, so the message is simply lost rather than delayed.
Does this affect Gmail as well?
Google has already completed the equivalent change — basic authentication for Gmail is gone, and OAuth 2.0 is the supported method. If your Kintone mail integration still works with a Gmail password, it is almost certainly using an app password rather than true basic auth, which is a separate mechanism with its own risks.
Can we just keep re-enabling it?
Only until the final removal date, which Microsoft says it will announce in the second half of 2027. Re-enabling is a stopgap for buying migration time, not a strategy.
How does Kinplug Mail handle this?
It authenticates with OAuth 2.0 and sends through your own Gmail or Microsoft 365 mailbox, including Send As and shared mailboxes. Replies land in the real mailbox and the message appears in its Sent folder, because it was genuinely sent from there rather than relayed by a third party.
Sending Kintone mail over OAuth 2.0
Kinplug Mail sends from your own Gmail or Microsoft 365 mailbox over OAuth 2.0 — Send As and shared mailboxes included, so replies arrive where your team is already looking. It is included in the single plan at ¥9,800 / $69 per month with every other plugin, and there is a 30-day trial.