セミナー「Gmail新ガイドラインのポイントを解説!メール送信者が今やるべきこと」を開催しました!(本編)

セミナー「Gmail新ガイドラインのポイントを解説!メール送信者が今やるべきこと」を開催しました!(本編)

12月7日に続き、1月22日に開催したオンラインセミナー「Gmail新ガイドラインのポイントを解説!メール送信者が今やるべきこと」。ありがたいことに、どちらの回も大変多くの方にご視聴いただきました。
本記事では、1月22日のセミナーで語られた内容に沿って、ガイドラインのポイントを細かく紹介いたします。

Gmailのガイドラインとは?

2023年10月、GoogleYahoo!(Yahoo! JAPANではありません)からメール送信者向けのガイドラインを更新した旨のアナウンスがありました。このガイドラインは2024年2月から段階的に適用されることになっており、それまでにガイドラインの更新に対応できなければメールが宛先に届かなくなる可能性があります。

2社が求める要件は共通しています。内容をざっくりまとめると、その主旨は実にシンプルです。

  • Authentication & Trust(認証と信頼)
    • 誰が送ったメッセージなのかを明確にすること
    • 安全で信頼できる方法で送信すること
  • Easy Unsubscribe(簡単な配信停止)
    • 受信者が必要としているメール(=読まれるメール)を送信すること
    • 受信者自身が送信者との関係をコントロールできるようにすること

受信者の気持ちになってみれば納得の内容ですね。本記事はGoogleの発表内容(メール送信者のガイドラインよくある質問)に沿って詳しくご紹介します。

ガイドラインが変更される背景

悪意のある送信者から受信者を守るため、ガイドライン自体は以前から存在していました。しかし、その位置づけは「推奨」であり「強制」ではなかったため、実際にはなかなか普及が進みませんでした。
その間もフィッシングメールは増加の一途をたどり、被害も増え続けています。このような事態を重く見て、とうとうガイドラインの内容が強制化されることになりました。これが今回の変更の背景です。

GoogleもYahoo!も、特別な仕組みが必要となるような対応を求めているわけではありません。広く使われている標準的な方法で、悪意のあるメールを減らしメールエコシステムを健全化しようとしているのです。
もちろん、皆さん正当なメールを送信されていることとは思いますが、それを”客観的に判断できる”ようにするというのがこのガイドラインの要件です。

適用のタイムライン

アナウンス当初は、2024年2月の時点で全ての要件に対応しておく必要があるものと思われましたが、その後のアップデートで、要件は段階的に適用され徐々に厳しくなっていくことがわかりました。

  • 2024年2月
    要件を満たしていないメールのうち、ごく一部のメールで一時的なエラーが返されるようになる。
  • 2024年4月
    要件を満たしていないメールのうち、一部のメールが拒否され始める。拒否されるメールの割合は徐々に大きくなる。
  • 2024年6月
    全てのマーケティングメールでワンクリック配信停止に対応している必要がある。

一括送信者(bulk senders)の定義

ガイドラインの適用対象となる「一括送信者」の定義も明らかになってきました。

  • 一括送信者とは、Google Workspaceを除いたGmailアカウント(gmail.comおよびgooglemail.com)に対し、24時間あたり5,000通程度以上を送信する送信者を指す
  • 同じプライマリドメインからのメール全てが同じ送信者からのメールとしてカウントされる
    • 例えば、@example.comから3,000通、@sub.example.comから2,500通送った場合、5,500通とカウントされる
    • メールの種類(トランザクションメール、マーケティングメール)や送信経路(Twilio SendGrid、CRMツールなど)にかかわらず、全てのメールがカウント対象
  • ⼀度でも⼀括送信者とみなされればその後も⼀括送信者とみなされ続ける
    • 「一括送信者」のステータスに有効期限はない

