失敗事例から学ぶSendGridの使い方 大量送信編

SendGridサポートエンジニアの菊田です。テクニカルサポートを担当していると様々な失敗事例を見かけます。その中には、事前に注意点さえ知っていれば回避できる失敗が数多くあります。そこで今回のブログでは、過去にあった失敗事例をもとに、どこに注意して、どのような対策を取ればよかったのか？についてご紹介します。ブログは2回に分けて、初回は「大量送信に関する失敗事例」をご紹介します。

事例1：長い年月をかけて獲得した大量の宛先がDBにあるので、その宛先に一斉配信したところ、メールが全然送れなくなってしまった！

長い間送信していない宛先は、既に存在しなくなっていたり、スパムトラップになっていたりする可能性があります。こうした宛先へ送信してしまうと、バウンスが大量に発生してアカウントが停止されたり、送信元IPアドレスがブラックリストに登録されたりして、メールが送信できなくなってしまうことがあります。

バウンスを防ぐための対策は次のとおりです。

対策：リストクリーニングを行う

一般的にハードバウンスの発生率は2%以下に抑えることが推奨されています。ハードバウンスを減らすには事前に宛先リストをクリーニングして、届かない可能性のある宛先を除外することが重要です。送信実績のない宛先へ送る場合や長い間メールを送っていない宛先を使用する場合は、次のようなサービスを利用して事前に必ずリストクリーニングを実施してください。

• 宛先リストクリーニングサービス「BriteVerify」を試してみました
• Kickboxでマーケティングキャンペーンの宛先をチェックする

スパムトラップへの送信は次の方法で防ぎます。

対策：エンゲージメントの指標をチェックする

スパムトラップに送信した場合、開封やクリックは発生しないため、たとえば、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画面に表示される送信イベントは保存期間が7日間という制限事項があるため、それを過ぎると確認できません。

対策：Event Webhookで送信イベントを保存する

Event WebhookはSendGridが外部に向けてイベント情報を通知する仕組みで、その通知を受信してデータベースやストレージへデータを保存できます。Activityの制限事項を回避できるので、運用の際には必ず設定しましょう。

Event Webhookの通知を受信するWebアプリケーションを構築しても良いのですが、他にも様々な受信方法が考えられるので、次の記事などを参考にしてください。

• Amazon DynamoDBにEvent Webhookのイベントデータを保存する方法
• Azure FunctionsでEvent Webhookデータを受信する
• SendGridのイベントデータをMongoDBにストアする方法

事例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は本来の宛先へのメールのコピーを別途送信する挙動のため、Bccで送った宛先にメールは届いているけど、本来の宛先から受信拒否されて届いていない、といったことが起こりえます。このため、Bccで送った宛先で受信が確認できても、本来の宛先へメールが届いたかどうかは確認できません。送信通数を無駄に増やしてしまうだけなので、宛先への到達確認はActivityやEvent WebhookのDeliveredイベントで確認しましょう。

以上、5つの失敗事例の紹介でした。これから大量送信される方でいずれかに該当する方は、是非事前の対策をしっかり取っていただければと思います。