失敗事例から学ぶTwilio SendGridの使い方 大量送信編
- 2019年3月20日
- by 菊田 洋一
- Category: ベストプラクティス
SendGridサポートエンジニアの菊田です。テクニカルサポートを担当していると様々な失敗事例を見かけます。その中には、事前に注意点さえ知っていれば回避できる失敗が数多くあります。
そこで今回は、過去にあった失敗事例をもとに、どこに注意して、どのような対策を取ればよかったのか？についてご紹介します。2部作の初回は「大量送信に関する失敗事例」編です。
事例1：長い年月をかけて獲得した大量の宛先がDBにあるので、その宛先に一斉配信したところ、メールが全然送れなくなってしまった！
長い間送信していない宛先は、既に存在しなくなっていたり、スパムトラップになっていたりする可能性があります。こうした宛先へ送信してしまうと、バウンスが大量に発生してアカウントが停止されたり、送信元IPアドレスがブラックリストに登録されたりして、メールが送信できなくなってしまうことがあります。
バウンスを防ぐための対策は次のとおりです。
対策：リストクリーニングを行う
一般的にハードバウンスの発生率は5%以下に抑えることが推奨されています。ハードバウンスを減らすには、事前に宛先リストをクリーニングして届かない可能性のある宛先を除外することが重要です。送信実績のない宛先や長い間メールを送っていない宛先がある場合、Email Address Validation API（Pro以上のプランで利用可）を使ってアドレスの有効性を検証しましょう。
次のような外部サービスを利用してクリーニングを行うことも可能です。
スパムトラップへの送信については次の方法で防ぎます。
対策：エンゲージメントの指標をチェックする
スパムトラップに送ったメールは、基本的に開封やクリックが発生しないため、たとえば、3ヶ月以上開封もクリックもしない宛先はスパムトラップの可能性があると判断して送信を止めるといった対策が有効です。メール送信を諦める条件を明確化して、Sunset Policyを定めましょう。
事例2：告知メールを早急に送る必要があり、Proプランを契約した直後に10万通送信したら遅延が大量に発生してしまった。急いでいるのに困る！
SendGridを使えばすぐに大量送信ができる、というのは誤った認識です。大量送信を成功させるには高いレピュテーションが必要なため、しっかり事前準備を行う必要があります。
対策：IPウォームアップを実施する
レピュテーションを高めるためにはIPウォームアップが必要です。SendGridが推奨しているIPウォームアップスケジュールでは、1日目に50通、2日目に100通、3日目に500通と徐々に送信通数を増やして様子をみながら送信します。IPウォームアップを実施してレピュテーションが高まれば、最終的には1日で10万通や100万通規模の送信が可能になります。
事例3：一斉送信後にお客さんからメールが届かないと問い合わせがありました。APIは正常応答を返していたのでActivityを確認したのですが、送信イベントが表示されませんでした。なぜですか？
Activityには表示期限があり、期限を過ぎたイベントデータは確認できなくなります。
対策：アドオンで保存期間を延長する
「Additional Email Activity History」アドオン（有料）を有効にすると、保存期間を30日間まで伸ばすことができます。イベントデータはエクスポートすることもできるので、定期的に保存しましょう。
対策：Event Webhookで送信イベントを保存する
30日より長くイベントデータを保存したい場合は、Event Webhookを使うことを推奨します。
この機能は、SendGridが外部に向けてイベント情報を通知する仕組みで、その通知を受信してデータベースやストレージへデータを保存できます。
Event Webhookの通知を受信するWebアプリケーションを自身で構築する他、様々な受信方法があります。次の記事などを参考にしてください。
事例4：大量送信のテストをするために、自分のGmailアドレスへ一斉送信したところメールが遅延しました。どのようにテストを進めれば良いのでしょうか？
通常、メールサーバには受信可能な通数に制限があるため、同一のメールアドレスへ大量送信すると受信拒否されることがあります。送信する側はテストのつもりであっても、それを受ける側は攻撃を受けていると判断してしまうためです。宛先にエイリアスアドレス（test+001@exampleのような形式のアドレス）を利用した場合も、実態としては同一のアドレスに対して送信していることに変わりないので、大量送信すべきではありません。
対策：大量メール送信テスト用の宛先を利用する
SendGridでは大量メール送信のテスト向けに「@sink.sendgrid.net」というドメインを用意しているので、是非ご利用ください。ローカルパートは自由な文字列を指定可能です（hoge@sink.sendgrid.netなど）。@sink.sendgrid.netには次の特徴があります。
- 受信通数に制限がない
- 正常応答を返す（ProcessedとDeliveredが発生する）
- 送信したメールは破棄される
テスト用に送信した場合でも課金対象となるので、ご注意ください。また、送信実績がない場合は事例2と同じように遅延が発生するため、突然の大量送信は避けてください。
事例5：メールが本当に送られているか確認するために、全メールにBccで自分の宛先を入れて送ったら、メールが遅延してしまったのですが…。
メールが遅延した原因は事例4と同じです。Bccで同じ宛先に大量送信しているため、受信拒否されることがあります。
対策：Deliveredイベントで確認する
Bccは、本来の宛先（To）へのメールのコピーを別途送信するものです。そのため、Bccの宛先にメールは届いているけれど、本来の宛先には受信拒否されて届かない、といったことが起こりえます。
Bccで送った宛先で受信が確認できたとしても、本来の宛先へメールが届いたかどうかは確認できないため、宛先への到達確認はActivityやEvent WebhookのDeliveredイベントで行いましょう。
以上、5つの失敗事例の紹介でした。これから大量送信される方は、是非事前の対策をしっかり取っていただければと思います。