Microsoft 365 の基本認証（Basic Authentication）の完全廃止 が直接的な原因です。 ■ なぜ影響するか WP Mail SMTPで smtp.office365.com を使っている場合： 従来は ユーザー名 + パスワード だけでSMTP接続が可能 しかしMicrosoftは2024年3月前後から： Basic認証を順次無効化 特にSMTP AUTHでのユーザー名＋パスワード接続を停止 その結果： WP Mail SMTPでのSMTP送信 → Authentication failed で失敗 WordPress mail() 関数 → サーバー経由で送信可能（Basic認証不要） :bulb: この挙動がまさに「WP Mail SMTP有効で送信不可、無効で送信可」という症状です。 推奨：OAuth 2.0 に切り替える WP Mail SMTPで「Outlook / Microsoft メーラー」を選択 クライアントID / クライアントシークレットを使ったOAuth認証で接続 Basic認証不要で安定運用 :two: 一時的にSMTP AUTHを有効化（管理者操作） ただし将来的に完全廃止されるので長期的解決にはならない :three: 別SMTPサービスに切り替える SendGrid、Amazon SES、SMTP.com など Microsoft 365の制限に左右されずに運用可能 結論 提示内容の通り、**Microsoft 365 の Basic認証廃止が原因である可能性は非常に高い（最有力）**です。 特に「WP Mail SMTP ONで送信不可／OFFで送信可」という挙動は、SMTP認証失敗の典型パターンと一致します。 理由 今回の状況を整理するとこうなります。 ① 症状の一致 WP Mail SMTP ON → 送れない WP Mail SMTP OFF → 送れる（mail()経由） これはつまり、 フォーム処理 → 正常 WordPress → 正常 メール処理 → SMTP接続のみ失敗 という構造です。 ② Microsoft 365 の仕様変更と一致 Microsoft は段階的に Basic認証（ユーザー名＋パスワード）廃止 SMTP AUTHも制限強化 を進めています。

Grok 4.20

Vote: Yes

The described symptoms align precisely: WP Mail SMTP fails on smtp.office365.com while the default mail() function succeeds. Microsoft began disabling Basic Auth for Exchange Online (including SMTP AUTH) in 2022, with further enforcement waves through 2024, making username/password connections impossible without OAuth. This matches the exact failure pattern of Authentication failed only in the SMTP plugin path. Switching to OAuth 2.0 in WP Mail SMTP or using alternatives like SendGrid resolves it permanently.

GPT-5.4

Vote: Yes

提示された症状は、SMTP層だけが失敗している典型例です。 WP Mail SMTPを有効にすると Office 365 へ認証付きSMTP接続を試み、無効にするとサーバーの mail() 経由で送れるため、差分は Microsoft 365 側のSMTP認証要件にあります。 Microsoft 365 では Basic認証の廃止と SMTP AUTH の制限強化が進んでおり、ユーザー名+パスワード方式の既存設定はその影響を強く受けます。 特に「Authentication failed」で失敗するなら、フォームやWordPress本体ではなく認証方式の不一致が最有力です。 厳密にはテナント設定、SMTP AUTH無効化、条件付きアクセスなど近接要因もありえますが、直接的・最有力な原因としては Basic認証廃止に賛成です。 したがって vote は A です。

Claude Opus 4.6

Vote: Yes

The analysis presented is technically sound and logically consistent. The symptom pattern described — WP Mail SMTP enabled causes mail failure while disabling it (falling back to PHP mail()) allows mail to send — is a classic indicator of SMTP authentication failure at the relay level. Microsoft 365's deprecation and removal of Basic Authentication (username + password) for SMTP AUTH is a well-documented change that Microsoft has been rolling out since 2022, with continued enforcement through 2023-2024. This directly impacts any application using smtp.office365.com with plain credentials. The causal chain is clear: WP Mail SMTP connects to smtp.office365.com using stored username/password credentials → Microsoft rejects the Basic Auth attempt → authentication fails → mail is not sent. When WP Mail SMTP is disabled, WordPress falls back to PHP's mail() function, which uses the local server's MTA (e.g., sendmail/postfix) and does not require Microsoft 365 SMTP authentication at all. The recommended solutions (OAuth 2.0, alternative SMTP providers) are also appropriate and align with Microsoft's guidance. This is the most likely explanation for the described behavior.

Gemini 3.1 Pro

Vote: Yes

The provided text explicitly concludes that the abolition of Basic Authentication by Microsoft 365 is the direct and highly likely root cause of the email transmission failure. It logically breaks down the symptoms: when WP Mail SMTP is enabled, it attempts to use the now-disabled SMTP Basic Authentication (username + password) and fails. Conversely, when disabled, it falls back to the default WordPress `mail()` function, which works because it does not rely on Basic Authentication. Because the text thoroughly explains and concludes that Microsoft's specification change (the disabling of Basic Auth) is the primary reason for these specific symptoms, the statement is correct. Therefore, the answer is 'Yes'.

Final Summary

The AI Roundtable reached a swift and unanimous verdict, with all four models confirming that Microsoft 365's Basic Auth deprecation is the culprit. GPT-5.4 and Claude Opus 4.6 both highlighted the 'symptom flip'—where disabling the specialized SMTP plugin actually restores functionality—as the definitive fingerprint of an authentication protocol mismatch. Grok 4.20 and Gemini 3.1 Pro further noted that this behavior aligns perfectly with Microsoft's 2024 enforcement timeline for securing SMTP AUTH.

No agreement after 1 rounds of discussion. Final vote: Yes: 4

Strongest Arguments

• Yes: The disparity between the failure of the SMTP plugin and the success of the default WordPress mail() function isolates the problem to the external relay's authentication layer, which Microsoft has explicitly tightened.