以前はメールの種類によってサブドメインを分ければ別カウントになるのでは?と推測されていましたが、その方法ではカウントは分けられず、また、一度でも一括送信者だと判断されれば今後リセットされることはありません。

この定義を厳しいと思う方もいるかもしれませんが、ガイドラインの内容はいずれもメール送信におけるベストプラクティスです。メール送信者としてあるべき姿を実現するために、宛先ドメインや送信規模にかかわらずガイドラインに対応しておくことを強く推奨します。

ガイドラインの内容

具体的には以下の要件を満たすことが求められています。

1.送信ドメインでSPFとDKIMを設定しましょう

SPFは、送信者が「この差出人からのメールはこのIPアドレスから送信します」という情報をDNSサーバに公開することで、メールが正当なサーバから送信されていることを確認できる仕組みです。

DKIMは、送信者が「この差出人からのメールに付けられた電子署名は、この公開鍵を使って検証してください」という情報をDNSサーバに公開することで、メールが正当なサーバから送信され、改ざんもされていないことを確認できる仕組みです。

いずれも、認証結果に基づいてメールをどう扱うか決めるのは受信サーバです。

SPFとDKIMの仕組

2.DMARCを設定しましょう

DMARCは、送信者が「この差出人から送られたメールがSPF/DKIMの認証に失敗した場合は、このように扱ってください」という指示(=ポリシー)をDNSサーバに公開する仕組みです。
SPF/DKIMとは違い、メールをどう扱うかを決めるのは送信者です。

DMARCの仕組み

ポリシーには以下の3種類があり、下に行くにつれてだんだん厳しくなります。

  • p = none:何も求めない(送信者側としては特に指示せず、受信サーバに判断を任せる)
  • p = quarantine:隔離(受信トレイには格納せず、スパムフォルダに振り分けるよう指示する)
  • p = reject:拒否(無条件で破棄するよう指示する)

Gmailの新ガイドラインでは、p=none を設定すれば良いとされています。一方、Yahoo!は、DMARCレコードに rua タグを付与してDMARCレポートを受け取ることを「強く推奨」しています。なりすましに利用されているものを含めドメインの利用状況がすべて把握できるため、忘れずに rua タグを設定しましょう。DMARCレコードの各タグについてはこちらを参考にしてください。

DMARC導入のベストプラクティス

DMARCを導入する際は、以下の流れで実施すると良いでしょう。

  1. SPFとDKIMを正しく設定する
  2. p=noneでDMARCレコードを設定する(必ずSPF、DKIM、DMARCのドメインは統一する)
  3. フィードバック(DMARCレポート)を受け取り、把握しきれていない経路のメールや設定誤りがないかをチェックする
  4. SPF、DKIM設定に抜け漏れや誤りがあった場合は修正する
  5. ポリシーを段階的に引き上げる(p=quarantineからrejectへ)

DMARCは同じドメインから送信する全てのメールに影響を与えます。そのため、いきなりポリシーを厳しく設定するのではなく、まずはp=noneで設定してDMARCレポートで現状を把握し、問題がないと判断できてから徐々に厳しくしていきます。

なお、プライマリドメイン、サブドメインそれぞれに別のDMARCポリシーを設定することができます。サブドメインのポリシーが設定されていない場合はプライマリドメインの設定が継承されるので、サブドメインの利用状況も把握したうえで適切なポリシーを設定しましょう。

3.ヘッダFromドメインはSPF、DKIMドメインと一致させましょう

これらが一致していないとDMARCアライメントにPassできなくなり、メールが受信トレイに届かなくなる可能性があります。

4.ヘッダFromにGmailのドメインを指定してはいけません

現在のGmail、Yahoo!、Twilio SendGridのDMARC設定は以下のようになっています。

Twilio SendGrid DMARCの設定

Gmailでは p=none のポリシーが設定されていますが、新ガイドライン適用にあたり p=quarantine に変更することが宣言されました。
これにより、今後は@gmail.comのアドレスを差出人にしてメールを送信すると、受信トレイに届かなくなります。

