Go to Qiita Advent Calendar Top
LoginSignup
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@vivid_muimui

メール送信で遅延しないようにするためにウォームアップをどうするか

Posted at

この記事はなにか

レピュテーションが低いと、メール送信が遅延する可能性があります。
社内のシステムでメール送信で大量遅延が発生してしまってその時に調べたことのメモです。(社内向けに書いていたのを少し手直しだけしてそのまま出しています)
目新しいことはないと思いますが、基本的な重要ポイントは抑えられてるはずと思います。

※ この記事の内容の信憑性に関しては、ぜひ公式などのドキュメントを参照したりサポートに相談したりして、きちんと確かめてください。メール送信ってむずいので。
※ もし、間違っているなどのことがあったら教えて下さい :pray:

レピュテーションについて

https://support.SendGrid.kke.co.jp/hc/ja/articles/25050550861593

  • レピュテーションというのは、メール受信側がそれぞれ独自に送信元に対して判定する信頼度のようなもの
    • たとえば、 some-service.example.com から test @ gmail.com にメールを送る場合、 受信側のgmail.com のサーバーが some-service.example.com からのメールをどう評価するかというもの。
  • 具体的なイメージ的には、「このドメインからは1日にこれぐらいのメールが送られてきてもOK。これ以上送られてくるとスパムの可能性あるから弾く」という制限値があるイメージ。
    • あくまでイメージです。実際はもっと複雑に賢く判定されてると思います
  • レピュテーションが低いなかで多くのメールを送ってしまうと、受信側でメールを受け取る数を制限したり弾かれたりすることがあり、メール遅延や送信失敗につながる
  • メール受信側の実装・仕様に依存するので、対策としてこれをすればOKという確実なものはない
  • レピュテーションはメール受信側ごとに異なる
    • たとえば、gmailからのレピュテーションが高くても、yahooメールからのレピュテーションは低いということがありうる。

ドメインレピュテーションとIPレピュテーション

https://SendGrid.kke.co.jp/blog/?p=2115

  • レピュテーションにはドメインレピュテーションとIPレピュテーションの2つがある
    • たとえば some-service.example.com からメールを送るとして場合は以下
      • some-service.example.com というドメインに対するレピュテーション
      • 弊社では、SendGridを使っていて、実際メール送信時にはSendGridから割り当てられた固定IPから送信されるが、そのIPに対するレピュテーション
  • スパム判定されるのにどちらが重要視されているかは受信側の仕様による
  • 補足: どうして2つの判定の軸があるのかに関しては以下(以下に書いた理由だけでは当然ないですが、わかり易い例として)
    • たとえばIPレピュテーションだけあり、ドメインレピュテーションがない場合どう困るか
      • 1つのサーバーから大量のメールを送らなければいいので、サーバー/IPを大量に用意することで悪意あるスパムを送ることができてしまう( 参考: スノーシュースパム)
      • なので、IP関係なくドメイン軸での送信量も判定基準にいれることでスパムを弾けるようにする
    • たとえばドメインレピュテーションだけあり、IPレピュテーションがない場合どう困るか
      • 適当に大量のドメインを用意すれば1つのサーバーからスパムを送れてしまうことになる
      • なので、IPレピュテーションも判定基準に入れる

遅延せずメール送信をするにはどうすればいいか

  • 重要なのは「地道に送信量を増やす」「送信量に応じてIPを増やす」の2つ

    • 大規模メール送信になるとまた異なってくると思いますが、経験がないのでわからないです

  • レピュテーションが低い状態で大量に送ると遅延してしまう。なので、段階的に送信量を増やしていきレピュテーションを高めていく必要がある

    • この作業が「ウォームアップ」と呼ばれている

  • 送信スケジュール目安は以下を参照

  • 重要なのは、送信側から見たときの総送信量ではなく、受信側から見たときのメールの受信量

    • なので、たとえば、ウォームアップスケジュールに合わせて送信量増やしていきサービス全体で1日2000件送信できる状態になったとする。でも、このときに、これまで送信してなかった受信プロバイダ側に急に1000件とか送ってしまうと遅延する可能性がある(はず)

  • 1つのIPで大量にメール送りすぎても良くない。送信量が増えたらIPを増やすことも検討する

  • レピュテーションは一回上がりきればOKではない。継続的に送っておくのが大事

    • レピュテーションは1ヶ月ぐらいで落ちる可能性があるので
      • 1ヶ月間メール送らないとレピュテーションは落ちるらしい
    • 結局は、メール受信側の仕様次第

  • トランザクションメール(遅延したら困る)とマーケティングメール(遅延しても良い)で、ドメイン・送信IPを分ける

