SendGrid Night #4 参加レポート (2)
クロスワープの大鷲です。
前回に引き続き、SendGrid Night #4 のレポートをお届けします。
発表資料の全体は構造計画研究所さんのブログをご覧ください。
ユーザ事例：習い事サービスサイタの場合
コーチと受講者を結びつける習い事サービス Cyta.jp でのメール送信のお話でした。
送信できなかったメールに対する対策とサポートを手動で行っていたのが、Event Webhook によって自動化できたというお話。
メール受信をトリガーとして実行される処理も、SendGrid の API を使うことでリプレースでき、メールサーバーの保守から解放されました。
メールマガジンや月次タスクなど、スポットで大量配信する際も、送信遅延を起こすことなく送れるようになりました。
こういったことができるのはクラウドの強みですね。
Substitution（受信者の名前を埋め込むなど、メール本文を個別の送信先ごとにカスタマイズする機能）を使う際、API にはテンプレート的な本文と、そこに差し込むデータの配列を渡しますが、それを当てはめた結果の、実際にユーザーに送信される本文は Webhook を使っても取得できないので、ログに残す目的で、置換処理を自前で行ったという点が興味深かったです。
LT：先輩社員がダブルオプトインの確認フラグを折り、僕の心もヘシ折った話
株式会社 VASILY の塩崎さんのお話。
ダブル オプトインとは、
- Web サイト上でメールの受信手続きを取ってもらい
- 確認メールを送信し、メール内のリンクをクリックしてもらうことで手続き完了とする
という 2 段階のメール受信の意思確認のことだそうです。
ダブル オプトイン手続きを取ったユーザーを DB 上で管理していましたが、某先輩社員がメルマガの送信数を増やそうとして
あっ……。
結果、質の低いメール アドレス リストが出来てしまったので、そのリストをクリーニングするために様々な方策を取られたそうです。
LT：後ろを向き、前に進む
ピクスタ株式会社の佐藤さんのお話。
つまりはそういうことです。
SendGrid を使ったからといって任せきりでいいわけではなく、継続的な送信先リストのメンテナンスが必要ですというお話でした。
AWS SES は特に日本の携帯キャリア メールにはあまり強くないようです。
また、使われていないであろうアドレスを判断して送信を止めることが重要であるとのことでした。
まとめ
いかがでしょうか。
なんと、示し合わせたわけでもないのに、全 6 セッションのうち 5 セッションまでが「レピュテーションを大事にしろ」と訴えるという事態に。
レピュテーションというのは、そのメールの「怪しくなさ」の度合いとでも言えばよいでしょうか。
率直に言いますと、私は今回 SendGrid を使ってみるまで、「レピュテーション」ということを意識したことがないどころか、そんな言葉を聞いたこともありませんでした。
もちろん迷惑メール判定が自動で行われていることや、SPF や DKIM といった技術については知っていましたが、判定は主にメール アドレスや本文に基づいて行われていると思っており、IP アドレスでも判断されているなんて思ってもみませんでした。
ましてや IP アドレスの「怪しくなさ」を上げるために、段階的にメール流量を増やして実績を上げていくという処理が必要だなんて……。
同時に、上げたレピュテーションを下げないため、スパム トラップに引っかからないために、送信先を厳選することの大切さ。
全体を通して、「メールを無事送り届けるために重要なこと」を学ぶことが出来ました。
今回私が開発にかかわった MODD のメール送信サービスは、まだ実運用に乗っていない段階で、改善していくべきポイントも多数あります。
機能面での改善だけでなく、こうしたレピュテーション向上対策も意識して、今後の改善を進めていきたいと思いました。