5.送信元ドメイン、IPアドレスに対し、有効な正引き、逆引きDNSレコードを設定しましょう

送信元ドメインのAレコードから送信元IPアドレスを参照できるようにし(正引き)、逆に送信元IPアドレスのPTRレコードから送信元ドメインを参照できるようにする(逆引き)必要があります。
IPアドレスとドメインの紐付きが双方向で一致すれば、正当な送信者である証明になるという理屈です。

6.メーリングリスト等、転送する場合はARCヘッダを追加しましょう

SPFとDKIMは、認証の仕組み上、メールが転送されたり転送時にメッセージが書きかえられたりすると認証に失敗してしまいます。ARCヘッダは、転送前に行われた認証の結果を転送後も確認できるようにするもので、これにより、転送されたメールでもSPFとDKIMの判定が正しくできるようになります。
メーリングリストやメールボックスプロバイダの自動転送機能などを提供されている場合にはARCヘッダを追加しましょう。

SendGridを使ってメールを送信しているだけであれば対応は不要です。

メーリングリスト宛の送信

7.ワンクリックでの配信停止に対応しましょう

配信停止はワンクリックで簡単に行える必要があります。具体的には、RFC 8058に従い、メールヘッダに List-Unsubscribe-PostList-Unsubscribe を含めましょう。

メールヘッダ

これらのヘッダを挿入してメールを送ると、受信メールの「To」フィールドの隣のドロップダウンメニューにハイパーリンクが表示されるようになります。

配信停止

配信停止を希望する受信者がこのハイパーリンクをクリックすると、ヘッダ内で指定されたURLまたはメールアドレス宛に配信停止のリクエストが送信されます。
したがって、配信停止リクエストを受け付ける仕組みも併せて準備する必要があります。

なお、この要件は、マーケティング目的のメール(ニュースレターやメールマガジンなど)を送信する場合に満たす必要があるもので、トランザクションメール(パスワードリセットメールや予約確認の通知メールなど)の場合は対象外とされています。

また、メール本文内の配信停止リンク設置だけでは要件を満たすことはできない点に注意してください。

List-Unsubscribeヘッダの詳細についてはこちらもご覧ください。

8.迷惑メール率は0.1%未満に維持し、0.3%を超えることは避けましょう

迷惑メール率は低く保ちましょう。値の確認にはGoogle Postmaster Toolsが有用です。このツールでは送信ドメイン認証の結果なども参照できるため、定期的に確認し推移を把握することをおすすめします。

Google Postmaster Toolsでのアカウント確認

迷惑メール率を下げるためには「メールを受け取りたいと望んでいる人のみに送る」ことが徹底されているか、具体的には以下が達成できているかを確認しましょう。

  • オプトインをとり、明確にメールを望んでいる宛先にのみ送信する
  • Sunset Policyを定め、一定期間メールが開封やクリックされていない宛先を配信リストから除外する

9.RFC 5322に準拠する形式で送りましょう

RFC 5322はメールの正式なフォーマットを定義するインターネット標準です。メッセージヘッダやボディ、添付ファイルのフォーマットについて定義されています。基本的な作法はしっかり守りましょう。

10.送信経路にはセキュア通信(TLS)を利用しましょう

TLSとは、プライバシーを保護するためにメールを暗号化するセキュリティプロトコルです。TLS接続を確立するには、送信側と受信側双方がTLSに対応している必要があります。メールへの不正アクセスを防ぐために、必ずTLSを利用しましょう。GoogleはTLSバージョン 1.0、1.1、1.2、1.3に対応しています。

よくある質問(FAQ)のアップデート

ガイドラインに関する詳細情報はFAQにまとめられています。ガイドライン本体だけでなくこちらも定期的にチェックしましょう。
直近で新たに追記された主要な項目を紹介します。

Q.マーケティングメールとトランザクションメールの見分け方は?

