2026 Google Workspace SMTP Relayのテストメールが拒否されたらどうする？
Google Workspace SMTP Relayで自社製品のテストメールが拒否されたとき、まずSMTP応答から中継の成否を判断します。送信元IP、認証、送信者情報を確認し、受け付け後はログと受信箱で実着信を確かめる手順を紹介します。
「送信成功」と表示されたのに受信箱にメールがない、または中継サーバーから拒否応答が返る。
まずSMTP応答で中継がメールを受け付けたかを判定し、拒否なら送信元IP、許可された送信者、認証方式、HELO/EHLOの順に確認します。受け付け後は、受信側の記録で到着を確かめます。中継の受け付けは、受信箱への到着を意味しません。
この記事は、自社製品の通知や確認メールをGoogle Workspace SMTP Relayで送る開発者、QAエンジニア向けです。
プレリリース環境のメール回帰テストや、Workspaceの中継ルール・ネットワーク出口を管理する担当者にも役立ちます。
SMTPの拒否と受信箱にメールがない状態を分ける
「メールが届かない」という症状だけでは、原因を特定できません。アプリからの送信要求が失敗したのか、中継が明示的に拒否したのか、それとも中継後に受信箱で見つからないのかを分けて記録します。
RFC 5321では、SMTPサーバーがメッセージを受け付けた後の250応答は、そのサーバーが後続の配送を引き受けたことを示します。これは、宛先の受信サービスへの配送や、ユーザーが読める受信箱への分類まで保証するものではありません。
| 状況 | まず確認する証拠 | 判断の目安 |
|---|---|---|
| SMTP接続・認証の失敗 | 接続先、TLS交渉、SMTP応答の有無 | まだ中継へのメール提出が完了していない可能性があります |
| 中継から拒否された | 応答コードとエラーメッセージ、ルール、送信ログ | IP、送信者、認証方式などの不一致を調べます |
| 中継が受け付けたが見つからない | 受信側ログ、宛先、迷惑メールなどの分類 | 中継後の配送と受信側の表示を調べます |
アプリの画面にある「送信成功」だけで判定せず、実行ごとの識別用文字列、宛先、送信時刻、SMTP応答をひとまとめにします。テストごとに関連付けられる記録があれば、再送による重複と別の実行結果を取り違えにくくなります。
「relay denied」ではSMTP応答とルールを照合する
Google Workspace SMTP Relayでrelay deniedに類する拒否が出たら、エラー全文とSMTP応答を保存し、現在の中継ルールと照合します。Googleの中継設定に関する公式説明では、接続元IPや送信者の扱い、認証などがルールと関連する設定項目として説明されています。実際に有効な条件は対象アカウントのルールで確認してください。
登録した送信元IPと実際の出口が一致していますか？
IPを登録済みでも拒否されるときは、登録画面の値だけでなく、その送信試行がSMTP接続に使った実際のグローバルIPを確認します。開発環境、プレリリース環境、CI環境で出口が異なる場合、ひとつの環境での確認結果を別環境に当てはめることはできません。
GoogleのSMTPエラーコードの説明も参照し、応答がIPの未登録、アカウントのドメインとの不一致、中継ルールの不適合を示していないかを確かめます。エラー文だけで原因を決めつけず、対象のルールと同じ実行の送信ログを合わせて読みます。
送信者、認証方式、HELO/EHLOの組み合わせを確認する
IPによる確認とSMTP AUTHは別の設定経路です。片方の方式に必要な条件や認証情報を、もう片方にそのまま当てはめないでください。Workspaceの中継ルールで許可されている送信者の種類を確認し、メールのFrom、SMTPセッションで使う認証情報、MAIL FROMがその条件と合っているかを見ます。
あわせて、送信プログラムが提示するHELOまたはEHLOの識別情報が、利用中のルールで認識されるものか確認します。ここは環境やルールに依存するため、一律の値を想定せず、拒否応答と自社の現在の設定に基づいて判断します。
接続やTLSの段階で止まる場合は提出前の記録を見る
TCP接続ができても、メールがSMTPサーバーに提出されたとは限りません。接続先ホスト名、利用ポート、TLSまたはSTARTTLSの交渉、サーバーからのSMTP応答をログで追い、接続・認証・ポリシー拒否を別々の状態として記録します。
設定値は、Google Workspaceの中継設定にある最新の案内と照合してください。異なる環境で同じ接続結果になるとは限らないため、タイムアウトを隠すような再送を繰り返す前に、どの段階で止まったかを特定します。
SMTP応答が記録されていない場合は、「中継に拒否された」とはまだ断定できません。アプリの送信処理、ネットワーク接続、TLS交渉のどこまで進んだかを先に分けてください。
中継が受け付けたのに受信箱で見つからない場合
送信ログに受け付けを示す応答があれば、次は宛先の入力間違い、後続の配送状況、迷惑メールなど受信側の分類を調べます。Google Workspaceのメールログ検索の案内を使える環境では、送信者と受信者に対応する記録を探し、アプリ側ログと同じテスト実行か確認します。
受信箱だけでなく、迷惑メールなどの別分類や、受信側で確認できる原本情報も調べます。迷惑メール判定や不審な配送の調査には、GoogleのSMTP Relayに関する迷惑メール・不正利用の説明も参照できます。中継が受け付けたこと、受信サービスに配送されたこと、利用者がメールを読めることは、別々の確認結果として残しましょう。
受信確認メールの見落としが疑われる場合は、登録確認メールが届かないときの確認ポイントも参考になります。自社サービスのテストでは、宛先を正しく記録し、受信側の結果を送信ログと照らし合わせるのが大切です。
自社製品のメールテストを受信証拠まで閉じる
同じ実行をたどれるよう、次の手順で記録をそろえます。
- 自社アプリまたは許可されたテスト環境から、内容を識別できるテストメールを送ります。
- テスト実行の識別子、送信元、宛先、送信時刻を記録します。ログに個人情報や認証情報を不用意に残さないようにします。
- SMTP接続先、TLS交渉、認証方式、サーバー応答を取得し、接続失敗と中継拒否を区別します。
- 中継が拒否した場合は、実際の出口IP、許可された送信者、認証方式、
HELO/EHLOとMAIL FROMを現在のルールに照らして確認します。 - 受け付けられた場合は、受信側のメール記録や受信箱を調べます。迷惑メールなど別の分類も確認し、送信側と受信側の記録が同じ実行を示すか照合します。
- メール本文、宛先、確認リンクや通知後のアプリ動作を検証し、必要なログは個人情報を伏せて保存します。
これにより、「SMTP中継が受け付けた」「受信側で確認できた」「アプリの確認リンクや通知処理が完了した」を別々に判定できます。受信できたかを確かめる前に、画面上の成功表示だけでテストを合格にしないでください。
テスト先を選ぶときの判断基準
一時的な受信先は、開発・検証用メールを個人や業務の主メールアドレスから分ける選択肢です。一方、実運用アカウントや長期の復旧が必要なアカウントでは、継続して受信・返信できる管理下のアドレスを選びます。
- 一時受信先：自社製品の短期テストや、主メールアドレスをテストデータに含めたくない場合に検討します。受信可能な条件や保持に関する情報は、利用するサービスの案内で確認します。
- 主メールアドレスや管理下の別名アドレス：継続的な受信、返信、アカウント復旧が必要なテストに向きます。テスト用アドレスを本番データと混在させない運用が必要です。
テスト用データに実在の個人情報を混ぜない考え方は、RelayTmpのプライバシーに関する案内も確認できます。ログのマスキングやテスト宛先の管理方法は、自社の情報管理ルールに合わせてください。
中継ルールの確認を終えた後、受信側で確認できるかを試すための一時受信先が必要なら、RelayTmpも検証方法の一つとして検討できます。主メールアドレスをテスト用の宛先として公開せずに済みますが、利用前にサービス上の受信条件を確認し、重要なアカウントや長期保管が必要なメールには継続管理できる受信先を使ってください。
使い捨て受信トレイを開く
開くだけでコピー可能な使い捨てメールアドレスを取得でき、同じページで実際のテストメールを更新・閲覧できます。