Zenn
FOLIOPublicationへの投稿
📧

Gmailのガイドライン発表で行ったこと

yaizuuuu
2024/02/16に公開
AWS
Gmail
tech

2023年10月にGoogleから発表された「メール送信者のガイドライン」で行ったことをまとめました。

要約すると以下のようなことを行いました。

  1. 「メール送信者のガイドライン」内容と準拠状況を確認
  2. SPF, DKIM, DMARCのおさらいと対応方法
  3. メール送信に関する技術について勉強会

「メール送信者のガイドライン」内容と準拠状況を確認

まずガイドライン発表が行われたのちに内容を確認して要約しチーム内にシェアをしました。

メール送信者のガイドラインは以下です。

https://support.google.com/a/answer/81126

ガイドラインの重要なポイントを要約すると以下になります。

  • Gmailアカウントに1日あたり5000件を超えるメールを送信する場合は以下を守る必要がある
  • ドメインにSPF及びDKIMを設定する
  • Postmaster Toolsで報告される迷惑メール率を0.30%以上にならないようする
    • 迷惑メール率を0.10%未満が望ましい
  • 送信ドメインにDMARCを設定する
  • マーケティングを目的したメールではワンクリックでの登録解除に対応する

そして上記の内容でそれぞれどのように対応すべきかを精査します。

Gmailアカウントに1日あたり5000件を超えるメールを送信する場合は以下を守る必要がある

弊社サービスではユーザーのメールアドレスを登録してもらう必要があり、月に何回かシステムからのメールを送信する必要があるため、この条件に当てはまります。そのため後続の条件も守る必要があります。

ドメインにSPF及びDKIMを設定する

こちらはすでに設定されていました。

Postmaster Toolsで報告される迷惑メール率を0.30%以上にならないようする

こちらは今まで確認する運用がなかったため、新たに定期的に確認するフローを確立する必要があります。Slackリマインダー等を設定して、定期的に確認する運用が良いでしょうか。

送信ドメインにDMARCを設定する

弊社には立ち上げ当初から存在しているtoC向けのサービスと比較的新しめのtoB向けサービスがあります。toBサービスで利用しているドメインにはすでにDMARCが設定されていたのですが、toC向けのサービスには設定されていなかったため、新たに設定を行いました。

マーケティングを目的したメールではワンクリックでの登録解除に対応する

運用しているサービスから送信されるメールはユーザーに報告すべきものを送信している(法令的にも)ため、こちらはアプリケーションの改修が必要とは当てはまらないと判断しました。ただ、サービスのアプリケーションとは別にマーケターがマーケティングオートメーションやメルマガ配信システム等を利用している可能性はあるため、こちらは社内で別途確認する必要がありそうです。


残りはDMARCをPassさせるだけ

弊社ではSPF, DKIMはすでに設定されており、全体を振り返ってみると必須で行うべきはtoC向けサービスで利用している送信ドメインにDMARCを設定することのみでした。

そしてDKIMの検証ドメインが folio-sec.com となっていたため、DKIMアライメントがPassできる状態となっており、すぐにDMARCをPassできる状態となっておりました(後述)。作業量としてはそこまで多くなくてよかった！

SPF, DKIM, DMARCのおさらいと対応方法

結果としてはDMARCを設定するだけだったのですが、改めてガイドラインに書いてあるSPF, DKIM, DMARCというのは何なのかという理解を深めました。

SPF

SPFは、送信元メールサーバのIPアドレスがSPFレコードとして公開されているものと一致するかどうかを認証することで、なりすましを防ぐ技術です。

SPF認証プロセスのイメージを図解したものです。アプリケーションからメール配信を行う際にはAWSのSESやSendGrid等のメールサービスを利用している方々も多い方と思いますので、そちらを想定したものとなっています。

  1. まずアプリケーションサーバからAPI等でパブリッククラウドのメールサービスに対して送信の指示
  2. パブリッククラウドのメールサービスのサーバからメール送信が送られる
  3. メールを受信したGmail等のメールサービスが送信元IPが登録されている確認

