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
340
Gmailの新ガイドラインでエンジニアが知っておくべき、これからの「メール配信」のあり方
2024/09/18
Developers Summit 2024 KANSAI
の発表資料です。
nakansuke
September 18, 2024
Tweet
Share
More Decks by nakansuke
See All by nakansuke
SendGrid Night #10 Opening Talk
nakansuke
0
360
SendGrid Introduction
nakansuke
0
440
コミュニティで写真を撮るときの心得
nakansuke
1
3k
コミュニティ、デベロッパとの付合い方 〜SendGridの場合〜
nakansuke
1
1.9k
SendGrid x kintone利用例紹介と効果的な活用方法
nakansuke
0
1.2k
SendGrid New Features #sgnight7
nakansuke
0
250
SendGrid APIインプット#mbshack
nakansuke
0
170
海外Webサービスを日本に持ってきた話
nakansuke
0
450
Community & Developer Relations #CMC_Meetup
nakansuke
1
860
Other Decks in Technology
See All in Technology
S3 Glacier のデータを Athena からクエリしようとしたらどうなるのか/try-to-query-s3-glacier-from-athena
emiki
0
240
いま、あらためて考えてみるアカウント管理 with IaC / Account management with IaC
kohbis
2
380
Intro to Software Startups: Spring 2025
arnabdotorg
0
270
ユーザー課題を愛し抜く――AI時代のPdM価値
kakehashi
PRO
1
130
MCP認可の現在地と自律型エージェント対応に向けた課題 / MCP Authorization Today and Challenges to Support Autonomous Agents
yokawasa
5
2.5k
AI時代の大規模データ活用とセキュリティ戦略
ken5scal
1
220
AIが住民向けコンシェルジュに?Amazon Connectと生成AIで実現する自治体AIエージェント!
yuyeah
0
180
o11yツールを乗り換えた話
tak0x00
2
1.6k
GCASアップデート(202506-202508)
techniczna
0
180
datadog-distribution-of-opentelemetry-collector-intro
tetsuya28
0
110
✨敗北解法コレクション✨〜Expertだった頃に足りなかった知識と技術〜
nanachi
1
770
僕たちが「開発しやすさ」を求め 模索し続けたアーキテクチャ #アーキテクチャ勉強会_findy
bengo4com
0
2.5k
Featured
See All Featured
BBQ
matthewcrist
89
9.8k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
GitHub's CSS Performance
jonrohan
1031
460k
Why You Should Never Use an ORM
jnunemaker
PRO
58
9.5k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
The Pragmatic Product Professional
lauravandoore
36
6.8k
Site-Speed That Sticks
csswizardry
10
770
Writing Fast Ruby
sferik
628
62k
RailsConf 2023
tenderlove
30
1.2k
Balancing Empowerment & Direction
lara
2
570
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
36
2.5k
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