はじめに

メール配信サービスの移行をしたので、調べた事や意識した事など残しておこうと思います。
メール周りは運用していくにあたってインボックスプロパイダにより独自のレピュテーション基準があったり、配信サービスとしてもバウンス・ブロック等様々な判定基準がバラバラであったりするためより良い仕組みを構築しようとするのには難しさを感じます。
それ故敬遠しており、普段メール周りの監視項目などもあまり意識をせず（良くない😣）保守運用をしてしまっていたので、学びの多い開発になりました。
どこかで誰かの参考になれば嬉しく思います。

背景

昨年、Googleが発表したメール送信者ガイドラインを受け、認証まわりの見直しと、より良い運用・保守性を求めてメールサービスの変更を決定しました。

主な変更点

これまで

• DKIM認証：OpenDKIM
• DMARC認証：OpenDmarc
• メールサーバ：EC2でPostfixを構築
• リレーサービス：ベアメール
• メール送信：CakePHPのMailerでMTAホストへメールの送信

これから

• SPF認証 / DKIM認証 / DMARC認証：SendGridでDomain Authenticationを設定し、AWS Route53でのレコード設定
• メール送信：SDKを利用し、SendGridのWebAPI V3を実行

感じていた課題点

認証

メールサーバを管理しMTAの構築やDKIMの認証設定を自らしていたので、アプリケーションの変更が認証結果にも影響を及ぼす可能性があり把握しておく必要がありました。設定にも落とし穴があり、運用・保守・開発とそれぞれしっかりと意識していないといけない状態となります。

例えばMTA側で改行コードやテンプレートの変換をしてしまい、メールハッシュ値が変わることによりDKIM認証がFAIL（body hash did not verify）となる可能性があります。
バージョンにもよりますが、sendmail_fix_line_endingsの設定等で回避しなければいけなかったりします。

構成

IPアドレスのレピュテーションを守る（というか捨てられるようにする、、、）ためにリレーサービスを利用していましたが、その構成自体が冗長なものとなってしまっていました。
メールのトラブルが発生した際にも、アプリケーションサーバ、メールサーバ、リレーサーバとサービスを切り分けて調査していく必要があります。

導入に関して

開発

こちらはドキュメントも十分に存在し、特段困ることはありませんでした。
基本的に以下2点を確認しておけば十分に開発が可能でした。

• SendGrid WebAPI V3
• php-sdk-usecase

※動的テンプレートやワンクリック解除などは独自開発していたため、SendGrid側の機能は利用していません。
※ワンクリック解除に関しては、送信時にアプリケーション側からPersonalizationsでメールヘッダを設定する形としました。
※できればSendGrid側での開封率・クリック率測定も設定したかったものの、テキストメールに関してはクリック率を測定するのにパラメータが付与されてしまうので以下の理由から利用はしていません。

• アプリケーション側で独自に測定する機能があること
• リンクブランド設定をすればドメインは独自のものになるが、どうしてもパラメータ部分が長く、作成時とメール受信時の差異が違和感を覚えてしまうこと

移行

新規のメールサービスを立ち上げる訳ではなく載せ替えとなるため、移行に関しては以下2点を意識しました。

• IPウォームアップ及びそのスケジューリング
• 送信先リストのクリーニング

IPウォームアップ及びそのスケジューリング

この観点を計画立案時に持てておらず、リリース1週前で一括載せ替えのリリースから段階的なものへとリリースの計画変更をしました、、、😭
メールサービスの載せ替え（というより送信元IPアドレスの変更）が今後あるか分かりませんが、勉強になりました、、。

スケジューリングに関してはこちらを参考に設定しました。

多い日によっては2万通のメールを送信するプロダクトだったため、スロットリングやブロックが発生してしまうと大事故となります。
問題のない可能性もありましたが、慎重になりすぎるぐらいが丁度いいと思い分割で徐々に適用していく計画としました。

実際の送信数は以下のように推移し、過度な遅延が発生するなどの問題はなく1日あたり2万通の送信まで移行することができました。

