アプリからメールが送られなくなったのはなぜか

自分のログではなく、事業者のログから見る

この障害がやっかいなのは、どこも壊れて見えないことです。コードは動き、送信関数は戻り、例外も出ず、自分のログにはメールが出ていったと残っています。なぜなら、アプリのログは自分のコードが何をしようと決めたかを記録し、事業者のログはそのメールに何が起きたかを記録するからです。両者が食い違ったときは、事業者のほうが正しい。事業者のアクティビティ画面を開き、送信が止まった時間帯で絞り込んでください。たいていは、ある時刻以降が無音になっているか、理由付きの拒否が並んでいるかのどちらかです。前者はコードが呼ぶのをやめたということ、後者は呼んだうえで断られたということです。

コードを変える前、API キーを回す前、何かを再送する前に、まずそれをやってください。どれも診断を難しくしますし、そのうち一つは事態を悪化させます。送信量ですでにフラグが立っているアカウントに再送を一気にかけるのは、一時的な停止を恒久的な停止に変える古典的な手口です。

送信を実際に止める4つの原因

答えになる頻度の高い順に、おおよそ次のとおりです。

• 成長して到達したプランの上限 日次・月次の送信上限が最も多い原因で、いちばん理不尽に感じられます。システムは何も変わっておらず、変わったのは登録数だからです。上限はどこにでもある火曜の朝に越えられ、落とされるのは最後にキューへ入ったもの、つまり朝に送られるログインメールではなく、通知やライフサイクルのメールであることが普通です。
• 事業者による一時停止 事業者は送信量の急変、しきい値を超えるハードバウンス率、迷惑メール報告を理由にアカウントを止めます。これについては警告メールが届くのが普通ですが、宛先はアカウント作成時に登録されていたアドレスであり、小さなチームではもう誰の受信箱でもないことがよくあります。
• 壊れたドメイン認証 SPF、DKIM、DMARC のレコードは DNS にあるので、DNS が変わると壊れます。レジストラの移管、追記ではなく置換になってしまったレコード、期限切れの確認、ローテートした署名鍵。これは止まる前に劣化します。まず特定のメールボックス事業者への配信が失敗し、次にバウンス率が上がり、そして停止が来ます。
• 自分のコードが呼ばなくなった ある環境だけ欠けている環境変数、静かに死んだキューのワーカー、デプロイ後に切れたままのフィーチャーフラグ、必須項目が変わった SDK の更新。事業者のログが拒否ではなく無音を示しているなら分岐はこちらで、答えは事業者のダッシュボードではなく自分のデプロイ履歴にあります。

ステータスコードではなく、ボディを読む

10分で終わるはずの障害を3日に変えるのがこれで、私たち自身も自社システムで一度ならず同じ間違いをしています。拒否された呼び出しは、必ずしもエラーとして届きません。HTTP 200 のレスポンスボディの中に失敗が入って届き、ステータスコードだけを見るコードはそれを成功として記録します。まったく同じ形に複数の事業者で遭遇しました。ある事業者はトークンに権限が足りないとき、200 のボディに false の成功フラグを入れて返します。別の事業者は SNS への投稿を受け付けたうえでボディに検証エラーを返し、封筒だけを読んでいた私たちのシステムはそれを投稿済みとして記録し、顧客にもそう伝えました。実際には何も投稿されていませんでした。

そこから出てきた規則は短く、メールにもそのまま当てはまります。事業者が受理したとレスポンスボディが言ったときにだけ送信を成功とみなすこと、受理しなかったときは事業者自身の理由文字列を記録すること、そして自分で要約した文言ではなくその文字列に対してアラートを出すこと。ステータス行が語るのは API との会話です。ボディが語るのはメールそのものです。

同じ規律がレート制限にも効きます。429 を返す事業者は、有用で一時的な情報を伝えています。バックオフのないコードはそれを恒久的な損失に変えます。メッセージは捨てられ、二度と再送されないからです。私たちもそのバックオフなしで走った期間が必要以上に長く、最終的に問題を表に出したのはアラートではありませんでした。誰かが見に行ったことでした。

次の一回は騒がしくする

意味のある対処は上限を引き上げることではなく、到達する前に気づくことです。そしてアラートは件数ではなく比率に対して置きます。「本日分の枠を14時までに80%使いました」は行動できますが、「100通送りました」はプランが変わった瞬間に何の意味も持たなくなります。私たち自身の送信量も、登録数が伸びるにつれて1日100通を越えました。無料プランの上限はちょうど100通。ようやく見に行った日でおよそ107通、その週の前半には100分の99まで来ていました。システムのどこもひと言も言いませんでした。プランの引き上げは簡単なほうの半分です。自分たちに借りたままだったアラートが重要なほうの半分で、それが欠けていた理由は、上限がそれまで一度も近づいたことがなく、誰もそれを動く数字として考えていなかったからです。

ついでにやっておく価値のあることがもう二つあります。ログインを運ぶメールが届かなかったときのために、アカウントへの二つめの入り口を用意しておくこと。理由は マジックリンクのログインが失敗する理由 に書いたとおりです。そして、ログインや領収を運ぶメールと、キャンペーンを運ぶメールを分けること。最低でも送信ドメインで、できれば事業者ごとに分けます。そうすれば苦情のしきい値を踏んだキャンペーン配信が、パスワード再設定まで道連れにすることはありません。どちらの流れに何を入れるかは ライフサイクルメールの組み立て方 で扱っています。AgentCeres、agentceres.com の AI Growth Officer を作る中で、優先順位は高い授業料を払って学びました。顧客が実際に求めたメッセージこそ、最初に守るものです。