SendGridのDeliveredは、相手側への配送に関するイベントであり、受信者の画面の受信箱位置を保証しません。見つからない場合はProcessedから後続イベントまでを同じメッセージ識別子で追い、受信者側のフォルダーと時刻を照合します。APIの成功だけをDeliveredと呼ばないでください。
対象と設定を確認する
国内の店舗がSendGrid経由で予約確認とニュースレターを送る場合、カテゴリやアプリの識別子を使い、どの通知を調べているかを明確にします。件名が共通でもイベントは別の場合があります。複数の宛先へ送った要求では、宛先ごとの状態を確認し、一人の配信結果を全体へ広げないようにしましょう。
公式のEvent Webhook説明は、Processed、Delivered、Deferred、Dropped、Bounceなどを区別しています。Deferredは延期であり、その時点で最終的な失敗と確定したわけではありません。Droppedも受信側の迷惑メール入りとは別の状態です。イベント名だけでなく、取得した理由や応答を一緒に保存してください。
切り分けの手順
- 同じメッセージと宛先のイベントを時系列で並べる。
- 延期・抑止・拒否・配信と理由を区別する。
- 再試行中か確認してから手動再送を判断する。
- 原文の認証と受信場所を記録し、イベント名と分ける。
再試行の扱いは公式の現在の説明と実際の記録で確認します。延期中にアプリから何度も再送すると、後で同じ通知が複数届く可能性があります。イベントを受け取る仕組みで重複記録がある場合も、送信そのものの重複と区別し、識別子を基に時系列を整理します。
想定例と運用の注意
想定例として、発送メールが未着と報告され、ログにDeferred、その後にDeliveredがあった場合を考えます。報告時点と最終イベントの時刻を比較すると、遅延中に問い合わせが来たことが分かるかもしれません。受信箱での確認はそれとは別に行い、最初の未確認状態を後から消さずに追記します。
送信ドメインの認証を変更した場合は、同じアプリから新しい通知を作り、原文の署名を確認します。SendGridの管理画面で設定を終えたことと、実際の経路で使われたことは別です。古い通知の結果や、スタッフの個人メールの成功を代用しないようにしてください。
Inbox Checkの標本で良好な配置が見えても、特定顧客の個人ルールや企業ゲートウェイは再現していません。日本向けのYahoo! JAPANや携帯メールを測ったかは対象一覧で確認が必要です。Delivered、認証結果、観察した配置を別欄にし、対応が不明なサービスを測定済みとして報告しないでください。
公式情報
Twilio：SendGridのイベント。Twilio：SendGridの延期。
観測方法と限界を確認し、Inbox Checkで対象を選択してください。実際に測定できた標本と未確認の範囲を分けて報告します。