どうやって送信状況・レピュテーションを確認するか

  • 各受信プロバイダごとのIPレピュテーションを一覧する方法自体はないはず
  • 「送信実績を確認する」「プロバイダ用意してくれているツールを見る」 「サードパーティのサービスを利用する」のどれか
  • 「送信実績を確認する」

    • SendGridで送信している場合はStats, Mail Box Provider Stats, Activityなどで確認する

      • image.png

    • DatadogにSendGrid連携して送信量を確認する

      • https://docs.datadoghq.com/ja/integrations/SendGrid/
      • SendGridだと1ヶ月分ぐらいしか送信量のグラフが見れない。昨年の送信量とかを見たいことは全然あるのでDatadogに連携して見られるようにしておくのは大事
  • 「プロバイダ用意してくれているツールを見る」「サードパーティのサービスを利用する」については以下を参照

FAQ

https://SendGrid.kke.co.jp/blog/?p=15531

  • Q ウォームアップめんどくさい。1つのIPで大量に送れないなら、IPを大量に用意して送信すればいいのでは？
  • Q 社内で用意したメアドにメールを送りまくればウォームアップできる？
    • NO
    • 1つのメアドに対して大量にメール送ると、それ自体がスパム判定されレピュテーションが下がるリスクが有る
    • また、仮にウォームアップに多少寄与したとしても、その受信プロバイダでのレピュテーションが上がるだけで、ほかのプロバイダに対してはウォームアップができていないのであまり意味がない
  • Q スパイク(急激にメール送信量が跳ね上がる)するメールがあるが、遅延してもいいやつだけど、その場合はどうすればいい？IP分ければいい？
    • IPだけでなくドメインも分けて送るのであればOK
    • ドメインを分けないと、ドメインレピュテーションが下がってしまうので全体的に遅延するリスクが有る
  • Q システム上、どうしてもスパイクがあり、でも遅延してほしくないメールの場合どうすればいい？
    • 基本的には、どうにかウォームアップ頑張るしかない
    • 具体例
      • Q AWS SES からSendGridの移行したいんだけど?
        • 一気にすべてのメールを移行するのではなく、送信量の少ないメールから徐々に移行するなどで、徐々にウォームアップをする
      • Q BtoBサービスで「従業員にメールで一斉送信する」機能があり、送信量が従業員数に依存するからコントロールできないんだけど?
        • 事前に、対象者に「メアド確認のためのテスト配信」といってメールを送るなどしてどうにかウォームアップする
        • 忘れちゃいけないのは「送信側から見たときの総送信量ではなく、受信側から見たときのメールの受信量」である
          • たとえば、サービス全体で日常的に1万件を送っているから、ある企業で従業員1万人に一斉通知が可能かと言ったらYESではない
          • 実際その人達に遅延なく送れるかはその受信プロバイダのレピュテーションに依存する
          • なので、「メアド確認のためのテスト配信」というような形で本人たちにちゃんと送ってウォームアップすることが重要
        • 補足: 安否確認サービスとかが定期的に「確認メールです。対応不要です」みたいなメール送ってくるのはこれ目的の面もありそうですね
          • 勝手な推測です。実際の理由はわかっていないです
      • Q 「あけおめメール」のような超スパイクがあるんだけど?
        • たとえば、そのメールに関しては最悪遅延してもよいのであれば、その時だけ共有IPを使って送信するというのは対策の1つとしてはありのハズ。たぶん。サポートなどに相談はしたほうが確実
  • Q スパイク対策として、社内の別サービスが大量にメール送信しているから、同じIPで送信すれば対策になる？
    • 確実にYESとは言えないが可能性はある
    • 補足:
      • 個人的には、各サービスでウォームアップ頑張るぐらいであれば、相乗りしあって全体でIPレピュテーションを高めまくるほうがスパイク耐性はあるのではないかとは思う。(保証はできないけど。)
      • ただし、問題起きたときは全体が影響受ける可能性あるのでそのリスクはある
  • Q SendGridに「自動IPウォームアップ」という機能あるけど、これはウォームアップに使える？
  • Q 固定IPは何個がよい？
  • Q 固定IPと共有IPどちらがいい？

この記事には書いていないこと

  • Domain Authentication(SPF/DKIM/DMARC)などいろんな設定
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?