SPFレコードを検証するドメインはヘッダFROM(メールのFROM)ではなく、エンベロープFROM(Return-Path)になっています。SESからメールを送る場合、デフォルトではエンベロープFROMが {xxxxxxx}@amazonses.com といったようなものに設定されるようになっています。SESの設定を変えたり、SendEmail APIを利用する際に変更しない限りは、SPFレコードの検証ドメインは、 amazonses.com となります。バウンスが発生した場合はエンベロープFROM(Return-Path)に記載されているアドレスにバウンス通知が行くようになっています。

SESデフォルトの設定でメール送信を行う場合はSPFの検証ドメインは amazonses.com となります。

  • ヘッダFROM: {xxxxxxx}@folio-sec.com
  • エンベロープFROM(Return-Path): {xxxxxxx}@amazonses.com (SPF検証ドメインはこちら)

また例として、エンベロープFROM(Return-Path)を弊社ドメイン folio-sec.com に変更しつつ、AWSのSESを利用し、SPFレコードに以下の様なものを設定したとします。

  • ヘッダFROM: {xxxxxxx}@folio-sec.com
  • エンベロープFROM(Return-Path): {xxxxxxx}@folio-sec.com
  • SPF検証ドメイン: folio-sec.com
$ nslookup -type=TXT folio-sec.com
;; Truncated, retrying in TCP mode.
Server:		127.0.0.1
Address:	127.0.0.1#53

Non-authoritative answer:
.
.
.
folio-sec.com	text = "v=spf1 include:amazonses.com -all"

SPFレコードの include:{other_domain} に当たる箇所は、他ドメインを参照してSPFレコードを認証させる場合に使用できます。そのため、 amazonses.com のSPFレコードを調べると以下のようになっています。(2024/02/07現在)

nslookup -type=TXT amazonses.com
Server:		127.0.0.1
Address:	127.0.0.1#53

Non-authoritative answer:
.
.
.
amazonses.com	text = "v=spf1 ip4:199.255.192.0/22 ip4:199.127.232.0/22 ip4:54.240.0.0/18 ip4:69.169.224.0/20 ip4:23.249.208.0/20 ip4:23.251.224.0/19 ip4:76.223.176.0/20 ip4:52.82.172.0/22 ip4:54.240.64.0/19 ip4:54.240.96.0/19 ip4:76.223.128.0/19 ip4:216.221.160.0/19 -all"

このようにSPFレコードには送信元となるIPが記載させることで、なりすましを防いでいます。

お使いのメーラでSPF検証が成功しているかも確認できます。以下はAWSからシステム通知をOutlookで受け取ったものなのですが、送信元IPがSPFレコードに記載されていたため検証にPassしていることが確認できます。

OutlookでSPFがパスしていることを確認
OutlookでSPFがパスしていることを確認


エンベロープFROM(Return-Path)に設定されているドメインにSPFレコードを確認する

DKIM

DKIMはメールサーバ側の秘密鍵により電子署名を行い、それに対応する公開鍵はDNSサーバで参照可能にすることで、改ざんされていないことを確認可能する技術です。

こちらも同様にアプリケーションからメール配信を行う際には外部のメールサービスを利用する想定となっています。

  1. まずアプリケーションサーバからAPI等でパブリッククラウドのメールサービスに対して送信の指示
  2. パブリッククラウドのメールサービスのサーバが保有している秘密鍵を用いてメールを電子署名しつつ、メール送信を行う
  3. メールを受信したGmail等のメールサービスが公開鍵をDNS経由で参照して電子署名を検証する

こちらも同様にお使いのメーラでDKIM検証が成功しているかも確認できます。DKIM-Signatureで電子署名がされているのが確認できます。( d={domain_name} となっている箇所がDKIMで検証するドメイン)

また、電子署名を検証する公開鍵は以下のようにDNSを通して参照できます。

