朝から昼寝

ITや家計、身近なことの整理

[お知らせ]
当サイトは、2024年1月1日に
新URL(happynap.net)に引っ越しました





このページの内容は、最新ではない場合がありますので、新URLをご確認ください。






当サイトには広告を含みます。"オススメ"として紹介している商品やサービスは、個人的にそう思えたものだけです。
共感、興味をもっていただけるものがあればご利用ください (広告掲載ポリシー)。

最終更新日

2024年、Gmailと米Yahooによる "No Auth, No Entry" 等

ネットワークサービス セキュリティ 電子メール [IT]

年末年始のAmazon

happy-nap.hatenablog.com

↑ 人気

概要

2023年10月、Google (Gmail) と米Yahoo (※) から、メール送信者向けのルール強化についての発表がありました。

2024年初旬に、それら2社が提供するメールサービスに対して送信した電子メールを受け取ってもらうための必須要件が追加されるというものです。

これは、大手メールボックスプロバイダー (MBP) において、送信ドメイン認証の必須化、いわゆる "No Auth, No Entry" が適用される格好であり、メールサービスに関わる人が把握しておくべき変化かと思います。

本記事では、Googleと米Yahooの発表内容や、M3AAWGのコメントをまとめておきます。

(※) アメリカのYahooの話なので、日本のYahoo! Japan (LINEヤフー株式会社) が提供するメールサービス (@yahoo.co.jp) のことではありません。

SPF、DKIM、DMARC、ARC、BIMIといった送信ドメイン認証をまとめた記事はこちらです。

更新履歴

[2023年12月21日～] しばらく随時更新します (更新履歴になってない)。
[2023年12月17～20日] indirect mailについて、追記、修正しました。
[2023年12月16日] GmailのガイドラインやFAQの更新を反映しました。ただ、ガイドラインやFAQは随時更新されるようで、最新情報については公式ページの確認を推奨します。当サイトの内容は、ある時点の状況をまとめたものです。

注意

本記事の内容は個人的な調査結果や経験に基づいたものです。
正確かどうか、最新かどうかについては、公式情報等をお確かめください。

主な発表の公式ソース等

Gmailと米Yahooから、2024年に適用される電子メール送信者に対する新たな要件について、以下の発表がありました。

それに対するM3AAWGのブログ記事も公開されています。

Google

前者のブログ公開 (Product Update) と、後者のガイドライン更新がありました。

さらに、以下のFAQも更新されています。

※ガイドライン、FAQは随時更新されているようなのでご注意を。

米Yahoo

追加要件の詳細については明記されていませんが、今後Sender Hubにて案内予定とのことです。

M3AAWG

以下は、M3AAWGのコメントです。

M3AAWGは、電子メールのセキュリティを含む様々なネットワーク上の脅威への対策に関する活動を行っているグローバルな団体です。

JPAAWG

日本国内の関連団体であるJPAAWGでは、2023年12月15日にウェビナーがありました。資料がアップされています。

サマリ (早見表)

上記の発表内容に沿って、2024年の所定のタイミングから、Gmailと米Yahooにおいて、電子メールを受信する際のポリシーが厳しくなります。

たくさんのメールを送信する主体 (bulk sender) に対する要件の強化が主となるようです。

まずは、2023年10月に発表された内容を早見表っぽくまとめてみました。

※正確な内容、最新の内容については、公式情報等をご確認ください (公式ソースは前述)。

(※１) 対象となる受信者に送信される1日あたりのメール通数、カウントはヘッダ From アドレスの primary domain単位 (組織ドメイン単位、サブドメインも合算) かつ24時間単位、なお1回でも bulk senders であると識別された後は、bulk senders でなくなることは無い (FAQの#bulk-sender-defと、#expiration)

(※２) おそらく、@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)

(※４) 近々、詳細な情報が公開されるらしい (In the coming months we will provide more details on our Sender Hub) (もともとSender Best Practices, Mailにはそれなりにベストプラクティスとしての記載はあり)