送信先リストのクリーニング

こちらに関しては問題ないとし、リリース時のクリーニングは実施しない形としました。

バウンス率に関しては最低でも3%未満をキープするものとしています。現行システムでの配信エラー率が3%未満であったため、載せ替え時においてのクリーニングは実施しないという判断をしました。
とはいえ、ソフトバウンス・ハードバウンスともにSendGridでは独自の基準に基づいて振り分けられているため、移行後の変動など注視していく必要はあると感じています。（移行時に限らず送信先リストのクリーニングは定期的に実施をする必要があります。）

また、バウンス率は平均5%~10%あると言われているものの、理想的な数値は0.5%とも言われています。
今回は問題が発生しないと考えられる中で現実的に守れる範囲を設定したので、この水準は改善し続けていかなければいかないと捉えています。

実際、移行後に20万通弱のメールを送信した時点では3%未満をキープする結果となっています。

運用・保守

運用・保守に関してはO'Reilly『入門 監視』の以下の考え方が重要だと考えています。

監視とは役割ではなくスキルであり、チーム内の全員がある程度のレベルに至っておくべきです。

https://www.oreilly.co.jp/books/9784873118642/

メール機能周りの監視・運用に関してはそれ単一の領域で専門的なスキルが求められるため無意識のうちに役割化してしまいがちですが、そうではなく、だからこそ全員が"ある程度"のスキルを獲得し、組織として運用していけるようにしなければいけないと捉えています。
また、対象プロダクトの特性でもあるのですが、SendGridの機能を使い切って安定したメール配信機能の提供だけではなくプロダクト自体の成長にも繋げていきたいという思いもあり、開発チーム外にもレクチャーを実施し組織横断して血の通った運用を実現していく狙いがありました。
これらの考え方をもとに、サービス載せ替えのリリースと同時にチーム全体で運用をしていくために以下の説明会を実施しました。

• プロダクト開発チーム向け：インシデント対応に必要な前提知識、モニタリングに必要な観点をキャッチアップする会
• カスタマーサクセスチーム向け：インシデント対応やプロダクトのサクセス成果を向上させるためのSendGrid管理画面利用方法をキャッチアップする会

プロダクト開発チーム向け説明会

基本的な監視項目に関してはPostmasterToolsのダッシュボードに集約してくれているのでこちらをもとに設計しました。
ただし、PostmasterToolsの結果だけを見ていくのは注意が必要です。

• 項目によってはあくまでGoogleからの評価に過ぎないという点
• 要対応/遵守という2択での評価となるため、事前検知に利用できないという点（コンプライアンスのステータス側の新ダッシュボード）

特に2点目は注意が必要かなと感じています。
リスクに対して事前検知ができない（気づいた時には問題が発生している）という点で、監視ツールとして利用していくべきではないと考えています。

以下の観点で整理をしてみました。（あくまで自組織で運用していこうと考えているものになりますのでご注意ください。）

• 水準：キープしていく理想の水準と、即時アクションが必要な水準の定義
• リスク：水準を満たせないとどのような問題が発生しうるか
• アクション案：とりうる策を参考程度に（状態によって異なるため、記載のアクションをそのまま実行すれば良いというものではないことに注意）

エラー・バウンス率（SendGrid管理画面）

• 水準
  • 理想：3%以内（あくまで現段階。0.5%に近づけていく）
  • 即時アクション：5%超過
• リスク
  • ISPからのメールの受信拒否（ブラックリスト入りすることで他のISP評価にも影響あり）
  • IP/ドメインレピュテーションの低下
  • SendGridアカウント停止
• アクション案
  • 送信先リストのクリーニング
  • メーリングリスト登録時の検証機能実装
  • (設定している場合は)Address Allow Listの見直し
  • (設定している場合は)Purge Bounces & Blocksの解除

APIキーの不正利用により高まるセキュリティリスクもあるので、IP Access Managementの設定&確認必須。

IP/ドメインレピュテーション（インボックスプロパイダの独自基準：PostmasterToolsなど）

