Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Gmailの新ガイドラインでエンジニアが知っておくべき、これからの「メール配信」のあり方
Search
nakansuke
September 18, 2024
Technology
0
85
Gmailの新ガイドラインでエンジニアが知っておくべき、これからの「メール配信」のあり方
2024/09/18
Developers Summit 2024 KANSAI
の発表資料です。
nakansuke
September 18, 2024
Tweet
Share
More Decks by nakansuke
See All by nakansuke
SendGrid Introduction
nakansuke
0
350
コミュニティで写真を撮るときの心得
nakansuke
1
2.8k
コミュニティ、デベロッパとの付合い方 〜SendGridの場合〜
nakansuke
1
1.7k
SendGrid x kintone利用例紹介と効果的な活用方法
nakansuke
0
1.1k
SendGrid New Features #sgnight7
nakansuke
0
190
SendGrid APIインプット#mbshack
nakansuke
0
130
海外Webサービスを日本に持ってきた話
nakansuke
0
420
Community & Developer Relations #CMC_Meetup
nakansuke
1
820
SendGridを活用したメール送信&メールマーケティング
nakansuke
0
670
Other Decks in Technology
See All in Technology
30万人が利用するチャットをFirebase Realtime DatabaseからActionCableへ移行する方法
ryosk7
2
280
わたしとトラックポイント / TrackPoint tips
masahirokawahara
1
190
Figma Dev Modeで進化するデザインとエンジニアリングの協働 / figma-with-engineering
cyberagentdevelopers
PRO
1
310
2024-10-30-reInventStandby_StudyGroup_Intro
shinichirokawano
1
120
失敗しないOpenJDKの非互換調査
tabatad
0
220
【LT】ソフトウェア産業は進化しているのか? -Javaの想い出とともに- #jjug_ccc
takabow
0
150
分布で見る効果検証入門 / ai-distributional-effect
cyberagentdevelopers
PRO
2
410
生成AI×マルチテナントSaaSな新規事業を立ち上げる上でテックリードとして気を使った点の紹介
lunastera
0
520
SwiftSyntaxでUIKitとSwiftUIの使用率を完璧に計測できちゃう件について
ldf_tech
0
160
オニオンアーキテクチャで実現した 本質課題を解決する インフラ移行の実例
hryushm
13
2.6k
Creating Intuitive Developer Tool in Swift
giginet
PRO
0
500
ABEMA のコンテンツ制作を最適化!生成 AI x クラウド映像編集システム / abema-ai-editor
cyberagentdevelopers
PRO
1
120
Featured
See All Featured
Fantastic passwords and where to find them - at NoRuKo
philnash
50
2.8k
Ruby is Unlike a Banana
tanoku
96
11k
Speed Design
sergeychernyshev
24
560
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
504
140k
BBQ
matthewcrist
85
9.3k
Thoughts on Productivity
jonyablonski
67
4.3k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
Learning to Love Humans: Emotional Interface Design
aarron
272
40k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
41
2.1k
Imperfection Machines: The Place of Print at Facebook
scottboms
264
13k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
3
360
Producing Creativity
orderedlist
PRO
341
39k
Transcript
Gmailの新ガイドラインで エンジニアが知っておくべき、 これからの「メール配信」のあり方 2024/09/18 Developers Summit 2024 KANSAI 1
自己紹介 中井 勘介 K an s u k e N
a k a i 会社名 株式会社構造計画研究所 役職 執行役員 SendGrid事業責任者 2 メールに携わり始めて早10年 何でも気軽にご相談ください @nakansuke
Twilio SendGrid 3 ❖ アメリカ生まれのクラウド型メール配信サービス ❖ 月間送信通数1,480億通以上 ❖ メルマガの一斉送信から自動通知メールまで 導入企業
自己紹介 東 邦之 K u n i y u k
i A z u ma 会社名 株式会社Cubicroot 役職 開発部 部長 メールサーバーを作ったり大量配信 の相談係をしたりバウンスメールの 解析をするOS SのS isi ma iを開発し てます (h ttps: //l ib si sim ai .or g) @a zu ma kun i yuki 4
Gmailの新ガイドラインを元に、 メール世界の「ニュースタンダード」を考えよう 5
Gmailガイドライン対応しましたか? 6 ❖ 2023年10月 Googleが送信者向けガイドラインの 更新を発表 ❖ 要件を満たさなければGmail宛ての メールが届かなくなる 半数以上の宛先に届かなくなるかも!?
Gmailガイドラインの要件 7 ❖ 送信元ドメインでSPFとDKIMを設定する ❖ 送信元ドメイン、IPアドレスに対し、正引き、逆引きDNSレコードを設定する ❖ DMARCを設定する ❖ ヘッダFromドメインはSPF,
DKIMドメインと一致させる ❖ 転送する場合はARCヘッダを追加する ❖ ヘッダFromにGmailのドメインを指定してはならない ❖ 送信経路にはセキュア通信 (TLS) を利用する ❖ RFC 5322に準拠した形式で送る ❖ 迷惑メール報告率を0.1%未満に維持する ❖ ワンクリックでの配信停止に対応する
ガイドラインが求めていること 8 • メッセージが、誰から送られてきたものか明確であること • 安全かつ信頼できる方法で送信されていること • 受信者が必要としている、読まれるメールを送っていること • 不要なメールは受け取らない選択を受信者自身ができること
①認証と信頼 ②送信者としての適切な振る舞い
Gmailガイドラインの要件 9 ❖ 送信元ドメインでSPFとDKIMを設定する ❖ 送信元ドメイン、IPアドレスに対し、正引き、逆引きDNSレコードを設定する ❖ DMARCを設定する ❖ ヘッダFromドメインはSPF,
DKIMドメインと一致させる ❖ 転送する場合はARCヘッダを追加する ❖ ヘッダFromにGmailのドメインを指定してはならない ❖ 送信経路にはセキュア通信 (TLS) を利用する ❖ RFC 5322に準拠した形式で送る ❖ 迷惑メール報告率を0.1%未満に維持する ❖ ワンクリックでの配信停止に対応する
ガイドラインの意義 10 ❖ メールボックスプロバイダ(Google、Yahoo! など)が 目指しているのは「受信者にとって快適な受信トレイ」 スパムメール 受信者が 望まないメール
ガイドラインの意義 11 ❖ メールボックスプロバイダ(Google、Yahoo! など)が 目指しているのは「受信者にとって快適な受信トレイ」 ❖ 対策を強化するため、Googleはガイドラインを厳格化 ❖ Gmailに限らず、各プロバイダは受信者が望むメール
ほど届きやすい仕組みを備えている
メール配信の歴史 12 「無秩序」時代 一括大量配信によりメールは嫌がられるものに 「スパム報告」時代 スパムボタンを使ってスパムを撲滅するように 「エンゲージメント」時代 スパムフィルタが洗練されより複雑になり、またパーソナライズされたフィルタ により不要なメールはブロックされるように 受け手が欲しがるメールを送る必要がでてきた
新ガイドラインで何が変わった? 13
2024年2月以前 14 ❖ 2014年?月 米国Yahoo!のDMARCが”p=reject”に ❖ 2015年3月 DMARCがRFC7489になる ❖ 2016年1月
GmailでDMARCが実装される ❖ 2017年9月 GmailでARCが実装される ❖ 2019年10月 Gmail宛転送がDMARC違反で拒否(観測) ❖ 2023年10月 Gmail+米国Yahoo!でガイドライン発表
DMARC導入率(60%) 15 出典: https://www.proofpoint.com/jp/blog/email-and-cloud-threats/Global-DMARC-Adoption-Rate-Survey-2023 出典: https://www.proofpoint.com/jp/blog/email-and-cloud-threats/Japan-lags-far-behind-in-fighting-spoofed-emails-DMARC 2022年
DMARC導入率の上昇 16 出典: https://www.proofpoint.com/jp/newsroom/press-releases/Nikkei225-Firms-and-Japanese-Gov-Accelerating-Measures2Combat-Email-Spoofing-Fraud
2024年2月以降 17 ❖ 2024年2月 Gmailの新ガイドライン開始(一時エラー) ❖ 2024年3月 米国Yahoo!宛の送信が厳しくなる(観測) ❖ 2024年4月
Gmailの新ガイドライン開始(恒久エラー) ❖ 2024年5月 Microsoftも追従するという情報 ❖ 2024年6月 今月開始と聞いてた件は始まらず ❖ 2024年8月 米国Yahoo!宛の送信が緩和(観測)
Microsoftも!? 18 出典: https://www.valimail.com/blog/microsoft-email-authentication-requirements/ May, 2024 Ross Adams, Microsoft’s Principal
PM Architect said 「いつ実施するかが問題、やる・ やらないの話ではない(意訳)」 Microsoftからの公式発表はまだ
Microsoftも! 19 出典: https://www.valimail.com/blog/microsoft-email-authentication-requirements/ 最終的にp=quarantine / reject に持っていきたい意図がありそう p=noneは通らなくなる可能性? Microsoftからの公式発表はまだ
メール配信アンチパターン よくある誤解たち 20
21 ダブルオプトインをやらない 1. フォームにメールアドレスを入力 2. 実際にメールを送信 3. メール本文内のリンククリックで登録完了 ダブルオプトインのメリット ❖
明確な受信意思がありエンゲージメントが高い ❖ 開封、クリックによりレピュテーションに好影響 ❖ メールアドレスの存在、到達が確認済み ❖ スパムトラップの混入防止
参考:スパムトラップとは 22 メールボックスプロバイダが仕掛けている 罠のメールアドレス スパムトラップはメールを受信するが オプトインや開封はしない スパムトラップに送り続けると 悪質な送信者と判断される 到達率を維持するには、宛先からスパムトラップを排除 受信者の反応を気にせず
送り続けることはNG
登録者のメアドは絶対に消さない 23 ❖ 反応のない宛先はリストから削除する ❖ 例)再エンゲージメントメールに反応がなければ削除 新規ユーザー アクティブ ユーザー 非アクティブ
ユーザー 退会候補 新規ユーザー 新規登録やサインアップしたばかり アクティブユーザー 製品やサービスに満足しており、継続が期待できる 非アクティブユーザー しばらく利用がなく、関心が薄れている 離脱のリスクが高い 退会候補 離脱が確実視され、これ以上の働きかけが効果的でない どんな人でもいずれはエンゲージメントが下がる
配信停止を分かりにくくする 24 ❖ わかりやすい配信停止フロー=迷惑メール報告の防止 ❖ ワンクリックでの配信停止の導入 一時的な配信停止オプション すべてのメールを停止する受信者を82%も減らすことができる Oracle: Modern
Marketing Blog “The Evolving Use of Snooze in Email Marketing” Oracle: Modern Marketing Blog “The Evolving Use of Snooze in Email Marketing”
バウンスメールを放置する 25 ハードバウンス Hard Bounce 500系 恒久エラー • 宛先メールアドレスが存在しない •
宛先ドメインが存在しない • 宛先メールアドレスが閉鎖・停止中 • 長期間にわたりメールボックスが一杯 ソフトバウンス Soft Bounce 400系 一時エラー • ドメイン認証に失敗・内容でスパム判定 • RFC違反・セキュリティポリシーに違反 • メールが大きすぎる • 一時的にメールボックスが一杯 • 接続数が多い・速度が速すぎる・DNS関連 • レピュテーションによる拒否 宛先メールアドレスの存在 に関するバウンス 発生を観測したら直ぐに配 信対象から除外 3回までならOKとか謎ルー ルを用いないこと 宛先MTAからの警告・回数 や内容を注視し対応する
直ぐに除外すべきハードバウンス 26 User Unknown: 宛先不明(メールアドレスが存在しない) Mailbox Full: 受信箱が一杯(500系エラー・長期間にわたるもの) Suspend: アカウント停止中(料金未払い・BAN・非アクティブ)
再送し続けると「宛先リストを管理できていない」と見做される
安易な変更をする 27 発信者アドレス(From:ヘッダー・Envelope From) 送信元IPアドレス (レピュテーションでも重要な部分) メールの形式 (ヘッダーや本文の構造における大きな変更) 変更するなら数カ月前から計画的に暖機運転が必要 Gmailの新ガイドラインで
言及されている
必要な変更をしない 28 宛先リストの更新(バウンスした宛先の削除・定期的な宛先確認) 配信サーバーの調整(相手側ポリシーの変更・一時エラーの観測) 配信頻度やコンテンツ(クリック率やスパム報告率と合わせて) 配信における信頼性の維持(相手側MTAから・ユーザーから)
まとめ メールのような枯れた技術でも進化は続けている 昔当たり前だったことも、今では当たり前ではないかも 「ニュースタンダード」に乗り遅れないように キャッチアップを続けていくことが重要 29