(※５) 説明の中で、Email Deliverability and performance feeds, Mail | Yahoo Developer Networkの測定データに関する言及あり

(※６) "Marketing messages and subscribed messages"に該当するメールは、購読解除のための明確なリンクをメッセージ本文に含む必要性あり (補足事項は後述)

(※７) "direct mail" というのは転送やMLを経由 (indirect) して配送されたメールでないものを指していると想定 (補足事項は後述)

(※８) 補足事項は後述

サマリコメント

細かい点や気になった点については後述しますが、ざっくりと個人的なコメントです。

対象

  • Gmailでは、おなじみの@gmail.com (個人アカウント) が対象です。
  • 2023年12月時点で、Google Workspace (独自ドメイン) は対象外となりました。今後対象となる可能性はあります。
  • 米Yahoo (@yahoo.com) については、日本国内からたくさんメール送信するケースは少ないかと思います。

送信者として

  • 特に、bulk sender (Gmailでは5,000通/1日以上) 向けの要件が厳しくなるので、それなりにメール流量のある組織、あるいはメール送信サービス事業者は要チェックです。
  • あとは、転送やMLにより、組織外にメールを配送するケースについても、配送先がGmailとなり得る場合には考慮が必要となります。
  • 上記を考慮し、"重要なメールをGmail等に送信したが届かない" というケースが発生しないよう確認が必要です。
  • bulk senders に該当するかどうかの条件がヘッダFromアドレスの組織ドメイン単位、メール送信レートの制限はIPアドレス単位となるようです。

受信者として

  • Gmailをメインで使用している個人ユーザは、今回の変更を意識しておくと良いでしょう。
  • ただ、今回の追加要件は送信者向けのものなので、受信者 (Gmail等) としてできることは少ないです。
  • 後述の許可リストの設定も、絶対的なホワイトリスト効果があるとは限りません。
  • 一応、特定の送信者からのメールを受け取りたい場合は、その送信者のメールアドレスを予め連絡先に登録しておいたり、もし迷惑メールに分類されてしまったらそのメールを "迷惑メールでない" と選択したりすると、以降はその送信者からのメールが迷惑メールとして判定されにくくはなるようです。
  • 上記を考慮し、"重要なメールが届くはずだが受信できない" というケースが発生していないか注意が必要です (届いていないことに気付くのは難しいと思いますが)。

発表をとりまく環境

上記の発表について、関連する事柄を記載しておきます。

フィッシングの脅威

詐称メールを含む各種システムの不正利用によりフィッシングが発生しており、世界的にも大きな脅威です。



出典：Cloudflareの「2023年フィッシング脅威レポート」のご紹介

Googleや米Yahooを含め、多くのユーザを抱えるMBPにとって、このようなフィッシング対策を含めたメッセージングプラットフォームの安全性確保は重要な課題と言えます。

要件追加の目的

自らのユーザに届く不正なメールを減らし、experience を向上させるというスタンスです。

合わせて、送信ドメイン認証を正しく実装できていない送信者も多く、不正利用されている点を指摘しています。

Many bulk senders don’t appropriately secure and configure their systems, allowing attackers to easily hide in their midst.
　
出典：Gmail introduces new requirements to fight spam


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." と説明があります。

ガイドラインが既に更新されており、2022年11月時点の変更内容についての記載はもう残っていないようです。

とりあえず、以下のコミュニティ上のやりとりから、このタイミングで SPF または DKIM の設定が必須になったであろうという点は読み取れます。

2022年11月から、「Google Gmail アカウントにメールを送信する新規の送信者は SPF または DKIM の設定が必須になりました」とあり、
…
　
出典：多数のGmailアドレスにメールが送れない - Gmail コミュニティ

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つのベストプラクティス文書が該当するかと思います。

上記2つのうち、前者は電子メールのオプトインや購読解除について (後述のCAN-SPAM法とも関連) 、後者は "No Auth, No Entry" に関連する送信ドメイン認証あたりの内容です。