マーケティングメールに該当するかどうかの判断はGoogleではなく受信者が行うとのことです。少し曖昧な回答ではありますが、ワンクリックの配信停止や低い迷惑メール率の維持を徹底するのが重要だということのようです。

Q.ワンクリックの配信停止に対応していないマーケティングメールはどうなるのか︖

ガイドラインの要件を満たしていない場合でも、メールが自動的に受信拒否されたりスパム扱いされたりはしないとのこと。直ちに影響はないと思われますが、

  • このようなメールは迷惑メール報告されやすいと考えられるため、いずれは受信トレイに届かなくなる可能性がある
  • Googleは、要件をすべて満たしている送信者へのサポートを優先的に行う

という記述もあるため、要件には対応しておくのが望ましいと考えられます。

誰が手を動かせばいいのか

ガイドラインを見るとわかるとおり、送信者認証などの事前設定をすれば終わりではありません。メール送信時、送信後に注意すべきことも要件に含まれています。すべての要件を満たすために、エンジニア、送信担当者の双方で協力しあいましょう。

エンジニアとマーケターの対応

SendGridで対応可能な項目

SendGridの機能などで対応可能なものは以下のとおりです。

  • 送信ドメインでSPFとDKIMを設定しましょう(参考
    • Domain Authenticationの設定画面にDMARC用のTXTレコードが表示されますが、これはあくまで必要最低限の設定例を参考情報として表示しているものです。DMARCは当該ドメインを利用する全てのメール(SendGrid以外からの送信を含む)に影響を与えるため、設定は慎重に行ってください。
    • DMARCは送信メールに何らかの設定を行うものではなく、送信元ドメインのDNSサーバにレコードを追加するものであるため、DMARCレコードの設定内容に関しては弊社サポートの対象外です。
  • ヘッダFromドメインはSPF、DKIMドメインと一致させましょう(参考
  • 送信元ドメイン、IPアドレスに対し、有効な正引き、逆引きDNSレコードを設定しましょう(参考
    • Reverse DNSが利用できるのは、固定IPアドレスが利用可能なProプラン以上のアカウントです。Free/Essentialプランのアカウントでは、独自ドメインではなくsendgrid.netドメインで逆引き設定されています(ガイドラインではメールのFromドメインと逆引きドメインが一致すべきかまでは言及されていません)。
  • ワンクリックでの配信停止に対応しましょう(参考
    • SendGridの配信停止機能を利用すると自動的にList-Unsubscribeヘッダが挿入され、配信停止リストの管理もSendGridで行えます。なお、現時点ではRFC8058に完全には準拠できていないことが確認されていますが、2024年3月中に対応できるよう改修を進めています。
  • RFC 5322に準拠する形式で送りましょう(参考
    • SendGridを利用していれば、特に対処は必要ありません。
  • 送信経路にはセキュア通信(TLS)を利用しましょう(参考
    • SendGridを利用していれば、特に対処は必要ありません。

おすすめのチェックツール

一通り設定した後は、それらが正しく適用されているかを確認する必要があります。その際に役立つツールをご紹介します。

dmarcian

送信者認証用のレコード(SPF、DKIM、DMARCレコード)が正しく設定されているかを診断してくれるツールです。

dmarcian

mail-tester

実際にメールを送ることで、送信者認証の設定状況の他、迷惑メール度合いを判定してくれます。使い方はこちらをご覧ください。

mail-tester

本編では送信者が対応すべき内容について細かく解説しました。既に述べたとおり、ガイドラインは頻繁に更新されているので、定期的にチェックしましょう!

ウェビナー当日に寄せられたご質問には以下の記事で回答していますので、あわせてご覧ください!

アーカイブ

メールを成功の原動力に

開発者にもマーケターにも信頼されているメールサービスを利用して、
時間の節約、スケーラビリティ、メール配信に関する専門知識を手に入れましょう。