$ nslookup -type=TXT xxxxxxx._domainkey.folio-sec.com
Server:		127.0.0.1
Address:	127.0.0.1#53

Non-authoritative answer:
.
.
.
xxxxx._domainkey.folio-sec.com	canonical name = xxxxx.dkim.amazonses.com.
xxxxxxx.dkim.amazonses.com	text = "p=xxxxxyyyyyzzzzz(公開鍵の文字列)"

DMARC

DMARCを利用するとDNSでDMARCのポリシーを公開することとなります。ポリシーを公開することによってなりすましメールに対する扱い(隔離・除外等)を明記することで、自社の顧客を守ることが可能になる技術です。

DMARC認証では、ヘッダFROMのドメインと、SPF認証 or DKIM認証に合格したドメインが一致しているかを確認します。これらをSPFアライメント、DKIMアライメントといいます。また、ヘッダFROMのドメインの _dmarc.{ヘッダFROMのドメイン} というレコードでDMARCのポリシーを公開することが必要です。

  • SPFアライメント or DKIMアライメントまたは両方が成り立つ
  • _dmarc.{ヘッダFROMのドメイン} でDMARCのポリシーが公開されている


DKIMアラインメントかSPFアラインメント、またはどちらもが成り立つ場合はDMARCがPass


DKIMアラインメントかSPFアラインメント、どちらもが成り立たない場合はDMARCがfail

DMARC認証にPassしなければ、公開されているDMARCのポリシーに則ってメールの扱いをメールサービスが決定します。DMARCのポリシーには抜粋すると以下のようなものがあります。

タグ 指定する値 内容
v DMARC1 DMARCのバージョン。固定値
p none or quarantine or reject 認証に失敗した場合に受信側で実行してほしいアクション ※必須
rua mailto:{xxxx}@example.com 集計レポートの送信先アドレス。複数指定が可能
ri 86400 集計レポートの送信間隔。デフォルトは86400sec = 24h
ruf mailto:{xxxx}@example.com 失敗レポートの送信先アドレス。複数指定が可能

pで指定した値でどのようにDMARC認証にPassしなかったメールをどのように扱うのかを指定することができます。

pで指定する値 アクション
none メッセージは受信者に配信される
quarantine メッセージは迷惑フォルダ等の隔離フォルダに移動
reject 受信拒否

DMARCのポリシーはDNSを通して公開することができます。

$ nslookup -type=TXT _dmarc.folio-sec.com
Server:		127.0.0.1
Address:	127.0.0.1#53

Non-authoritative answer:
_dmarc.folio-sec.com	text = "v=DMARC1; p=quarantine; rua=mailto:{xxxx}@folio-sec.com; ruf=mailto:{xxxx}@folio-sec.com;"

ガイドライン準拠するだけなら p=none; でも問題ありませんが、弊社では p=quarantine; に設定しております。

Terraform等でDNSレコードを管理している場合は以下のように設定する必要があります。

resource "aws_route53_zone" "this" {
  name = "folio-sec.com"
}

# DMARCレコード
resource "aws_route53_record" "dmarc" {
  zone_id = aws_route53_zone.this.zone_id
  name    = "_dmarc.folio-sec.com"
  type    = "TXT"
  ttl     = "300"
  records = ["\"v=DMARC1; p=quarantine;\""]
}

メール送信に関する技術について勉強会

上記のようにSPF, DKIM, DMARCを改めて理解を深めつつ、チーム全体で勉強会を行いました。それにより「メール送信者のガイドライン」で何が求められているのかという理解度をチーム全体で高めるようにしました。

終わりに

メールまわりは一回設定してしまうと、なかなか触る機会がなく下回りの技術等が記憶に定着しにくいのですが、これを気に改めて整理できてよかったです！すでにガイドライン適用自体は始まっていますが改めて設定確認を行う方がいれば理解の一助になれば幸いです🙏

FOLIO
FOLIOPublication

Discussion