M3AAWG のベストプラクティス＝ベストチョイスかどうか

M3AAWG は、多くのメールサービス関連企業が参加している団体です。

取りまとめられたベストプラクティス文書は、業界の貴重な成果物だと思います。

そのベストプラクティスを実運用で再現しきることもまた、貴重なチャレンジでもある一方、常に最高の結果をもたらすベストチョイスかどうか、という点については様々な意見も出てくると思います。

少なくとも Gmail としてはこの要件を段階的に適用していくので、送信者 (や受信者) はうまく監視しつつ、メール配送への悪影響を抑えながらセキュリティ強化できれば建設的です。

(参考) FTCによるトランザクションメールとマーケティングメールの分類

最近、米国のFTC（連邦取引委員会）によって、CAN-SPAM法とトランザクションメール (とマーケティングメール) の定義を巡り、65万ドルの支払いを命じた裁判の事例がありました。

この、"トランザクションメール" と "マーケティングメール" という分類は、今回追加される要件や、DMARC等の送信ドメイン認証や、あるいはメール配信全般についてきちんと検討する際、考慮すべき点かと思います。

CAN-SPAM法において購読解除 (つまりオプトアウト) の対応が必須となるのは、"マーケティングメール" であり、今回のGmailの要件でも "Marketing messages and subscribed messages" と表現されています。

機会があれば、別記事にまとめます。

メール送信者が対応すべきこと

Googleのガイドラインに沿った対応としては、以下が考えられます (米Yahooも同様かと思います)。

  • 自組織のドメインから Gmail に送信されるメール流量の確認

  • Gmail の Postmaster Tools の利用、確認
    迷惑メール率の表示有無 = bulk sendersに該当するかどうからしい (詳細は実際にご確認を)

  • 要件を満たすよう対応するかどうか検討、実装

    • SFP、DKIM、DMARC、およびAlignment
    • (転送やMLでGmailに配送し得るなら) ARC対応、もしくは転送やMLの運用見直し
    • 自ドメインをヘッダFromとして送信する経路の洗い出し、整理
    • マーケティングメールに関し購読解除リンクの設置等
    • bulk sendersに該当するかどうかに関わらず、ベストプラクティスの実装に向けて検討 (送信者に対する要求が厳しくなるのは一般的な傾向)


  • Gmailへのメール配送状況のモニタリング継続

  • 意図せず正規のメール配送されない場合にはエスカレーション (後述)

  • (そもそも) 自組織のドメインやメール環境をどうしたいかをはっきりさせる

    • 自前 or 外部委託？

細かな留意点

実際に新たな要件が適用される (or された) 際に、注意しておいた方が良いと個人的に思った点をいくつか備忘用にメモします。

引用元は、ほとんどGmailのものです。

要件適用のタイムライン

FAQによると、bulk senders 向けの要件は段階的に適用されます。

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.
　
出典：Email sender guidelines - Gmail Help

FAQには、DMARC認証は、最終的な受信可否を決定するための重要な要素の1つであり、基本的に DMARC ポリシーに基づいて処理されると記載がありますので、(DMARC の範囲においては) "p=none" のとおりに扱ってくれるようです。

しかし、以下の DMARC 以外の要件によって、Gmail側がメールを受け取ってくれない可能性は十分にあります。

そもそもDMARCより厳しいという見方も

DMARCの認証成否に関わらず、以下の2つの必須要件がそれなりに厳しいです。

  • direct mail の ヘッダFrom が SPF or DKIM の認証対象ドメインと一致することを必須としている (DMARC Alignment 相当)

  • SPFとDKIMの両方を必須としている (SPF and DKIM)

