2026 Gmail SMTP 535 5.7.80 はどう切り分ける？

今週の切り分けでは、535 5.7.80をGmail SMTPによる認証拒否として扱い、まず実際の認証方式と対応する資格情報を照合してください。この応答だけではパスワード間違いと断定できません。認証が直った後も、メールの送信受理とテスト宛先での実受信を別々に確かめます。

Gmail SMTPの認証エラーで、自社のテストプログラムが止まっている開発者向けです。
メールの回帰試験を担当し、認証と受信の証拠を分けたいQAにも役立ちます。
テスト環境の設定を直しつつ、認証情報をログに残したくない独立開発者も対象です。

535 5.7.80が示す範囲

この応答が返ったなら、SMTPの認証処理でサーバーが現在の認証を受け付けなかったと判断します。GoogleはSMTPエラーの説明で、535 5.7.80をユーザー名とパスワードが受け入れられない場合に対応づけています。

ただし、エラー文だけで「入力したパスワードが間違っている」と決めるのは早計です。実際にクライアントが選んだ認証方式や、送信した資格情報が期待どおりかは、アプリケーション側の設定・実行内容と照合する必要があります。

また、この段階の応答は、メールが迷惑メールに分類された、受信トレイに見当たらない、という状態を示すものではありません。認証前後のどこで失敗したのかを確認し、配信や受信の調査とは切り離します。RFC 4954のSMTP AUTH応答は認証の成功・失敗を扱う一般仕様であり、特定のGoogleアカウントで拒否された理由までは決めません。

認証方式と資格情報の照合

Gmail SMTPではOAuth 2.0認証とSASL XOAUTH2が利用できます。まず、設定ファイルに書かれた方式ではなく、問題が起きた実行環境でクライアントが実際に使ったAUTH方式を確認してください。GoogleのSMTP資料とXOAUTH2の仕様説明を、構成の照合に使えます。

OAuth 2.0を使う構成なら、次の点を順に確認します。

• SMTP認証に渡しているユーザーのメールアドレスと、トークンを取得したアカウントが一致しているか。
• クライアントがXOAUTH2を選択し、Bearerトークンをその認証方式に沿って渡しているか。
• 今回の接続で必要な権限が認可されているか、トークンがその認証処理に使える状態か。
• SMTPサーバーから返った応答の原文と、その直前に実行した認証処理を記録できているか。

トークンが有効そうに見えても、アカウントの対応関係や認証データの組み立てが正しいとは限りません。逆に、似た文言の別の応答を見つけても、それを今回の535 5.7.80の原因と決めつけないでください。GoogleのOAuth 2.0資料を参照し、許可範囲やトークンの扱いを実装と照らし合わせます。

接続確立とAUTH失敗の切り分け

SMTPホスト、暗号化接続の方式、AUTH機構は、個別に確認します。Gmailの接続資料に照らして、自社の実行環境が想定した接続先とTLSの開始方法を使っているかを調べてください。固定のポート番号や特定ライブラリの版を前提にせず、実際の構成を記録するのが安全です。

TLSが確立する前に接続が切れた場合と、SMTPがAUTH処理まで進んで535を返した場合は、障害の段階が異なります。クライアントのデバッグログでは、接続確立、暗号化開始、AUTH実行、サーバー応答を順に追います。ただし、認証情報やトークンを含む行はそのまま保存・共有しないでください。

ログや画面共有には、アクセストークン、パスワード、完全な確認リンクを含めないでください。原因調査に必要なAUTH方式、処理段階、応答文だけを残し、秘密情報は伏せます。

試験環境での分岐判断

次の条件で、確認する対象を選びます。

• クライアントがOAuth 2.0とXOAUTH2を使う想定なのに、実行ログで別のAUTH方式を確認した場合：まず実行時設定を修正します。トークンの再取得を繰り返す前に、認証方式が反映されているか再確認します。
• XOAUTH2が実行されている場合：認証対象のメールアドレス、トークンのアカウント、権限、Bearerトークンの渡し方を照合します。問題が残れば、応答原文と機密情報を除いた接続記録を比較します。
• AUTH開始前に接続またはTLSで失敗している場合：認証情報の変更ではなく、接続先とTLSの開始方法を確認します。
• AUTHが成功した場合：認証調査を終えたとせず、自社製品からテストメールを送り、送信の受理と受信を確認します。

たとえば、開発環境では送信できていたのに、QA環境だけ535が返るケースでは、アカウントのパスワードを変更する前に、環境ごとの実行設定とAUTH方式を比較します。認証後の試験では、今回の実行を識別できる件名などを付け、管理下のテスト宛先で到着を確かめます。

認証・送信受理・実受信の記録

試験結果は一つの「メール送信成功」にまとめず、段階ごとに記録します。SMTPサーバーがメッセージを受理したことと、宛先で実際に読める状態になったことは同じではありません。RFC 5321のSMTP仕様でも、受理後の配送は別の処理として扱われます。

最終記録には、エラーの原文、発生段階、実際の認証方式、機密情報を除いたテスト識別情報を残します。結論も「この試験環境で認証が成功した」「この送信がサーバーに受理された」「今回のテスト宛先で受信を確認した」と分ければ、何を確かめたのかが明確になります。

よくある確認事項

Gmail SMTPの535 5.7.80は、何を意味しますか？
Gmail SMTPが現在の認証を受け付けなかった応答です。Googleの説明ではユーザー名とパスワードが受け入れられない場合に対応しますが、原因を入力ミスだけに限定するものではありません。今回のクライアントが実行したAUTH方式と、方式に対応する資格情報を確認します。

自社アプリがOAuth 2.0を使っているか、どこで確認しますか？
設定画面だけで判断せず、問題が起きた実行環境のクライアント設定とSMTP認証の記録を確認します。OAuth 2.0を使う構成では、Gmail SMTPの認証方式としてSASL XOAUTH2が関係します。認証方式や処理段階は記録し、トークン自体はログに残さないでください。

OAuthトークンが有効でも、SMTP認証に失敗する場合は？
トークンの状態だけで原因を断定せず、トークンのアカウントと認証対象のメールアドレス、認可された権限、XOAUTH2での渡し方を確認します。似たエラー文を同じ原因とみなさず、実際のSMTP応答と自社クライアントの構成を合わせて調べます。

認証後、テストメールが届いたことをどう確かめますか？
認証の成功、SMTPサーバーによる送信受理、管理下のテスト宛先での受信を別々に記録します。受信側では受信トレイだけでなく迷惑メールなども確認してください。受理応答だけでは、宛先への到着や分類まで証明できません。

テスト宛先で受信を確かめる

認証を修正したら、次は自社製品から送ったメールを、管理できるテスト宛先で確認します。受信先の使い分けは一時受信箱の案内を確認し、試験に合う条件かを判断してください。個人情報を試験データに混ぜないための考え方は、プライバシーに関する案内も参考になります。

認証段階の記録と、実際に受信したかどうかの記録を分けておけば、次に失敗したときも調査対象を絞れます。短期の登録フロー確認や検証メールの受信には一時受信先も選択肢になりますが、長期保管や返信、重要アカウントの復旧には継続して管理できるメールアドレスを使ってください。SendTmpをテストに使う場合も、受信条件を確認したうえで、実際のテストメールが届いたかを個別に判定します。