• 水準
  • 理想：高
    • SendGrid管理画面で割合を確認することができるが、水準は模索中。。。
  • 即時アクション：中
• リスク
  • 迷惑メールフォルダへの振り分け増加
  • スロットリングの発生
  • ブロックの発生
• アクション案
  • 迷惑メール報告率の改善
  • 認証成功率の改善
  • ブラックリスト入りの定期的な診断

固定アドレスでない場合、共有アドレスとなるため他のユーザーによってIPレピュテーションが低下するリスクがありプロプランとしました。

メールの日次送信数（SendGrid管理画面）

• 水準
  • 日次送信数による
• リスク
  • インボックスプロパイダのコネクション数制限超過
    • スロットリングの発生
    • ブロックの発生
  • 配信コストの増加
• アクション案
  • 固定IPアドレスの追加
  • トランザクションメールとマーケティングメールの分散
  • SendGridプラン変更

SPF/DKIM/DMARC認証結果（Valimail）

• 水準
  • 組織として守るべき水準の検討中ではあるものの100%は難しく、実態から95%ほどと感じています。
• リスク
  • レピュテーションの低下
  • 迷惑メールフォルダへの振り分け増加
• アクション案
  • ブロックリストのメンテナンス

DMARC認証通過の条件に関してはこちらの表がわかりやすかったです。

他にも遅延の発生率やスパムレポートなど見ていきたいものが多くあるのですが、代表的なものはこの辺かなと思っています。

移行していく上で困ったこと

開発

• 認証まわりをSendgridに移行する形としましたが、メールソース上SPF・DKIM・DMARC全てでPASSとなったものの、PostmasterToolsのダッシュボードではdkim&spfが「要対応」となってしまう事象が発生しました。Domain Authentication側でも全てVerifiedとなっているため、経過観察としています。
  • 検証用のメールドメインを、まだ認証設定の完了していないドメインのサブドメインとして用意していたので、そちらが影響してしまっている...？
  • こちらはリリース後10日ほど変わらないので引き続き対応を検討しています。
  • →リリース後2週間で「遵守」に表示が変わりました。一安心。
• ワンクリック解除のベストプラクティスに則りメールヘッダにList-Unsubscribe-Post及びList-Unsubscribeの設定をするも、メーリングリストの登録解除ボタンが表示されませんでした。Gmailコミュニティにある程度実績が積まれないと表示されないという回答もあったのでこちらも経過観察とし、本文内にリンクを設けておく対応としています。
  • ちなみにこちらはSendGrid側でヘッダが自動付与されるUnsubscribe Groupsの機能を利用しても同事象となりました。
  • →リリース後10日ほどで登録解除のリンクが表示され始めました。

運用

• キャリアメールドメインの場合、受信側の設定によりハードバウンス相当のエラーが返却されること。AddressAllowListへキャリアメールのドメインを設定することで回避しているものの、レピュテーションへの影響が見えづらいです。
• PostmasterToolsの評価がざっくりしているので、満たすべき指標の異常を事前に検知しづらいと感じます。認証系や到達率などはSendmailやValimailで細かくみていくことができますが、レピュテーションに関してはプロパイダ独自の基準になるので正確なスコアリングの把握が難しく、検知した際には高→中となってしまっているリスクがあります。

移行後の期待

• サービス運用者として監視をしつつも、送信者ガイドラインの更新など外的要因での対応の必要が少なくなっていくこと（運用負荷の軽減）
• プロダクトの成長など内部の要因であってもスケールアップがしやすくなること（送信元IPアドレスの追加等）
• 導入を進めていく中でSendGridからのメルマガ配信はかなり参考になったため、これからも継続的に情報収集の手段となること

これからの課題

直近、対応していきたいと考えているのは以下2点です。

• Webhook等を利用した通知がまだ構築できていないので、管理画面を見にいく運用が強いられる。アラート設計をして、push型で運用できるような状態に改善していく。
• Subuserでのアカウント分離ができていないので、純粋な数値を見ていくためにも変更していく。

engineer aws / clickhouse