2024年、Gmailと米Yahooによる “No Auth, No Entry” 等
2023年10月、Google (Gmail) と米Yahoo (※) から、メール送信者向けのルール強化についての発表がありました。
それら2社が提供するメールサービスに対して送信した電子メールを受け取ってもらうための必須要件が、2024年初旬に追加されるというものです。
これは、大手メールボックスプロバイダー (MBP) において、送信ドメイン認証の必須化、いわゆる “No Auth, No Entry” が適用される格好であり、メールサービスに関わる人が把握しておくべき変化かと思います。
本記事では、Googleと米Yahooの発表内容や、M3AAWGのコメントをまとめておきます。
SPF、DKIM、DMARC、ARC、BIMIといった送信ドメイン認証をまとめた記事はこちらです。
更新履歴
[2024年3月2日] 2/21時点くらいまでの差分を反映したつもりです (2/8までの差分＋2/21時点まで)。
[2024年1月21日] 米Yahoo分の更新を反映しました。
[2023年12月21日] 随時更新します (更新履歴になってない)。誤字等も随時修正します (親切にご指摘いただいた方、ありがとうございます)。
[2023年12月17～20日] indirect mailについて、追記、修正しました。
[2023年12月16日] GmailのガイドラインやFAQの更新を反映しました。ただ、ガイドラインやFAQは随時更新されるようで、最新情報については公式ページの確認を推奨します。当サイトの内容は、ある時点の状況をまとめたものです。
主な発表の公式ソース等
Gmailと米Yahooから、2024年に適用される電子メール送信者に対する新たな要件について、以下の発表がありました。
それに対するM3AAWGのブログ記事も公開されています。
- Gmail introduces new requirements to fight spam (日本語版の記事はだいぶ遅れて2024年1月に公開…)
- Email sender guidelines – Gmail Help (日本語)
前者のブログ公開 (Product Update) と、後者のガイドライン更新がありました。
さらに、以下のFAQも更新されています。
※ガイドライン、FAQは随時更新されているようなのでご注意を。
米Yahoo
- Postmaster @ Yahoo & AOL — More Secure, Less Spam: Enforcing Email Standards…
- Sender Best Practices, Mail | Yahoo Developer Network
- FAQs, Mail | Yahoo Developer Network
まずブログ記事の公開、その後、Sender Best Practices とFAQsの更新がありました。
Sender Best Practices には、Requirements と Additional Recommendations がそれぞれ書かれています。
M3AAWG
以下は、M3AAWGのコメントです。
M3AAWGは、電子メールのセキュリティを含む様々なネットワーク上の脅威への対策に関する活動を行っているグローバルな団体です。
JPAAWG
日本国内の関連団体であるJPAAWGでは、2023年12月15日にウェビナーがありました。資料がアップされています。
サマリ (早見表)
上記の発表内容に沿って、2024年の所定のタイミングから、Gmailと米Yahooにおいて、電子メールを受信する際のポリシーが厳しくなります。
たくさんのメールを送信する主体 (bulk senders) に対する要件の強化が主となるようです。
早見表っぽくまとめてみました。
※正確な内容、最新の内容については、前述の公式情報等をご確認ください。
(※１) 対象となる受信者に送信される1日あたりのメール通数、カウントはヘッダ From アドレスの primary domain単位 (組織ドメイン単位、サブドメインも合算) かつ24時間単位、なお1回でも bulk senders であると識別された後は bulk senders でなくなることは無い (FAQの#bulk-sender-defと、#expiration)
(※１’) 詐称メールもbulk sendersのカウントに含まれる。問題なら、DMARC enforcement policy (p=quarantine or p=reject) を適用すべきと記載あり。
(※２) おそらく、@yahoo.com、@myyahoo.com、@yahoo.co.uk(旧)、@yahoo.fr(旧) は含む (参考) (AOLのサービスとの関連性は不明)
(※３) 送信元ホストのIPアドレスは、PTRレコードで示されるホスト名から (正引きで) 解決されるIPアドレスと一致する必要性あり (The sending IP address must match the IP address of the hostname specified in the Pointer (PTR) record)
(※４) 記事編集の都合上、欠番
(※５) 説明の中で、Email Deliverability and performance feeds, Mail | Yahoo Developer Networkの測定データに関する言及あり
(※６) 補足事項は後述
(※７) “direct mail” というのは転送やMLを経由 (indirect) して配送されたメールでないものを指していると想定 (補足事項は後述)
(※８) 補足事項は後述
サマリコメント
細かい点や気になった点については後述しますが、ざっくりと個人的なコメントです。
対象
- Gmailでは、おなじみの@gmail.com (個人アカウント) が対象です。
- 2023年12月時点で、Google Workspace (独自ドメイン) は対象外となりました。今後対象となる可能性はあります。
- 米Yahoo (@yahoo.com) については、日本国内からたくさんメール送信するケースは少ないかと思います。
送信者として
- 特に、bulk sender (Gmailでは5,000通/1日以上) 向けの要件が厳しくなるので、それなりにメール流量のある組織、あるいはメール送信サービス事業者は要チェックです。
- あとは、転送やMLにより、組織外にメールを配送するケースについても、配送先が Gmail や米Yahoo になり得る場合には考慮が必要です。
- 上記を考慮し、”重要なメールを Gmail等に送信したが届かない” というケースが発生しないよう確認が必要です。
- bulk senders に該当するかどうかの条件がヘッダFromアドレスの組織ドメイン単位、メール送信レートの制限はIPアドレス単位となるようです。
受信者として
- Gmail をメインで使用している個人ユーザは、今回の変更を意識しておくと良いでしょう。
- ただ、今回の追加要件は送信者向けのものなので、受信者 (Gmail等) としてできることは少ないです。
- 後述の許可リストの設定も、絶対的なホワイトリスト効果があるとは限りません。
- 一応、Gmailでは、特定の送信者からのメールを受け取りたい場合は、その送信者のメールアドレスを予め連絡先に登録しておいたり、もし迷惑メールに分類されてしまったらそのメールを “迷惑メールでない” と選択したりすると、以降はその送信者からのメールが迷惑メールとして判定されにくくはなるようです (米Yahoo の説明には、そのような記載は見当たらず)。
- 上記を考慮し、”重要なメールが届くはずだが受信できない” というケースが発生していないか注意が必要です (届いていないことに気付くのは難しいと思いますが)。
発表をとりまく環境
上記の発表について、関連する事柄を記載しておきます。
フィッシングの脅威
詐称メールを含む各種システムの不正利用によりフィッシングが発生しており、世界的にも大きな脅威です。
Google や米Yahoo を含め、多くのユーザを抱える MBP にとって、このようなフィッシング対策を含めたメッセージングプラットフォームの安全性確保は重要な課題と言えます。
要件追加の目的
自らのユーザに届く不正なメールを減らし、experience を向上させるというスタンスです。
合わせて、送信ドメイン認証を正しく実装できていない送信者も多く、不正利用されている点を指摘しています。
Many bulk senders don’t appropriately secure and configure their systems, allowing attackers to easily hide in their midst.
A key mission of Yahoo is to deliver messages that consumers want to receive and filter out the messages they don’t.
Yet, numerous bulk senders fail to secure and set up their systems correctly, allowing malicious actors to exploit their resources without detection. A pivotal aspect of addressing these concerns involves sender validation, leveraging email authentication standards to guarantee the verification of the email sender’s identity.
出典：Postmaster @ Yahoo & AOL — More Secure, Less Spam: Enforcing Email Standards…
(補足) Gmailの2022年11月時点の変更
以前から、メール送信者向けのルール強化自体は行われています。
Gmailについては、Gmail introduces new requirements to fight spamにて、”Last year we started requiring that emails sent to a Gmail address must have some form of authentication.” と説明があります。
Internet Archiveで確認したところ、2022年11月時点でガイドラインが変更されています。
また、以下のコミュニティ上のやりとりから、このタイミングで SPF または DKIM の設定が必須になったであろうという点は読み取れます。
2022年11月から、「Google Gmail アカウントにメールを送信する新規の送信者は SPF または DKIM の設定が必須になりました」とあり、
…
2社から同時の発表
ちなみに今回、Googleと米Yahooが足並みを揃えてポリシー強化を発表しています。
米Yahooの発表では、Googleのコメントも掲載しており、同志っぽい感じになっています。
Our industry peers like Google agree with us:
…出典：Postmaster @ Yahoo & AOL — More Secure, Less Spam: Enforcing Email Standards…
大手MBPによるベストプラクティス実装
今回追加される要件自体は、以前から M3AAWGのBest Practices に記載されている内容に沿ったものです。
大手が実装に踏み切った格好です。
関連するベストプラクティス文書
以下2つのベストプラクティス文書が該当するかと思います。
- M3AAWG Sender Best Common Practices Version 3.0 (2015年)
- M3AAWG Email Authentication Recommended Best Practices (2020年)
上記2つのうち、前者は電子メールのオプトインや購読解除について (後述のCAN-SPAM法とも関連) 、後者は “No Auth, No Entry” に関連する送信ドメイン認証あたりの内容です。
M3AAWG のベストプラクティス＝ベストチョイスかどうか
M3AAWG は、多くのメールサービス関連企業が参加している団体です。
取りまとめられたベストプラクティス文書は、業界の貴重な成果物だと思います。
そのベストプラクティスを実運用で再現しきることもまた、貴重なチャレンジでもある一方、常に最高の結果をもたらすベストチョイスかどうか、という点については様々な意見も出てくると思います。
ただ少なくとも Gmail、米Yahoo ともにこれらの要件を段階的に適用していくので、送信者 (や受信者) はうまく監視しつつ、メール配送への悪影響を抑えながらセキュリティ強化できれば、建設的です。
(参考) FTCによるトランザクションメールとマーケティングメールの分類
最近、米国のFTC（連邦取引委員会）によって、CAN-SPAM法とトランザクションメール (とマーケティングメール) の定義を巡り、65万ドルの支払いを命じた裁判の事例がありました。
この、”トランザクションメール” と “マーケティングメール” という分類は、今回追加される要件や、DMARC等の送信ドメイン認証や、あるいはメール配信全般についてきちんと検討する際、考慮すべき点かと思います。
CAN-SPAM法において購読解除 (つまりオプトアウト) の対応が必須となるのは、”マーケティングメール” であり、今回のGmailの要件でも “Marketing messages and subscribed messages” と表現されています。
機会があれば、別記事にまとめます。
なお、Gmail の FAQ を2024年2月時点で確認したところ、promotional and transactional messages の区別については、業界や規則によって異なり、メールの性質は受信者が決めることという説明が追記されました。
メール送信者が対応すべきこと
Google のガイドラインに沿った対応としては、以下が考えられます (米Yahooも同様かと思います)。
- 自組織のドメインから Gmail に送信されるメール流量の確認
- Gmail の Postmaster Tools の利用、確認
迷惑メール率の表示有無 = bulk sendersに該当するかどうからしい (参考情報は後述)
- 要件を満たすよう対応するかどうか検討、実装
- SPF、DKIM、DMARC、およびAlignment
- (転送やMLで Gmail に配送し得るなら) ARC対応、もしくは転送やMLの運用見直し
- 自ドメインをヘッダFromとして送信する経路の洗い出し、整理
- マーケティングメールに関し、1クリック購読解除の対応や本文への購読解除リンクの設置
- 送信メールのスパムフィルタリング
- bulk senders に該当するかどうかに関わらず、ベストプラクティスの実装に向けて検討 (送信者に対する要求が厳しくなるのは一般的な傾向)
- Gmailへのメール配送状況のモニタリング継続
- 意図せず正規のメール配送されない場合にはエスカレーション (後述)
- (そもそも) 自組織のドメインやメール環境をどうしたいかをはっきりさせる
- 自前 or 外部委託？
細かな留意点
実際に新たな要件が適用される (or された) 際に、注意しておいた方が良いと個人的に思った点をいくつか備忘用にメモします。
引用元は、ほとんどGmailのものです。
要件適用のタイムライン
Google の FAQ によると、bulk senders 向けの要件は段階的に適用されます (米Yahooも段階的に適用)。
2024年2月から、ガイドラインの要求事項を満たさないメールを配送しようとすると、所定の割合で temporary errors (with error codes) となります。400番台エラーかと思います。徐々にその割合が増えていきます。送信者がこのエラーを検出し対処するためのものです (400番台エラー後の再送時のエラー発生が再び確率で決まるのかどうかは不明)
2024年4月には、所定の割合で拒否され始めます (後述の500番台エラーかと思います)。徐々にその割合が増えていきます。
2024年6月1日までに1クリック購読解除に対応する必要性があります (後述)。
要件を満たさない場合
ガイドラインに記載の要件を満たさない場合、Gmailに送信されたメールは拒否されるか、迷惑メールとして扱われます (FAQより)。
送信ドメイン認証が成功せず拒否されると5.7.26エラー
GoogleのEmail sender guidelinesには、”Messages that aren’t authenticated with these methods might be marked as spam or rejected with a 5.7.26 error. ” とあるので、送信ドメイン認証が成功しない場合、以下のエラーとなるようです。
550, “5.7.26”, “This message does not have authentication information or fails to pass authentication checks (SPF or DKIM). To best protect our users from spam, the message has been blocked. Please visit Prevent mail to Gmail users from being blocked or sent to spam for more information.”
出典：Gmail SMTP errors and codes – Google Workspace Admin Help
DMARCはp=noneで良いと記載はあるものの…
1日あたり5,000通以上送信する bulk senders についてはDMARCが必須ですが、”p=none” でも良いとされています。
Set up DMARC email authentication for your sending domain. Your DMARC enforcement policy can be set to none.
FAQには、DMARC認証は、最終的な受信可否を決定するための重要な要素の1つであり、基本的に DMARC ポリシーに基づいて処理されると記載がありますので、(DMARC の範囲においては) “p=none” のとおりに扱ってくれるようです。
しかし、以下の DMARC 以外の要件によって、Gmail側がメールを受け取ってくれない、もしくはやがて受け取ってくれなくなる可能性はあります。
そもそもDMARCより厳しいという見方も
DMARCの認証成否に関わらず、以下の2つの必須要件がそれなりに厳しいです。
- direct mail の ヘッダFrom が SPF or DKIM の認証対象ドメインと一致することを必須としている (DMARC Alignment 相当) ※ただ、これはDMARC認証成否そのものについて説明しているだけかもしれません
- SPFとDKIMの両方を必須としている (SPF and DKIM)
前者は、通常の DMARC における Alignment と同等です (DKIMは作成者署名)。alignment はサブドメインまでの一致でなく組織ドメイン単位のようです (FAQ)。ただ、direct mail かどうかをどのように判断するのかは不明です (indirect mail かどうかの判断が難しいので、この要件は実際には検証されない可能性や、DMARC認証の成否やARCヘッダの有無を基準にする可能性、あるいはdirect mail かどうかに関わらず検証される可能性、等々…)。
後者については、”all senders” 向けの “or” という表現とは異なる “and” が用いられています。
その文面どおりに解釈すると、普通のDMARCがSPFかDKIMのいずれかでpassすれば良いという点に比べ、より厳しい条件と言えます。
実際、FAQにおいても、SPFとDKIMの両方への対応が最終的な要求になる可能性が示唆されています (“It’s likely that DMARC alignment with both SPF and DKIM will eventually be a sender requirement.”)。
つまり、DMARCより厳密な送信ドメイン認証への対応を求めている意図を読み取れます。
なお個人的には、次期DMARC (DMARCbis) について、RFC策定の見通しに関する不透明感や、今後の実装見直しの可能性も考えられることから、Googleとしては、まずは既に Standards Track になっているSPFやDKIMをベースにした方針を明示することで、将来的な混乱を抑えつつ堅実にルール強化を進めようとしたのであれば、それは合理的だと思います。
DMARCbis の経過については、以下の記事で少しまとめています。
ちなみに、米Yahooの要件には “Publish a valid DMARC policy with at least p=none – DMARC must pass” と記載されています。これは “p=none” でも良いけど DMARC の pass は必須、という意味ですかね (だとすると何のための p=…略)。
Google Postmaster Tools
Google Postmaster Tools は、迷惑メール率だけでなく、レピュテーションの状況等も確認できるので、使用できるようにしておいた方が良さそうです。
Googleのヘルプには画像が無いので、以下のように画像付きで説明されている記事が参考になります。
indirect mail、ARC関連
要求事項として、MLを含む転送時の外部向けメール (indirect mail) へのARCヘッダ追加も挙げられています。
Gmail は、ARC の採用に対して割と積極的な印象です (RFC 8617 の著者の1人は Google)。
このあたりで気になった点をいくつか記載します (本来、別記事にした方がよい内容ですが面倒なのでここに)。
要求事項に ARC があるものの…
ARCヘッダの必須加減についてです。
個人的な印象では、実際のGmailの動作としては、MLを含む転送時の外部向けメール (indirect mail) へのARCヘッダ追加という要件に関し、厳密な検証は行われない気がします。
つまり、”indirect mail (だと思われる) メールに ARC ヘッダが無い” という理由単独では、必ずしも拒否やスパム扱いをしないのでは、という推察です。
以下の理由からです。
- 受信者 (Gmail) は、届いたメールが direct か indirect かを正確に判断できない
- Google のベストプラクティスでは、ARC だけにこだわっている訳ではない
※なお、ガイドラインの要求事項を軽視して良いという意味ではありません
受信者 (Gmail) は、届いたメールが direct か indirect かを正確に判断できない
メールが届いたとき、そのメールが転送やMLを経由 (indirect) して届いたのかどうかを確認することは難しいです (改ざんが無いという前提なら別ですが)。
ARCヘッダがあれば、そのメールがARCヘッダの分だけ署名者を経由して配送されたことは分かります。
しかし、ARC ヘッダの有無を indirect mail かどうかの判断基準にしてしまうのは論理的に無理があります。例えば、”ARC ヘッダが付与されていない indirect mail” を検出することができません。
ということで、MLを含む転送時の外部向けメールにARCヘッダが追加されているかどうかというのは、検証するのが難しい要件であるはずです。
それは同時に、前述の direct mail かどうかの基準が曖昧になることも意味します。
さらに余談ですが、中継者がいなくても、送信者がARC署名して送信しただけの direct mail が Gmail に直接届くケースもあり得るので (MS の Exchange からのメールとか)、”ARC 署名がある = indirect mail “とは限りません (ガイドラインには “ARC headers indicate the message was forwarded and identify you as the forwarder” とはありますが、ケース分類として一応)。
Google のベストプラクティスでは、ARC だけにこだわっている訳ではない
ガイドラインからリンクを辿ると、以下のページがあります。
- ARC email authentication – Google Workspace Admin Help
“ARC reduces the possibility that forwarded messages will fail email authentication.” と、ARC の目的についての記載あり - Forwarding, redirecting, and routing email with Google Workspace – Google Workspace Admin Help
メールの転送等の分類についての説明あり - Best practices for forwarding email to Gmail – Google Workspace Admin Help
“Follow the recommendations in this article to increase the likelihood that forwarded messages pass authentication and are delivered as expected.” と、転送されたメールが認証成功する可能性を高めるという目的に言及あり
特に、最後に挙げたベストプラクティスでは、ARC 以外にも、一般的な対策が説明されています。
例えば、メールが転送されても認証失敗しないよう、以下の対策も推奨されています。
- エンベロープFromの書き換え (“Change the envelope sender to reference your forwarding domain.” と記載があり、これはMLサーバソフトの配送処理や、SRS (Sender Rewriting Scheme) 的な処理に相当)
- DKIMを、SPFとセットで常に使用すること
ARC は、そういったベストプラクティスのコンテキスト中で推奨されている対策の１つです。
ARC 推しスタンスだが、まずは堅実に SPF と DKIM と Alignment を
上記より、indirect mail の問題はややこしいので、Googleとしても ARC がすべてではないという認識かと思います。
対して、ガイドライン上は indirect mail に関する要件として、あっさりと ARC のみが記載されているのですが、その背景が混乱を避けるためということであれば、それはそれで納得です。
ガイドラインに色々と書いても、indirect mail の問題は解決できない見込みが高いからです。
私としては、”ARCは推しておくけど、まず SPF と DKIM と Alignment の部分をしっかり進めよう” という印象を (勝手に) 受けました。
補足として、ARC (RFC8617)はまだ Experimental であり、普及させることにより Standard Track に少し近づくという側面もあります。推し活みたいな。
indirect mail の構成例
indirect mail の構成例について考察してみます。
SRS で DMARC=pass させるメールに ARC ヘッダ追加しない場合
例えば、SRS (Sender Rewriting Scheme) です。エンベロープFromの書き換えです。
転送をする際、SRS により SPF 認証が pass (DMARC認証がpass) となるよう構成している送信者が、ARCヘッダを付与しないままGmailにメール送信した場合はどうなるのでしょう。
Gmail が受け取ったメールが indirect mail であるかどうかを判断する基準が、ARCヘッダの有無だけであれば、(転送やMLを経由したことに気付かれないので) 無事に配送されそうです。
逆に、もしARCヘッダ以外の何らかの要素から判断している場合、”転送やML配送なのにARCヘッダが無い=要求を満たしていない” ということで配送されなくなるケースがあったりするかもしれません (ただ、それは必要以上の検証というか、手段が目的化している感もあります)。
この点は、実際そのように配送された際の結果を目にする機会が無いと分かりませんが。
(補足) MLシステムが配送する際のエンベロープFromの書き換えは SRS とは呼ばないと認識しています。MLの場合、通常は書き換え後のエンベロープFromアドレスの形式は “ML名-bounce@domain” のようなものであり、SRSで用いられるVERPではありません。
ヘッダFrom変更等で DMARC=pass させるメールに ARC ヘッダ追加しない場合
他にも、主にMLシステム (中継者) によって、ヘッダFrom変更等が行われる可能性もあります(Mailmanの説明1、説明2、説明3、Sympaの説明)。
具体的には、それらの中継者が、ヘッダFromを自ドメインのものに書き換え (Munge)、さらに構成によっては、そのドメインのDKIM署名を追加する形です。
これは、中継者が DKIM 署名対象のデータを改変しても、SPF 認証もしくは DKIM 認証が pass (DMARC認証がpass) となる構成です (※)。
(※) 前提をかなり省略していますが、ML配送ではエンベロープFromの書き換えが行われるケースが多い点や、中継者がDKIM署名したドメインがDMARC対応しないといけない点等、あります。
なお、中継前の DKIM 署名がある場合 (もともとの送信者が追加したもの)、それは残ったままでも RFC7489 の DMARC としては pass できるはずですが(Note that a single email can contain multiple DKIM signatures…のところ)、受信する側がより厳しいポリシーで評価する場合、さらに既存のDKIM署名を削除するという選択肢もあります。
これについても、実際そのように配送された際の結果を目にする機会が無いと分かりませんが。
※ちなみに、中継者が DKIM 署名対象のデータを改変しない場合には、もともとの送信者が追加した DKIM 署名に対する認証はそのまま成功しますので、上記のような処理は不要です。
※また、DKIMの再署名をする前には、中継者はそのメールが迷惑メール等でないかをきちんとチェックすべきという話もあります。
ARCの認証結果に基づくローカルポリシー
あと、ARC の認証結果の扱いについてです。
Gmail 側で受信したメールについて、SPF もしくは DKIM の認証が pass (=DMARCも設定されていれば pass) になったとしても、もしそのメールが以前に送信ドメイン認証に失敗したことを示す場合 (おそらくARC-Authentication-Results (AAR) ヘッダを含む場合かと推測)、そのメールを認証されていないものとして扱うようです。
これは、DMARCの認証結果を、ARCの認証結果に基づいて上書きし得ることを示しているようです (DMARC Local Policy Overridesに近いが、これはOverrideによりSPFやDKIMの認証成功を取り消すというパターン) 。
このようなケースは、頻繁に発生するものではないとは思いますが、ARC の実装例として把握しておこうと思いました。
このケースに該当するメールは、基本的には、転送やMLを経て配送されたものです。
If a forwarded message passes SPF or DKIM authentication, but ARC shows it previously failed authentication, Gmail treats the message as unauthenticated.
米Yahoo 側の説明では特に言及なし
ちなみに、2024年1月時点で、米Yahoo の Sender Best Practices には、direct / indirect の区別や、ARC に関する記載はさっと探した限り、見当たりませんでした。
前述のとおり、direct / indirect の区別は受信者が正確に判断できるものでもないので、このように言及しなくても、受信者側の要件として完結はしますね。
迷惑メール率 (spam rates)
迷惑メール率は、0.3%未満を必須、0.1%未満を目指すよう記載されています。
Postmaster Toolsにて確認できるようです (米Yahooの方は、Complaint Feedback Loop)。
迷惑メール率の集計期間は、日次です (FAQより)。
注意点は以下です (FAQより)。
- 0.1%を超えるとメール配送に悪影響 (a negative impact on email inbox delivery) がある
- 0.3%を超えると、後述の mitigations の申請を行う資格を失う (2024年6月以降)
しきい値ピッタリでなく、段階的な影響となるようですが、0.3% だけでなく 0.1% の方も意識した方が良い気がします。
あと、参考までに米Yahooの方の迷惑メール率に関する記載ですが、集計期間の明示が無く、またinbox に配送されたメールが集計対象という説明があります。
共有IPアドレス使用時のレピュテーション
メール送信に使用するIPアドレスを共有するようなメール配信サービスを利用、提供する際には注意が必要です (以前から一般的にも)。
複数のメール送信者 (送信元ドメインと読み替えも可) がメールの送信時に共有 IP アドレスを使用する場合、いずれか送信者の送信処理に対するレピュテーションが、その共有 IP アドレスを使用する他の送信者のレピュテーションに影響します。
A shared IP address (shared IP) is an IP address used by more than one email sender. The activity of any senders using a shared IP address affects the reputation of all senders for that shared IP.
1クリックでの購読解除の要件
Gmail側では、”Marketing messages and subscribed messages” に該当するメールにおいて、ワンクリック購読解除のサポートと、購読解除のための明確なリンクをメッセージ本文に含める必要性がある旨、記載されています。米Yahooも概ね同様の基準です。
1クリックでの購読解除を実装する際のメールヘッダについて解説があります。
以下のRFCが参照されています。
- RFC 2369 – The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields
- RFC 8058 – Signaling One-Click Functionality for List Email Headers
To set up one-click unsubscribe, include both of these headers in outgoing messages:
List-Unsubscribe-Post: List-Unsubscribe=One-Click
List-Unsubscribe: https://solarmora.com/unsubscribe/exampleLearn more about List-Unsubscribe: headers in RFC 2369 and RFC 8058.
なお、RFC 8058 の1クリック購読解除のリクエストは、GETメソッドでなくPOSTメソッドが対象になるので、試しにList-Unsubscribe: ヘッダのURLをブラウザのアドレス欄に普通に入力するといった方法では購読解除の処理は実行されません (GETでも動作するようにしてあるケースはあるかもしれませんが)。
1クリック購読解除の実装を試されている方の記事も参考になります。
2024年2月時点でFAQに追記
補足説明がけっこう追加されています。
1クリック購読解除の実装は2024年6月1日まで猶予
既に購読解除リンクをメッセージ内に設置できている送信者は、2024年6月1日までに1クリック購読解除に対応する必要性があります(FAQより)。若干猶予があると言えばあります。
配信停止リンクが長期間機能していない場合
配信停止リンク (おそらくリンク先のWebサーバ) が長期間機能していない場合、要求を満たしていないことになります。
迷惑メールとして扱われることはないようですが、後述の mitigations の申請を行う資格を失います (FAQより)。
1クリックという性質上、Googleが勝手にリンク先にアクセスすることは無いはずなので、どのように判断するのか、詳細は不明です。
Web (https:) でなく mailto: は Gmail の要求を満たさない (米YahooはOK)
Gmail では、mailto: 形式の one-click unsubscribe では要求を満たさないことが明記されています。
一方、米Yahooの方では、List-Unsubscribe: ヘッダの値として、mailto: もサポートする旨が明記されています。
Of course we support “mailto:” unsubscribe headers as well.
上記や、Sender Best Practicesの記載 です。
購読解除要求を2日以内に処理できているかの確認や実装
ガイドラインでなくブログ記事の方で、購読解除要求を2日以内に処理することが要件として挙げられていますが、全ての購読解除要求に対し、本当に2日以内に処理できているかどうかをGoogleや米Yahooが確認することは不可能です。
実際の運用がどのようになるかは不明です。
一応、細かく考えると、MBPが自前で提供するWebメールシステムや専用アプリ上で表示させたメールの1クリック購読解除を実行した場合には (1クリック＝購読解除の意思)、それから2日経過以降のメール受信有無という条件によって、限定的な確認はできると思います。
ただ、受信者がある送信者から届くメールAとBの両方を購読していたと仮定して、メールAのみを解除する一方でメールBの購読を続ける場合、購読解除から2日以降に引き続き届くメールBが “メールAではない” と判定するロジックの正確性 (List-Idヘッダがあるとは限らない) や、購読解除後すぐに購読を再開したケース等、絶対に齟齬の無い自動判定というのは難しそうです。
RFC 5322、HTML標準への準拠
RFC 5322 – Internet Message Format、HTML Standard への準拠も要件に含まれています。
どの程度厳密に適用されるのか、またHTML Standard (Living Standard) については、最新の要件がいつどのように適用されるのか等については、運用しながら注意が要りそうです。
実際のガイドラインには、たくさん記載があります。
Follow these message formatting guidelines to increase the likelihood that Gmail delivers your messages to the inbox instead of the spam folder:
・Format messages according to the Internet Format Standard (RFC 5322).
・If your messages are in HTML, format them according to HTML standards.
・Don’t use HTML and CSS to hide content in your messages. Hiding content might cause messages to be marked as spam.
・Message From: headers should include only one email address. For example:
From: notifications@solarmora.com
・Make sure every message includes a valid Message-ID (RFC 5322).
・Make sure single-instance message headers are included only once in a message. Examples of single-instance headers include From, To, Subject, and Date (RFC 5322).
・Avoid excessively large message headers. To learn more, visit Gmail message header limits.
・Web links in the message body should be visible and easy to understand. Recipients should know what to expect when they click a link.
・Sender information should be clear and visible.
・Message subjects should be accurate and not misleading.
・Format these international domains according to the Highly Restrictive guidelines in section 5.2 of Unicode Technical Standard #39:
・Authenticating domain
・Envelope from domain
・Payload domain
・Reply-to domain
・Sender domain
Sending guidelinesの記載もろもろ
“Sending guidelines” には、使用するIPアドレスや送信元メールアドレス、メールの種別の考慮、またメール送信レートについての記載があります。
例えば、すべてのメールが同じ IP アドレスから送信されることが理想的であるものの、複数の IP アドレスから送信する必要がある場合は、メールの種類ごとに異なる IP アドレスを使用すること (前述のトランザクションメールとマーケティングメールの話)や、同じメールに異なる内容を混在させないこと、等です。
あと、受信者の連絡先に登録されているアドレスからのメールは、迷惑メールに分類される可能性が低くなるらしいので、これはエンドユーザ側での小手先テクニックの1つになりそうです。
Recommended sending practices
Ideally, send all messages from the same IP address. If you must send from multiple IP addresses, use a different IP address for each type of message. For example, use one IP address for sending account notifications and a different IP address for sending promotional messages.
Messages of the same category should have the same From: email address.
…Messages sent from an address in the recipient’s contacts are less likely to be marked as spam.
Sending practices to avoid
Don’t mix different types of content in the same message. For example, don’t include promotions in sales receipt messages.
異なる送信先ドメインのメール通数を合算
メール送信レートについては、Google Workspaceの “仕事用アカウントおよび学校用アカウント” のユーザが持つ your-company.net と solarmora.com という複数のドメインのメールアドレスそれぞれにメールを送信した際、どちらのドメインも MX レコードに google.com が含まれる場合には、それらのドメインに送信されたメールは送信制限にカウントされるようです。
つまり、メール送信レートを考慮する上で、送信先ドメインごとでなくGoogleに送信されるメールの通数を合算して管理する必要性があります。
For work and school accounts, sending limits apply even when recipients are in different Google Workspace domains. For example, you might send email to users with email addresses that have the domains your-company.net and solarmora.com. Although the domains are different, if both domains have google.com as their MX record, messages sent to these domains count toward your limit.
※2023年12月時点で、Google Workspaceを使用する組織は対象外となりましたが、上記の記載は残ったままです。メール送信レートの制限については対象ということかと思います。
送信メール通数を急に増やさない
同じくメール送信レートについて、以下のような記載があります。
- “急に送信量を2倍” にすると、レート制限やレピュテーション低下につながる可能性がある (過去に大量に送信したことがない場合)。
- メールを週単位でなく日単位で送信するほうが、より早く送信量を増やすことができる。
上記の “2倍 (doubling)” というのは、”メール送信通数を徐々に増やす” にしても、どれくらいのペースで増やせばよいのかを考慮するための目安の1つにはしたいところです (が、比較方法が前日比なのか週平均なのかといったことも分かりません)。
なお、Gmail側のメール送信レート制限の管理が送信元IPアドレス単位だと仮定して、送信元側のメールシステムの切り替え等により “新しいメールサーバが本稼働” した直後には、注意が要りそうです。本稼働前のウォームアップや、段階的なシステム切り替えにより徐々にメール送信通数を増やしていくことが必須になるのかもしれません。ウォームアップの具体的な手法についても迷惑メール判定されないよう配慮が要りそうです。
For example, immediately doubling previously sent volumes suddenly could result in rate limiting or reputation drops.
Frequency of sending email: You can increase the sending volume more quickly when you send daily instead of weekly.
あとは、送信しながら、サーバーのレスポンス、迷惑メール率、送信元ドメインの評価を定期的に監視するよう記載があります。
送信元IPアドレス単位の制限
いまいち読み方が分からなかったのですが、前述のとおり、送信先ドメインのMXレコードにgoogle.comが含まれるメールについて、送信元ホストのIPアドレス単位でメール送信レート制限が適用されるという文脈で理解しています。
Stay within the IP limits for sending:
…
Limit sending email from a single IP address based on the MX record domain, not the domain in the recipient email address.出典：Email sender guidelines – Gmail Help
送信について、以下の IP 制限内に収まるようにしてください。
…
受信者のメールアドレスに含まれるドメインではなく、MX レコードのドメインに基づいて、1 つの IP アドレスからのメール送信を制限します。
その他
その他、気になった点を記載しておきます。
Affiliate marketing、Phishing exercises
“Special considerations” では、Affiliate marketing や Phishing exercises についての注意事項が記載されています。
特に、フィッシングの演習のためのテストメールによりドメインのレピュテーションが低下する可能性もあるようです。
例えば、社内のIT教育のために、模擬的なものであってもフィッシングメール相当のものを送信するような演習を実施するのは控えた方が良いですね。
Monitoring and troubleshooting
以下のような点が記載されています。
- Google では開封率を明示的に追跡していない
- 利用するドメインがGoogle セーフ ブラウジングで危険なドメインとして登録されていないか定期的に確認する
- 一般的なエラーメッセージの例 (以下)
421, “4.7.0”: Messages are rejected because the sending server’s IP address is not on the allowed list for the recipient’s domain.（送信元サーバーの IP アドレスが受信者のドメインの許可リストに登録されていないため、メールが拒否されました。）
550, “5.7.1”: Messages are rejected because the sending server’s IP address is on an IP suspended list.（送信元サーバーの IP アドレスが IP 停止リストに登録されているため、メールが拒否されました。）このエラーは、評価の低い共有 IP を使用してメールを送信すると発生する場合があります。
550-5.7.1: Message does not meet IPv6 sending guidelines regarding PTR records and authentication.（メールが PTR レコードと認証に関する IPv6 の送信ガイドラインに準拠していません。）
メール送信を制限されたら、是正して少しずつ再開
今回の追加要件に限らず、メール送信を制限された場合についてです。
具体的な記載はさっと見つかりませんが、エラーがあればその内容や、ガイドライン等に沿って対処の上、しばらく時間を置いてから、また制限されないように少しずつ、メール送信を再開することになるのかと思います。
If you’re having delivery issues with email sent by a service provider, verify that they use the recommended practices in this article.
…
Use the Google Admin Toolbox to check and fix settings for your domain.
上記では、Google Admin Toolboxの使用について言及されています。
送信者向けのエスカレーションルート
送信者は、ガイドラインの要件を満たしていれば、Gooleに対し mitigations の申請が可能です (FAQより)。
満たしていない場合には、不可です。
mitigations の申請は、Sender Contact Form から行うことができます。
このフォームの説明を読む限り、ユーザから報告されている迷惑メール率が低いにもかかわらず、迷惑メールに分類されるケースが多い場合に、受信制限を緩和するようリクエスト (審査要求) ができるようです。
この申請が通ると、一時的に強制的なスパム振り分けが無効化されるようです。その後、ガイドラインに沿ってメールが送信されていればメール配送の問題は発生しないようになるはずと説明されています。
なお、送信者から許可リスト申請という形では受け付けていないそうです (後述)。
米Yahooの方も、ホワイトリスト機能は提供されませんが、相談窓口やそれに基づく設定調整については言及されています。
BGP hijacking
米Yahooの方は、BGP hijacking に対する注意にも言及がありました。
既存機能、関連仕様
新たに適用される要件が、既存機能とどのように関連するかについての考慮も要りそうです。
実際に適用された後に様子を見るしかないと思いますが…。
許可リストが上記の制限より優先されるか
Gmailには許可リスト機能があります。
しかし、今回の追加要件を含めたポリシーより優先されるとは限らないようです。
注: Gmail で疑わしいメールとして識別された場合は、送信者が許可リストに含まれていても、そのメールは拒否される、または迷惑メールに分類される可能性があります。
補足として、以下はメールプロバイダからの許可リスト登録は受け付けていないという記載です。
Using email service providers
Google and Gmail don’t accept allowlist requests from email providers. We can’t guarantee messages sent by email providers will pass Gmail’s spam filters.
(参考) GmailのSPF検証に関する独自仕様？
参考情報として、さくらインターネットの記事へのリンクを記載しておきます。
Gmailへの転送が失敗するケースについて、GmailではSPF検証の際、送信者と転送者がSPFレコードに含まれているかを検証するという独自仕様について記載されています。
※そのような独自仕様があるらしいという点を参考情報として記載しました。ただ、上記記事の文中にある “本来、メール転送時のSPF確認はメールの送信元（例図ではexample.com）にのみ行われます。” の部分については、SPF本来の記載ではないような気がするので (SMTP Fromアドレスに変更が無ければ転送者のIPアドレスをチェックするはず)、あるいは何か別の前提があるのか、よく分かりませんでした。
また以下のように、トラブルシューティングに関する記事も充実しています。
実際、Gmail側でも以下のように転送者も含めてSPFレコードに登録するよう案内されています。
※なお当然ですが、信頼できない転送者をむやみにSPFレコードに登録してはいけません
転送されたメールが迷惑メールに分類されないようにする
…
ドメインの SPF レコードに、ドメインのメールを転送するすべてのサーバーまたはサービスの IP アドレスまたはドメインが含まれるようにする。
Gmailは2024年に p=quarantine を適用予定
GmailのDMARCレコードは、従来 “p=none” でしたが、今後 “p=quarantine” に変更されるようです。
M3AAWGのコメントによると、2024年に変更予定とのことです。
Don’t impersonate Gmail From: headers. Gmail will begin using a DMARC quarantine enforcement policy, and impersonating Gmail From: headers might impact your email delivery.
出典：Email sender guidelines – Gmail Help
Although it hasn’t garnered nearly as much attention as the new bulk sender requirements for sending mail to Google and Yahoo, Google announced one other change that is likely to have a significant impact. In 2024, they’ll be updating the DMARC record for gmail.com to p=quarantine from its current setting of p=none.
出典：New Minimum Requirements for Sending Bulk Mail to Gmail and Yahoo | M3AAWG
まとめ
本記事では、2023年10月、Google (Gmail) と米Yahoo から発表された、メール送信者向けのルール強化についてまとめてみました。
電子メールは長く使われている技術ではありますが、まだ変わっていく点が多そうです。
参考情報
- GoogleとYahoo.comによるスパム対策の強化｜株式会社TwoFive
- Gmailのメール認証規制強化への対応って終わってますか？ – エムスリーテックブログ
- 詐欺メール撲滅にGoogleとYahooも本腰、導入が求められる「送信ドメイン認証」 | 日経クロステック（xTECH）
- 政府機関総合対策グループ – NISC
※”政府機関等の対策基準策定のためのガイドライン（令和５年度版）” で、DMARC等に対する言及あり
- 送信ドメイン認証全般に関する記事
- 個々の送信ドメイン認証に関する記事
- 送信ドメイン認証のTIPS
-
Authentication-Results ヘッダまとめ ※機会があれば作成予定…
- 送信ドメイン認証の動向
happynap
(はっぴぃなっぷ)
3人家族で暮らし
ITっぽい仕事をしつつ
ポイ活、投資を趣味的に
スキマ時間に、ゆるく全力でブログ
のんびり昼寝したい
お得情報
出張先、旅行先のホテル予約はお早めに
