451 4.7.650。内容は「IP reputation を理由に一時的に rate limit した」というもの元記事は、Microsoft系メールアドレスにだけメールが届かなくなったというトラブルの記録です。
ここでいう Microsoft 系とは、Hotmail、Live、MSN、Outlook など。昔からあるメールサービスですね。
筆者のサービスでは、月に約35万通のメールを送っていて、そのうち約3.9万通はログイン通知、請求、パスワード再設定のようなtransactional emailでした。
transactional email というのは、ニュースレターみたいな一斉配信ではなく、ユーザーの操作に反応して送るメールのことです。遅れると普通に困ります。かなり重要です。
ところがある日、SendGrid のログを見ると、Microsoft宛てのメールだけが Deferred になっていました。
Deferred は、ざっくり言うと「今は受け取れないので後でまた試してね」です。
完全拒否ではないけれど、実質かなり困る状態です。
しかも理由がこれです。
451 4.7.650 ... temporarily rate limited due to IP reputation
直訳っぽく言うと、
「あなたのIPアドレスの評判が理由で、一時的に送信速度を制限しました」
ということです。
ここ、かなりイヤな感じです。
なぜなら筆者側から見ると、何も設定を変えていないのに急に止められたように見えるからです。
筆者はまず、SendGrid のログ、Gmail Postmaster Tools、SPF / DKIM / DMARC などを確認しています。
ここで出てくる用語を軽く補足すると：
結果として、筆者側の指標はどれも大きく悪くなかったそうです。
そのため、最初は「Microsoftが一時的に誤判定しているのでは」と考えたわけです。
この判断、かなり自然だと思います。
自分の設定や実績に問題がないなら、まず相手側を疑いたくなりますよね。
筆者が調べていくと、Microsoft は Gmail などと比べてかなり厳しめに送信元を評価する傾向があるとわかってきます。
しかも、rate limited という文言は、単なるIP評判だけでなく、短時間にメールが急増したことでも起こりうる。
ここがこの記事の面白いところです。
「IP reputation が悪いから止められた」と思っていたら、実は
“急にたくさん送ったから怪しい” と見なされた可能性があるわけです。
筆者はここで、週次ニュースレターの配信方法に注目します。
これ、実はかなりありがちな設計です。
人間からすると「4日に分散してるから大丈夫でしょ」と思うのですが、受信側から見ると、1分間だけドカッと増えるのは十分に怪しい。
メール配信の世界って、こういう“見え方の違い”が地味に怖いんですよね。
筆者は、Microsoft宛てに送ろうとしたメール数を分単位で集計するSQLを書いています。
その結果、問題の直前に 1分あたり53通 という山があったことがわかりました。
しかもそれ以前、同じ規模の送信があったのはかなり前。
つまり、Microsoft側から見ると「急に増えた」と判断されてもおかしくない状況だった、というわけです。
ここはとても重要で、
送信総量が多いかどうかよりも、
短時間にどう見えるか
のほうが効くことがある、という話です。
メール配信って、総量だけ見て安心しがちですが、受信側は「今この瞬間の振る舞い」を見ています。
人間関係と似ています。急に大量に連絡してくる相手は、ちょっと警戒しますよね。あれです。
筆者は、原因の完全特定を待つのをやめて、Microsoft宛てのメールだけ送信速度を制御する仕組みを作ります。
使ったのは Redis。
Redis は、超ざっくり言うと高速なメモ帳兼カウンターのようなものです。
「今この時間帯に何通送ったか」を覚えておくのに向いています。
実装の考え方はシンプルです。
元記事では、Microsoft 宛てなら 1 IP あたり毎分 10通 に抑えるようにしています。
このくらいの制限だと、ユーザー体験への影響はほぼなく、数秒の遅延に収まるとのことです。
個人的には、この対応はとても現実的だと思います。
「相手の問題かもしれない」と思っても、ビジネスとしては自分側で緩和策を入れるのが強いです。
原因究明と対症療法を同時に進めるのが、実務ではいちばん健全なんですよね。
その後、筆者は Microsoft のサポートポータルに問い合わせを出します。
SendGrid のログなども添えて、できるだけ状況が伝わるようにしたそうです。
すると、少しして Microsoft 側の人間から返答が来ます。
接続と throttling の制限は、あなたのIPの評判に基づいて、より適切なレベルに設定した
要するに、制限を調整したということです。
これでしばらくすると、Hotmail / Live / MSN / Outlook 宛てのメールが再び配信され始めました。
しかも、開始から 72 時間以内に解決しているので、メールが完全に失われたわけではなく、遅延していただけだったようです。
ここはホッとするところです。
メール配送トラブルって、放っておくと「届いていない」ではなく「どこで消えたかわからない」になりがちなので、72時間以内に回復したのはかなり救いがあります。
筆者の考えでは、こうです。
つまり、Microsoftの判定が厳しすぎた可能性はあるが、送信側にも改善余地があったという結論です。
このバランス感覚がいいですね。
「相手が悪い」で終わらず、かといって「全部自分が悪い」とも言い切らない。
実際の運用トラブルって、たいていこの中間にあります。
配信システムは、APIを叩いて終わりではありません。
受信側にどう見えるか、どんなタイミングで届くかまで含めて設計しないといけないです。
元記事でも触れられていますが、Microsoft は Gmail より敏感に見えることがあるようです。
もちろん全ケースではないですが、配信速度の急変には注意したほうがよさそうです。
筆者が SQL で直前の送信量を見たことで、「スパイクだったかも」という仮説にたどり着けました。
こういうとき、感覚ではなく数字を見るのが強いです。
地味ですが、実務ではこういう地味な武器が効きます。
SendGrid は優秀だけど、完全におまかせだと Microsoft 側の制限に巻き込まれることがある。
だからこそ、自前でレート制限を持つのはかなり賢い判断だと思います。
この記事、かなり好きです。
単なる障害報告ではなく、「相手の問題っぽいけど、自分でもコントロールできる部分を作る」という流れがすごく実践的だからです。
しかも、最後にちゃんと送信制御を入れて終わるのがいい。
“原因は完全にはわからないけど、再発しにくくした”という着地は、現場の解像度が高い証拠だと思います。
メール配信の世界って、一見地味ですが、こういう綱引きが本当に難しい。
今回の件は、その難しさがかなりよく伝わる事例でした。