前者は、通常の DMARC における Alignment と同等です (DKIMは作成者署名)。alignment はサブドメインまでの一致でなく組織ドメイン単位のようです (FAQ)。ただ、direct mail かどうかをどのように判断するのかは不明です (indirect mail かどうかの判断が難しいので、この要件は実際には検証されない可能性や、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 になっているSFPやDKIMをベースにした方針を明示することで、将来的な混乱を抑えつつ堅実にルール強化を進めようとしたのであれば、それは合理的だと思います。

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 以外にも、一般的な対策が説明されています。

例えば、メールが転送されても認証失敗しないよう、以下の対策も推奨されています。

  • SRS (Sender Rewriting Scheme) 的な処理 ("Change the envelope sender to reference your forwarding domain.")

  • 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の書き換えです。

転送やML配送をする際、SRS により SPF認証が pass (DMARC認証がpass) となるよう構成している送信者が、ARCヘッダを付与しないままGmailにメール送信した場合はどうなるのでしょう。

Gmail が受け取ったメールが indirect mail であるかどうかを判断する基準が、ARCヘッダの有無だけであれば、(転送やMLを経由したことに気付かれないので) 無事に配送されそうです。

逆に、もしARCヘッダ以外の何らかの要素から判断している場合、"転送やMLなのにARCヘッダが無い=要求を満たしていない" ということで配送されなくなるケースがあったりするかもしれません (ただ、それは必要以上の検証というか、手段が目的化している感もあります)。

この点は、実際そのように配送された際の結果を目にする機会が無いと分かりませんが。

ヘッダ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.
　
出典：Email sender guidelines - Gmail Help

迷惑メール率 (spam rates)

迷惑メール率は、0.3%未満を必須、0.1%未満を目指すよう記載されています。

Postmaster Toolsにて確認できるようです。

迷惑メール率の集計期間は、日次です (FAQより)。

注意点は以下です (FAQより)。

  • 0.1%を超えるとメール配送に悪影響 (a negative impact on email inbox delivery) がある

  • 0.3%を超えると、後述の mitigations の申請を行う資格を失う

しきい値ピッタリでなく、段階的な影響となるようですが、0.3% だけでなく 0.1% の方も意識した方が良い気がします。

共有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.
　
出典：Email sender guidelines - Gmail Help

1クリックでの購読解除の要件

1クリックでの購読解除を実装する際のメールヘッダについて解説があります。

以下のRFCが参照されています。

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/example
　
Learn more about List-Unsubscribe: headers in RFC 2369 and RFC 8058.
　
出典：Email sender guidelines - Gmail Help

1クリック購読解除の実装は2024年6月1日まで猶予

既に購読解除リンクをメッセージ内に設置できている送信者は、2024年6月1日までに1クリック購読解除に対応する必要性があります(FAQより)。若干猶予があると言えばあります。

配信停止リンクが長期間機能していない場合

配信停止リンク (おそらくリンク先のWebサーバ) が長期間機能していない場合、要求を満たしていないことになります。

迷惑メールとして扱われることはないようですが、後述の mitigations の申請を行う資格を失います (FAQより)。

1クリックという性質上、Googleが勝手にリンク先にアクセスすることは無いはずなので、どのように判断するのか、詳細は不明です。

(米Yahoo) Web (https:) でなく mailto: もサポート

米Yahooの方にも同様の説明がありますが、さらに List-Unsubscribe: ヘッダの値として、mailto: もサポートする旨が明記されています。

Of course we support “mailto:” unsubscribe headers as well.
　
出典：Subscription Hub, Mail | Yahoo Developer Network

購読解除要求を2日以内に処理できているかの確認や実装

購読解除要求を2日以内に処理することが要件として挙げられていますが、全ての購読解除要求に対し、本当に2日以内に処理できているかどうかをGoogleや米Yahooが確認することは不可能です。

実際の運用がどのようになるかは不明です。

一応、細かく考えると、MBPが提供するWebメールシステムや専用アプリ上で表示させたメール内の購読解除リンクのクリックを経由した要求であれば (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
　
出典：Email sender guidelines - Gmail Help

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.
　
出典：Email sender guidelines - Gmail Help

異なる送信先ドメインのメール通数を合算

メール送信レートについては、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.
　
出典：Email sender guidelines - Gmail Help

※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.
　
出典：Email sender guidelines - Gmail Help

あとは、送信しながら、サーバーのレスポンス、迷惑メール率、送信元ドメインの評価を定期的に監視するよう記載があります。

送信元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 アドレスからのメール送信を制限します。
　
出典：メール送信者のガイドライン - Gmail ヘルプ

その他

その他、気になった点を記載しておきます。

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 の送信ガイドラインに準拠していません。）
　
出典：メール送信者のガイドライン - Gmail ヘルプ

メール送信を制限されたら、是正して少しずつ再開

今回の追加要件に限らず、メール送信を制限された場合についてです。

具体的な記載はさっと見つかりませんが、エラーがあればその内容や、ガイドライン等に沿って対処の上、しばらく時間を置いてから、また制限されないように少しずつ、メール送信を再開することになるのかと思います。

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.
　
出典：Email sender guidelines - Gmail Help

上記では、Google Admin Toolboxの使用について言及されています。

送信者向けのエスカレーションルート

送信者は、ガイドラインの要件を満たしていれば、Gooleに対し mitigations の申請が可能です (FAQより)。

満たしていない場合には、不可です。

mitigations の申請は、Sender Contact Form から行うことができます。

このフォームの説明を読む限り、ユーザから報告されている迷惑メール率が低いにもかかわらず、迷惑メールに分類されるケースが多い場合に、受信制限を緩和するようリクエスト (審査要求) ができるようです。

この申請が通ると、一時的に強制的なスパム振り分けが無効化されるようです。その後、ガイドラインに沿ってメールが送信されていればメール配送の問題は発生しないようになるはずと説明されています。

なお、送信者から許可リスト申請という形では受け付けていないそうです (後述)。

既存機能、関連仕様

新たに適用される要件が、既存機能とどのように関連するかについての考慮も要りそうです。

実際に適用された後に様子を見るしかないと思いますが…。

許可リストが上記の制限より優先されるか

Gmailには許可リスト機能があります。

しかし、今回の追加要件を含めたポリシーより優先されるとは限らないようです。

注: Gmail で疑わしいメールとして識別された場合は、送信者が許可リストに含まれていても、そのメールは拒否される、または迷惑メールに分類される可能性があります。
　
出典：Gmail で正当なメールが迷惑メールに分類される - Google Workspace 管理者 ヘルプ

補足として、以下はメールプロバイダからの許可リスト登録は受け付けていないという記載です。

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.
　
出典：Email sender guidelines - Gmail Help

(参考) GmailのSFP検証に関する独自仕様？

参考情報として、さくらインターネットの記事へのリンクを記載しておきます。

Gmailへの転送が失敗するケースについて、GmailではSFP検証の際、送信者と転送者がSFPレコードに含まれているかを検証するという独自仕様について記載されています。

※そのような独自仕様があるらしいという点を参考情報として記載しました。ただ、上記記事の文中にある "本来、メール転送時のSPF確認はメールの送信元（例図ではexample.com）にのみ行われます。" の部分については、SFP本来の記載ではないような気がするので (SMTP Fromアドレスに変更が無ければ転送者のIPアドレスをチェックするはず)、あるいは何か別の前提があるのか、よく分かりませんでした。


また以下のように、トラブルシューティングに関する記事も充実しています。

実際、Gmail側でも以下のように転送者も含めてSPFレコードに登録するよう案内されています。

※なお当然ですが、信頼できない転送者をむやみにSFPレコードに登録してはいけません

転送されたメールが迷惑メールに分類されないようにする
…
ドメインの SPF レコードに、ドメインのメールを転送するすべてのサーバーまたはサービスの IP アドレスまたはドメインが含まれるようにする。
　
出典：メールを Gmail に転送するおすすめの方法 - Gmail ヘルプ

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 から発表された、メール送信者向けのルール強化についてまとめてみました。

電子メールは長く使われている技術ではありますが、まだ変わっていく点が多そうです。

参考情報

happy-nap.hatenablog.com