Gmail メール送信者のガイドライン変更に備える話

2023/10 に発表された **Gmail [メール送信者のガイドライン](https://support.google.com/mail/answer/81126)変更** に関する話です。

https://support.google.com/mail/answer/81126?hl=ja

日本では、[こちらの IIJ のブログ記事](https://eng-blog.iij.ad.jp/archives/21788)が出たことで話題になりましたね。

https://eng-blog.iij.ad.jp/archives/21788

ざっくりいうと、

- **2024/02 以降、Gmail（~~Google Workspace を含む~~）のアカウントに対して 5,000 通／日以上のメールを送信する場合、SPF・DKIM・DMARC への対応が必須になる**

という話です。

:::note warn
**2023/12/04 追記（12/25 修正）：**
Google から[追加のアナウンス（FAQ）](https://support.google.com/a/answer/14229414#zippy=%2C%E9%80%81%E4%BF%A1%E8%80%85%E3%81%AE%E3%82%AC%E3%82%A4%E3%83%89%E3%83%A9%E3%82%A4%E3%83%B3%E3%81%AF-google-workspace-%E3%82%A2%E3%82%AB%E3%82%A6%E3%83%B3%E3%83%88%E3%81%8B%E3%82%89%E9%80%81%E4%BF%A1%E3%81%95%E3%82%8C%E3%82%8B%E3%83%A1%E3%83%BC%E3%83%AB%E3%81%AB%E3%82%82%E9%81%A9%E7%94%A8%E3%81%95%E3%82%8C%E3%81%BE%E3%81%99%E3%81%8B)が公開され、Google Workspace アカウント宛てのメール送信は対象外であることが明記されました。

- **[メール送信者のガイドラインに関するよくある質問](https://support.google.com/a/answer/14229414)**

> 送信者のガイドラインは Google Workspace アカウントから送信されるメールにも適用されますか？
> > 個人の Gmail アカウントにメールを送信する場合、Google Workspace ユーザーを含むすべての送信者がメール送信者のガイドラインの要件を満たしている必要があります。この要件は、Google Workspace の受信メールとドメイン内のメールには適用されません。

:::

[blastengine](https://blastengine.jp/) を有料プランで利用中のユーザには、すでにメールでアナウンスがあったのでご存知かと思います。

また、[ガイドライン](https://support.google.com/mail/answer/81126)にはその他の注意事項もいくつか記されています。

この記事では、[前述のガイドライン](https://support.google.com/mail/answer/81126)に沿った対応をする際のポイントについて **完全に個人の独断で** 記していきます。

:::note warn
この記事では、SPF・DKIM・DMARC の設定方法そのものの解説は行いません。
お使いのメール送信サービスのマニュアルを確認するか、以下の Gmail（Google Workspace）ヘルプなどを参照してください。

- **[なりすまし、フィッシング、迷惑メールの防止を支援する](https://support.google.com/a/topic/9061731?hl=ja)（Google Workspace 管理者 ヘルプ）**
:::

## いきなりまとめ

- **SPF・DKIM・DMARC レコードを設定したら、設定内容を必ずチェックする**
  - ツールを使って各レコードをチェックする
  - 実際の環境で Gmail 宛て（あわせて他のメールサービス宛て）にメールを送信して　SPF・DKIM・DMARC が PASS していることを確認する
  - [Postmaster Tools](https://postmaster.google.com/managedomains?pli=1) で監視する
- **DMARC を「初手`p=none`」のまま放置しない**
- **メールフォームを設置・運用している場合は、メールの送信形式と悪用に気を付ける**
  - [RFC5322](https://datatracker.ietf.org/doc/html/rfc5322) に準拠する
  - 迷惑メールの送信に悪用されないようにする
- **マーケティング目的のメールはワンクリックで配信停止できるようにする**
  - `List-Unsubscribe-Post`・`List-Unsubscribe`ヘッダを含めて送信する
  - その他の方法で受信者が容易に配信登録を解除できるようにする

## SPF・DKIM・DMARC レコードを設定したら、設定内容を必ずチェックする

SPF・DKIM・DMARC の各レコードを登録したら、その内容が正しいことを必ずチェックします。

### ツールを使って各レコードをチェックする

例えば、レコードのチェックには次のようなツールが利用可能です。

- **[PowerDMARC・SPF チェッカーツール](https://powerdmarc.com/ja/spf-record-lookup/)**

https://powerdmarc.com/ja/spf-record-lookup/

- **[同・DKIM レコードチェッカ](https://powerdmarc.com/ja/dkim-record-lookup/)**

https://powerdmarc.com/ja/dkim-record-lookup/

:::note
**実行例：**

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/123899/66bb48df-80d6-20cb-af61-f743b600b974.png)
:::

- **[同・DMARC チェッカーツール](https://powerdmarc.com/ja/dmarc-record-checker/)**

https://powerdmarc.com/ja/dmarc-record-checker/

- **[MxToolBox](https://mxtoolbox.com/NetworkTools.aspx)**

https://mxtoolbox.com/NetworkTools.aspx

:::note
**spf 実行例：**

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/123899/17721aca-63aa-fbf9-fe6c-d6964e25411b.png)
:::

個人的には、特に以下の点に注意が必要だと考えています。

#### SPF レコードの DNS ルックアップ回数超過

SPF では、送信者のドメイン認証を行う際、DNS への問い合わせ（ルックアップ）が 1 件につき 10 回までに制限されています（[RFC7208](https://datatracker.ietf.org/doc/html/rfc7208)）。

https://datatracker.ietf.org/doc/html/rfc7208#section-4.6.4

近年では、マーケティング目的のメールを専用のクラウドサービスを利用して送信するケースが多いですが、その場合 SPF レコードに`include`を使用して送信元を追加していく関係で、どうしてもルックアップ回数が多くなります。

加えて、そのようなメールサービスでは`include`した先の SPF レコードの内容がたびたび変更されるため、月に 1 回など定期的にチェックしていないと、知らないうちにルックアップ回数が 10 を超えてしまっていることもあります。

また、ルックアップ回数が 10 を超えたからといって、直ちにすべての宛先でメールが届かなくなるとは限らないので、うっかりしていると気づかない可能性もあります。

1 つのドメインで複数のメール送信サービスを利用している場合は特に注意が必要です。

#### 2,048 ビット（以上）の DKIM 公開鍵登録ミス

DNS のレコードに文字列を登録する際、**1 つの文字列は 255 文字まで** の制限があるケースが多いのですが、DKIM の公開鍵を（Base64 エンコーディングして）登録する場合 2,048 ビット鍵では 255 文字を超えてしまいます。

その場合、[文字列を引用符で囲んで分割すれば良い](https://support.google.com/a/answer/11613097?hl=ja)のですが、単純にコピペする場合と比べるとコピペミスする可能性が高くなります。

https://support.google.com/a/answer/11613097?hl=ja

:::note warn
**2023/12/13 追記：**
逆に、鍵生成に OpenDKIM を使う場合は最初から分割された書式で生成されるため、例えばお名前.com の DNS レコード設定など引用符も分割も不要な書式で登録すべきケースでは、引用符を除外して単一の文字列に変換する必要があります。
:::

### ツールでチェックしたら、実際に受信して確認する

実際に Gmail で受信し、**メッセージのソースを表示** で SPF・DKIM・DMARC が PASS していることを確認します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/123899/842d2ab0-be6e-f519-4900-37dcaa3325f6.png)

（あわせて他のメールサービスでも受信して確認します）

:::note warn
**2023/12/13 追記：**
DMARC については、ツールによるレコードのチェックは即時に実施可能ですが、実際にメールを送信して PASS の確認が可能になるまでには時間が掛かることがあります。

例えば、Gmail の場合は[こちらの注意書き](https://support.google.com/a/answer/2466563?hl=ja)にあるように、SPF・DKIM レコード登録後 48 時間以上経過してからでないと DMARC の PASS 確認ができません。
（[注意書き](https://support.google.com/a/answer/2466563?hl=ja)には「SPF・DKIM レコード登録後 48 時間以上経ってから DMARC レコードを登録するように」という趣旨の文章が書かれていますが、SPF・DKIM レコードと同じタイミングで DMARC レコードを登録してしまった場合も、PASS 確認ができるまでにタイムラグがあります）
> DMARC を設定する前に、DKIM（DomainKeys Identified Mail）と SPF（Sender Policy Framework）を設定してください。DMARC を有効にする 48 時間以上に、DKIM と SPF でメールを認証している必要があります。
:::

### [Postmaster Tools](https://postmaster.google.com/managedomains?pli=1) で監視する

SPF・DKIM・DMARC の運用を開始したら、Google の [Postmaster Tools](https://postmaster.google.com/managedomains?pli=1) でメール送信状況を監視します。

https://support.google.com/mail/answer/9981691?hl=ja

迷惑メール率が 0.10% 未満に維持されることを目指すとともに、**0.30% 以上の状態が継続的に発生しない** ように注意します。

## DMARC を「初手`p=none`」のまま放置しない

:::note warn
**2023/12/13 追記：**
この項目については **2024/02 時点で達成できている必要はありません** が、今後の動向を考えると当然に意識しておく必要があります。
:::

DMARC を`p=none`で登録しても、**「メールの送信が SPF または DKIM の指定に従っていなくても DMARC のチェックは PASS させる」** という意味ですので、受信者にとっては「DMARC レコードが登録されている」以上の（「信頼できる送信者である」と判断する上での）意味はありません。

そのため、2024/02 時点ではとりあえず Google が求める要件をパスしたとしても、それ以降も高い評価が維持されることは保証されません。

いずれ、DMARC 本来のチェックが機能するように **`p=quarantine`（検疫）または`p=reject`（拒否）を指定して、メールの送信が SPF・DKIM の指定に従っていない場合は検疫または拒否するポリシーに変更する** 必要があります。

https://support.google.com/a/answer/10032169?hl=ja

なお、その際「`pct`タグの値を`0`から`100`に徐々に上げていき、ポリシーどおりにチェックする割合を上げる」という方法が（仕組みの上では）可能になっていますが、

- `0`の指定は Gmail では指定範囲外
  - どう解釈されるか不透明
- `1`〜`99`の指定は受信側サーバで正しく使用されないケースがある

ため、実質的に`pct=100`以外の指定を取るのはリスクがある（想定どおりの動きにならない可能性がある）といえるでしょう。

このようなこともあり、現在ドラフト段階の DMARCbis では`pct`タグの代わりに`t`タグが提案されているようです。

- **[DMARC の "pct" は DMARCbis で "t=" に置き換えられる](https://maildata.jp/blog/blog-2023-11-13.html)（MailData ブログ）**

## メールフォームを設置・運用している場合は、メールの送信形式と悪用に気を付ける

ここからは SPF・DKIM・DMARC 必須化の話からは外れますが、メールの送信ドメインの評価を下げないようにしてメールの到達率を高い状態に保つための話です。

自社の Web サイトに問い合わせフォームを設置して登録された内容をメール送信している場合、送信内容が [RFC5322](https://datatracker.ietf.org/doc/html/rfc5322) に準拠しているか（ヘッダなどの過不足がないか）に注意します。

https://datatracker.ietf.org/doc/html/rfc5322

さらに、

- Perl・PHP などのメール送信スクリプトが使用されている場合、フォーム以外からの送信に悪用されないようにする
- フォームからのメール送信が、いたずらや広告など別の目的に悪用されないようにする
  - メール送信前に登録内容を適切にチェックする
  - 場合によっては登録内容そのもののメール送信をやめる
    - 登録者へのフィードバック機能は、登録者のメールアドレスを詐称される可能性が高いので、ログイン（認証）不要の Web ページには極力実装しない
- bot からの登録を防ぐために、[reCaptcha（v3）](https://www.google.com/recaptcha/about/) や [Turnstile](https://www.cloudflare.com/ja-jp/products/turnstile/) などを組み込む

https://www.google.com/recaptcha/about/

https://www.cloudflare.com/ja-jp/products/turnstile/

などの対策を講じます。

## マーケティング目的のメールはワンクリックで配信停止できるようにする

[前述のガイドライン](https://support.google.com/mail/answer/81126)にも記されているとおり、[RFC2369](https://datatracker.ietf.org/doc/html/rfc2369)・[RFC8058](https://datatracker.ietf.org/doc/html/rfc8058) で規定されている`List-Unsubscribe`・`List-Unsubscribe-Post`両ヘッダをメールに組み込んで、ワンクリックで配信解除できるようにします。

https://datatracker.ietf.org/doc/html/rfc2369

https://datatracker.ietf.org/doc/html/rfc8058

~~または、その他の方法（仕組み）で受信者が容易に配信登録を解除できるようにします。~~

:::note warn
**2023/12/25 追記：**
[前掲の FAQ](https://support.google.com/mail/answer/14229414#zippy=%2C%E3%83%AA%E3%82%B9%E3%83%88%E3%81%AE%E3%83%98%E3%83%83%E3%83%80%E3%83%BC%E3%81%8C%E3%81%AA%E3%81%84%E5%A0%B4%E5%90%88%E3%83%A1%E3%83%BC%E3%83%AB%E6%9C%AC%E6%96%87%E3%81%A7%E3%83%AF%E3%83%B3%E3%82%AF%E3%83%AA%E3%83%83%E3%82%AF%E3%81%AE%E7%99%BB%E9%8C%B2%E8%A7%A3%E9%99%A4%E3%83%AA%E3%83%B3%E3%82%AF%E3%82%92%E7%A2%BA%E8%AA%8D%E3%81%97%E3%81%A6%E3%81%84%E3%81%BE%E3%81%99%E3%81%8B) の記述（[RFC8058](https://datatracker.ietf.org/doc/html/rfc8058) に準拠する必要がある）にあわせて削除しました。

:::

送信したメールが（受信者によって）迷惑メールとして報告されないようにするのが重要です。

## その他

こちらも[前述のガイドライン](https://support.google.com/mail/answer/81126)に記されているとおり、通知など他の目的のメールの本文にプロモーション目的の内容を含めないよう注意が必要です。

人によっては、メールのフッタに（本文とは無関係の）宣伝目的の文章や URL を常時含めて送信しているケースがありますが、そのようなことは送信者のドメインの評価を下げ、メールが正しく届かないリスクを上げるので、避けたほうが良いでしょう。

---

以上、対応のポイントについて記しました。

SPF のルックアップ回数にしても迷惑メール率にしてもそうですが、スポット的な対応だけではなく、継続的な監視や対応が必要ですね。

---

明日（2 日目）は satodaisuke さんです。

- **[メール本文のハイパーリンクとドメインの難しい関係](https://qiita.com/satodaisuke/items/b60863b2be25ff87eb60)**

https://qiita.com/satodaisuke/items/b60863b2be25ff87eb60

---

**2023/12/04 追記：**
同じチームのメンバーが、当 Advent Calendar に記事を投稿しました。

- **[blastengineを使い始めて便利だった点](https://qiita.com/yoyoyo_pg/items/f128a2e2dbd78be84f74)**

https://qiita.com/yoyoyo_pg/items/f128a2e2dbd78be84f74

なお、blastengine の検証を実施したときの記事はこちらです。

- **[blastengine で送信したメールの Bounce Event を取得するサンプル](https://qiita.com/hmatsu47/items/e6e8fc9290eede7c8a55)**

https://qiita.com/hmatsu47/items/e6e8fc9290eede7c8a55