これはkintone Advent Calendar 2022の12/24担当の記事です。
本来ならば事前に記事書いて当日の朝公開されるべきなのですが、、時間が全くとれず翌日の公開になってしまいました。反省。。
背景
今までのメール運用
去年のアドベントカレンダーQiitaで概要を書きましたが、私が所属するパブリテック事業部では、契約情報管理含む基幹システムを現在はkintoneで管理しています。そのため、以下のような案内をkintone内で管理しているメールアドレスや顧客情報を元にしてメールを送る必要があります。
- トライアルご案内やお知らせ、通知
- 各サービス導入説明や研修のご案内メール
- サービスメンテナンス通知
- 障害発生時の報告や通知
- ライセンス証書送付
- 販売パートナーへの見積書、注文請書などの送付
オペレーションの効率化と誤送信防止のため極力人の手を介さずに運用を行うためにトヨクモ社が提供しているkMailerを契約してGmail API経由でメールを送信できるようにしました。
作業者は、kintoneの詳細画面からメール作成し、メールテンプレートを選択して確認画面で送信ボタンをクリックするだけでメールを送信することができるため、宛先誤り防止やメール作成効率化が実現できました。
また、ステータス変更やフィールド値変更などのトリガで裏側でメールを自動送信することもできるため本当に人間がメール本文をチェックして送信すべきもの以外は自動送信する運用にしています。
なぜ移行することにしたか
事業立ち上げから3年程度は上記の運用だけで全く問題なかったのですが。以下の課題が出てきました。
- 契約数が増えてきてGmailの送信上限件数(2,000通/日)を超過してしまう日が発生
- 一斉送信を実行したとしても内部では1件ずつメールを送信する仕組みであるため約2,000件のメール送信に100分以上かかってしまい障害通知など即時性が必要となる通知には向かない
LoGoチャットとLoGoフォームの契約団体数すべてにメール一斉送信するだけでも2,000通上限を超過することになってきてしまったため障害や緊急の通知など1日に何度も一斉送信が必要となった場合にはkintoneからCSV出力して別のメール配信ツールから一斉送信する...などの運用が発生してきてしまいました。これではオペレーションが煩雑になり誤送信などのリスクが増えるため、Gmail APIではない別の方式への移行が必要ということでSendGridで検証することにしました。
SendGridとは?なぜSendGridか
SendGridはメール配信サービスです。以前はSendGrid社が運営するサービスでしたが、Twilio社に買収されサービスの正式名称は「Twilio SendGrid」になっているようです。SendGridの正規代理店である構造計画研究所さんのブログがわかりやすいです。
SendGridとは?
メール配信ツールはたくさんありますが、その中でも以下の理由でSendGridを採用しました。
- kMailer公式のブログにいくつか情報があり実績あるツールである
- 他事業本部でSendGridを使っている情報があったため技術情報共有して知見を溜められそう
- (個人的にかもしれないですが)SendGridは昔から知っておりメール配信ツールとしての運用実績が長く信頼できた
- API中心での利用であるため画面操作性などは優先度が低く、機能としてはどれもあまり大差ないので正直どれでもよかった
- 構造計画研究所さんのブログやAPI仕様書など技術情報が豊富にあり扱いやすい
移行前の設定
移行前のSendGridの設定での注意事項
色々調べたり検証した中で注意する点を記載します。
プラン契約
これは設定というより契約なんですが。企業として実用するなら絶対有料のProプラン以上にした方がよいと思います。無料プランでもメール送信はできるのですが、Proプランでしか利用できない固定IP利用やサブユーザ機能は安全に確実にデータを管理しメールを相手に届けるために必要な設定だと思います。
確実に相手にメールを届けるための対策
固定IP設定
Pro以上のプランだと固定IPが割り当てられますのでそれを送信元のアドレスに紐づけて設定します。設定方法はこちら参照
ブロックリストの宛先調査運用を検討
SendGridには、様々な配信停止や配信エラーがリストアップされる仕組みがあります。詳細はこちらのドキュメント参照
SendGridが自動で配信停止リストに登録して今後同じアドレスには送信されない状態にしてくれるものから、リスト化されるけど今後も送信自体はされるものがあり、せっかくリスト化されても放置したままにすると通知が届かないなどのクレームやレピュテーションが下がる要因になってしまいますので実際の運用に合わせてリストからの解除や配信停止への追加などオペレーションを検討する必要があるかと思います。
- Bounces: メールアドレス誤りなど恒久的な配信エラーでSendGridで自動的に登録されるリスト(ハードバウンス)
- Deferred: 一時的な配信エラー(ソフトバウンス)
- Blocks: ソフトバウンスしたためSendGrid側で再送を試みたが、一定時間経っても宛先サーバが受け付けなかった。不明なドメインのメールアドレスなど。登録されてもメールは送信される。
- Spam Reports: 受信者からの迷惑メール報告
- Unsubscribes、Group Unsubscribes、Group Resubscribes: 配信停止または配信停止の解除。
今回移行したメールは重要な契約情報関連の通知や障害報告などのメールに利用するものであるため、定期的にリスト内のアドレスを調査して対応を検討する運用にしています。
送信ドメイン認証(独自ドメイン設定-SPF/DKIM設定)
システムとしてはSendGridからメールを送信しますが、独自ドメイン利用設定を行うことによって、受信者には "所有の独自ドメインから直接メールが送られてきた" ように見せることができます。これをドメイン認証といいますが、今回の送信元となるコーポレートドメインをドメイン認証することで信頼度を上げています。
設定方法はこちらのDomain Authentication設定参照です。
これは独自ドメイン認証設定前にメール送信した場合の受信側であるGmailからなりすましメールとして迷惑メール判定されている例の画面です。
独自ドメイン認証設定を行うと「sendgrid.net経由」という文言が消えてコーポレートドメインが認証したものであることがわかります。
送信ドメイン認証(独自ドメイン設定-IPアドレス逆引き設定)
IPアドレス→ドメインという登録だけでなく、IPアドレス→ドメインという方向でもドメイン設定を行っておくことで信頼性および到達率の向上ができます。設定方法はこちらのReverse DNS設定参照です。
IPウォームアップ
宛先サーバから見た「メールの送信元IPアドレスの信頼度(=レピュテーション)」を上げ、送信者としての信頼を獲得するための作業です。こちら参照。
今回の移行時には、ちょうど必ずしも同日にメールが届かなくてもよい一斉送信内容であった「年末年始の休業のお知らせ」メールを5日間かけて少しずつ50通→100通→500通→1,000通→2,000通に分けてメール送信することでIPウォームアップを行いました。
切替えが簡単にできるため既存の運用に影響することなく簡単にウォームアップができます。
移行時の設定
kintoneの設定
設定変更は不要です。kMailerが間に入っているため、kintone側のオペレーションも設定も何も変更することなく移行ができます。
SendGridの設定
SendGrid APIキーの発行
設定方法はこちらの項番2から5です。トヨクモさんのブログでは詳細書いてないですが、項番4の権限は最小権限に設定した方がよいのと、項番5のAPIキーが表示されるのは初回の1回のみになるため必ずどこかにメモしておき安全な所でデータ保管した方がよいことに注意です。
二要素認証設定
SendGrid APIを利用するにはSendGridを二要素認証設定しておかないと利用できないようなので必ず設定が必要です。トヨクモさんのブログではSMSテキストでの設定になっていましたが、SMSにはかなりタイムラグがあり数分以上経って忘れた頃に発行されていたりと面倒だったので私は二要素認証アプリAuthy Appでの認証で利用しています。
kMailerの設定
SendGrid APIへの切り替え
トヨクモさんのこちらのブログだと情報が古い?のか、ユーザ名が自分のものと記載があるんですがユーザ名はSendGridを利用する場合には必ず「apikey」になるようですので注意です。こちらのヘルプ手順の内容が正しいです。パスワードはSendGrid APIキーを入力します。
検証に使ったツール類
検証のためレピュテーションを図るツールをいくつか使いました。
- Newsletters spam test
- SenderScore.org
- BarracudaCentral
- Google Postmaster Tools
- Microsoft SNDS
- Trend Micro Email Reputation Services
- Network Tools: DNS,IP,Email
この中でも検証してみたオススメはNewsletters spam testです。各項目ごとでスコアリングされるのでどこが悪いのかがわかりやすいです。セキュリティ設定する前は如実にレピュテーションスコアが悪く、
移行してみて
移行してから1か月程度経った時点での所感は以下です。
- 操作者の操作に変更がなかったためスムーズに混乱なく移行ができた
- 2,000件のメールが数分で送信完了になるのは気持ちいい
- レピュテーションが99%以上で維持できている。IPウォームアップちゃんとしてよかったのかも。
- SendGridのActivityログは7日間しか保存されないため、webhookトリガでAWS Lambda > S3 に保存し、Athenaで参照できる仕組みなど検討中
- SendGridの構造計画研究所さんの技術サポート心強い
- メールって...奥が深い...