SMTPの4xxと5xxが出たら、まず一時的な失敗か永続的な失敗かを、応答本文と発生段階を含めて確認します。4xxだからすぐ手動再送、5xxだから必ずアドレス削除、という単純なルールでは対応できません。送信サービスが再試行中かどうかを調べてから次の操作を決めてください。

最初に分ける条件

日本の店舗が注文確認を何度も手動で送り直すと、延期されていた分が後から重複して届くことがあります。通知の重複は問い合わせを増やすため、元の送信要求と再送要求を別の識別子で管理します。利用者へ説明する場合も、未着と再試行中の状態を混ぜないようにしましょう。

応答は、宛先の処理、接続、本文送信など、どこで返されたかによって読み方が変わります。サービスが付けた短いラベルだけでなく、元の応答と時刻を確認します。複数の宛先を含む送信では、一人の失敗を全員の失敗として扱わず、宛先単位の状態を取得します。

証拠を残す確認手順

再試行の期間や間隔はサービスの実装と現在の設定を確認します。規格の一般説明や他社の例を、自社サービスの保証された時間として案内しません。キューの確認権限がない担当者は、運用窓口へ識別子を渡し、処理が継続中か終わったかを確認してもらってください。

想定例として、発送通知の送信後に一時エラーが記録され、担当者が二回再送を押した状況を考えます。先にキューを調べれば、三つの要求が残っていることが分かるかもしれません。どれを継続・停止するかはサービスの管理手順で判断し、受信者へ同じ通知が複数届く可能性も整理します。

同じコードでも応答本文の説明が異なる場合があります。調査資料にはコードだけでなく、返された説明と確認した接続先も残してください。

確定した拒否でも、原因を示す本文を読みます。入力誤り、ポリシー、認証などで必要な対応は異なります。受信者のアドレスを変える前に登録情報を確認し、設定の問題なら送信側で直します。再確認が必要な場合も、根拠を残して必要な一通だけを検証する方が調査しやすくなります。

受信側が受理した後のフォルダー分類は、これらの応答だけでは分かりません。Inbox Checkの標本で未確認のメールを見つけた場合も、すぐに迷惑メールと呼ばず送信キューを確認してください。実配信の延期と標本の配置を別の欄にし、確認できない状態を成功や失敗へ無理に変換しないでください。

測定方法と対象の制約を読み、Inbox Checkのテスト対象を確認してください。標本結果は個々の実顧客への保証ではありません。