2024 年- Gmail のスパム対策強化について🤔 (+DKIM/SPF/DMARCチェック の方法 step by step)
この記事では Gmail がアナウンスしたメール送信者に対するガイドラインの解釈と、その要件を満たしているかCheckする方法について自分なりの考えを描きます。
長いので目次を。。
結論としては、Gmailなどにメール送れば、ほとんどのことはヘッダーに書かれています。なのでメルサバ担当者に声をかける前にまずはそのメールシステムから、お手持ちのGmailに対して実際にメールを送ってみようね。チェッカーツールでもいいよ。（重要！😳）
しかしながら、見るべき・対応するべきポイントや、解釈についてある程度知見がないと理解し難い部分もあるかと思いまして、ここにしたためます。
どういう要件になったの？
こちらをレビューしていきましょう。まず全員が守るべきなのは以下の7つ
[✅全員が守るべきもの]
1) ドメインに SPF または DKIM メール認証を設定します
解釈：SMTPコマンドのレベルでは、メールの送信元は送信者が自由に名乗れます。名乗るだけなら本当にタダです。有名企業の社長でも総理大臣でも大アリクイでも好きな送信元を名乗れます。そのためここに書かれている SPF/DKIM という送信元ドメインが本物かどうか見抜く技術が培われてきました。これにより、嘘のドメインを名乗っていることを見抜くことができます。
確認方法：お手持ちの Gmail に実際送ってみたらいいです。
受け取ったメールをメッセージのソースを表示するとこんな感じで出ます。
成功してると PASS となりますし、失敗していると FAIL ってなります。
実際に note さんから送られるメールで見てみます。ちゃんと PASS してるのがわかります。なお後で出てきますが、その下の DMARC も PASS ですね！
これがダメな状態だと "FAIL" と出ます。
なお、DNSという公の仕組みに登録されているのでそこを見に行ってもいいです。見るためには SPF の知識が必要なので、上の方法で確認する方が簡単でいいですが、どうしても生のデータが見たければDNSを見に行きます。この辺を確認するにはある程度の専門知識が必要です。初見だと難しいのでスキップしてもいいかもしれません。また、ご存じの方も以下をスキップして次へどうぞ。
・ちょっと SPF の話
SPFは「Mail From のドメインのTXTレコード」を見ます。Mail From?なにそれ？と思いかと思います。実はメールには二つの From アドレスがあって、エンベロープ From と ヘッダー From とに分かれています。我々がメーラーで見ている送信元は後者のヘッダー From の情報です。SPFに使うのはそれと別の エンベロープ From のドメインを使います。外部のメールサービス使ってると、これは別になることが珍しくないです。というかほぼ別だと思います🤔
分かりにくいと思いますが例えば
封筒には
「住所 - 鈴木一郎様 / 住所 - 山田太郎」
と書かれますが、
手紙の中には
「おう、イッチ元気か？じゃあの。 ドカベンより🤤」
って書くようなもんです。SPFは先頭の山田太郎の情報を使って認証します。山田太郎のIPアドレスとして正式に登録されているものかどうかを検証しにかかります。例えば note.com さんだと、こんな エンベロープ From を使っています。先ほどのメッセージのソースを表示するで取ってきたヘッダーの情報に以下のようなものがあります。
smtp.mailfrom="bounces+xxxxx-ワイのメアド=gmail.com@email.note.com";
ここだと email.note.com とある。なので、 dig ツールを使って TXT レコードを見てみましょう
https://toolbox.googleapps.com/apps/dig/#TXT/
こんな感じで
CNAME とあるが、これは丸投げのサインで、「このDNSサーバーに行け」と指示されています。んでそのDNSサーバーから帰ってきたのが ip4 ~ の部分。ここに該当するIP（もしくはIPレンジ）から送られていれば晴れてOKです。今回、かくしてますがOKでした😊。よってPASSと表記されます。
・DKIMは？？
DKIMはメールヘッダーに入っている Signature (署名) が本当に送信者のものかどうかをチェックする機構が走ります。署名は送信者の秘密鍵で暗号化されますので、間違いなく秘密鍵を持った人しかその署名が書けません。
このとき、ヘッダーに書かれているドメインを確認して、そのドメイン（＋セレクター）の txt レコードをチェックして公開鍵をゲットしてきます。
公開鍵を使って署名をチェックして、妥当だと判断したならば、DKIM がパスします。もし偽った秘密鍵で署名したならば、そのドメインの公開鍵では正しく認証できません。
分かりにくいのでまた例を。
先ほどの手紙の中だと例えば🤤が署名だとします。
「おう、イッチ元気か？じゃあの。 ドカベンより🤤」
この場合、ドカベンの DNS に行き、txt レコードから DKIM のレコードを取り寄せます。ここに公開鍵が入っているので 🤤を検証します。正しく検証できれば「あっ、これマジでドカベンさんからの手紙だ」ってわかります。
具体的に見るのはすごくトリッキーです
「"セレクター"."_domainkey.ドメイン.” のTXTレコード」を見ます。
同じく note さんだと、以下のようにあり、 d=note.com/s=s1 とあります。
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=note.com; ~省略~; s=s1
ここで重要なのが、dはドメイン、sはセレクターと言います。このセレクターが非常にトリッキー。というのもTXTを取り寄せる先のドメインが以下のフォーマットになっているからです
<セレクター>._domainkey.domain.com
noteさんだと上の例に従うと
s1._domainkey.note.com
となります
では取り寄せてみましょう。レコードがあります。
さすがに人間ではこのレコードであってるかどうかはわかりませんが、とりあえずレコードがあればOKです。Passしないなら、指定された公開鍵を正しく登録できていないでしょう。外部のメール送信ベンダーを使っている場合、ＤＮＳがベンダー管理なら彼らに見直しを依頼し、自社管理するタイプなら彼らから指示を受けた DKIM レコードが正しく入っているか？をチェックしましょう。
2) 送信元のドメインまたは IP に、有効な正引きおよび逆引き DNS レコード（PTR レコードとも呼ばれます）があることを確認します
解釈：通常、インターネットの通信では、ドメインに対応するIPアドレスを引き出します。これを正引きと呼びます。反対にIPアドレスからドメインを引き出すのを逆引きといいます。
確認方法：DNS は誰でもどこからでも引けます。ここでは発信元のGoogle様の提供するDNSのツールを使ってみましょうか。https://toolbox.googleapps.com/apps/dig/#A/
・正引き：レコードの種別は何か書かれていませんが、おそらくAレコードでしょう。ではまたしても note.com さんをお借りします。note.com と書いてAレコードのところをクリック
・逆引き：1) で確認したSPF のところに xxx.xxx.42.230 という送信者のサーバーの IP がありますので、同じツールで確認します。IPを入れて PTR ってところをクリックします。
3) メールの送信に TLS 接続を使用します。
解釈：要するにメール送信時に中身を暗号化しろということ。
*えっ、と思う方がいるかもしれませんが、メールはSMTPというプロトコルで、これは通常、暗号化してません。なのでアナタのあんなメール、こんなメールもパケットキャプチャーしたら思いっきりそのまま乗ってますよ😂
*これを防ぐために、サーバー間で通信するときに EHLO という挨拶をして、STARTTLS という暗号化通信をしようという紳士協定を結びます。最近はこっちがスタンダードだからあまり気にしなくていいですが、大昔のメールはまあ、、、当時見られてた人いるんでしょうねｗ
確認方法：確実に記録されるかは定かでないですが、先ほど同様、Gmail に送ってみて、ヘッダーを見てみましょう。
Received: from xx.xxxxx.note.com (xx.xxxxx.note.com . [zzz.aaa.42.230])
by mx.google.com with ESMTPS id h15-xxxxxxxxxxx for ワイのメールアドレス@gmail.com
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Sat, 08 Jul 2023 02:20:08 -0700 (PDT)
これがエビデンスになり、TLS(しかも現状で最新の) 1.3 を利用していることがわかります。
4) Postmaster Tools で報告される迷惑メール率を 0.10% 未満に維持し、迷惑メール率が決して 0.30% 以上にならないようにします。
解釈：Postmaster Tools という google が提供しているツールがあります。この中に迷惑メールとして処理された比率が入っているそうです。これが 0.1%死守し、間違っても 0.3% を超えてはならないぞと言っています。
確認方法：私はメルマガなどを自分で送ってないのでこのツールを結果が出た状態で見たことがないです。利用申請までしたことあります。
*なお利用申請の際には、そのドメインがあなたの所有であることを示す必要があります。方法として、 そのドメインの TXT レコードに、Google が指示したレコードを追記する必要があります。もし送信に利用しているドメインがベンダー管理ならば、依頼して指示があったレコードを追加してもらうお願いをしましょう。
大事なこと：迷惑メールにしないことです。これには一例として以下のようなポイントが大事です。
・必要としている人に、必要としている頻度で、必要としている内容を送る
・正しいメールアドレスに送る
・変な添付やリンクを含めすぎない
・購読の停止を簡単に（ログインさせんなよ😡）
結局、Google のあらゆるサービスに言えることですが、ユーザーにとって不利益なことはしないことが大事。送ったメールをなんとかして見てもらいたい気持ちはわかるけど、、この直後批判殺到みたいなサムネの動画とか、歌ってみたのついてない音楽動画とか見せられたらエンゲージメント下がるでしょう。なのでどこまでもユーザー本位で。。
5) Internet Message Format 標準（RFC 5322）に準拠する形式でメールを作成します。
解釈：今の時代はほとんど準拠してる認識です。よほど古いメールサービスを利用しているなら注意が必要。ただ、思うに、Google が出している RFC5322 の記事を見ていると以下が見つかります。要するに To や CC のヘッダーを重複させないでくれというように見える。
https://support.google.com/a/answer/13567860?hl=ja
確認方法：これは実際に SMTP のコマンドレベルで見れないと厳しいです。ただ書いてあることは当たり前な内容が多いので、多くは準拠してるんじゃないかなと思われます。（適当）
7) メーリング リストや受信ゲートウェイを使用するなどして、メールを定期的に転送する場合は、送信メールに ARC ヘッダーを追加します。ARC ヘッダーによって、メールが転送されたことが示され、送信者が転送者と見なされます。メーリング リストの送信者は、メーリング リストを指定する List-id: ヘッダーも送信メールに追加する必要があります。
これは以下のような構成を張って外部に送信している時が該当するとみています。（このヘッダーはあまり検証したことがなくなじみは薄いです）
[送信者] --> [👉中間メールサーバー] --ARC つける--> [Google 様]
この時に中間のメールサーバーで ARC ヘッダーをつけて、転送したことを示せというところ。まあ受信はともかく送信メールで外に出ていくときに SMTP サーバーを別途立ててるってことはあまり多くないのでは？とは思うけど、外部のセキュリティ製品のサーバーにルートしてから、そこから外部出て行ってもらうような構成だったらケアしなきゃいけないかもですね。
※SPF 通すときにどのみち転送はケアしてると思うのですが、、ARC ヘッダーも今後はちゃんとつけろということか。ワイはこの構成組んだことがないからなじみがない。
確認方法：メールヘッダーにつきますね。 Gmail でもつきますからサンプルを見てみましょう。
ARC-Seal: i=1; a=rsa-sha256; t=省略; cv=none;
d=google.com; s=arc-20160816;
b=P5~省略mE+ijA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
h=to:subject:message-id:mime-version:from:date
:content-transfer-encoding:dkim-signature:dkim-signature;省略
ARC-Authentication-Results: i=1; mx.google.com;
dkim=pass header.i=@note.com header.s=s1 header.b="省略";
dkim=pass header.i=@ぼ某メールサービスだった header.s=smtpxxxx header.b=省略;
spf=pass (google.com: domain of bounces+xxxxワイのメアド=gmail.com@xxxx.note.com designates zzz.zzz.42.230 as permitted sender) smtp.mailfrom="bounces+省略-ワイのメアド=gmail.com@xxxxx.note.com";
以上が全員が守るべきアクションだ。
また、5000件以上送る人は以下も同時に満たす必要があるようです。
[🙌1日 5000 件以上を Gmail へ送る人が守るべきもの]
ページ下の方に移動して今度はこちらも見ていきましょう
1~7 は同じなので割愛
8)送信ドメインに DMARC メール認証を設定します。DMARC 適用ポリシーは none に設定できます
解釈：DMARC レコードをちゃんとつけなさい。ただし (おそらく今のところは) ポリシーは none という最弱のもので構わない。
注釈：DMARC は、DKIM/SPF のどちらかが Fail したときにメールをどう処理するかを受信者に指示するものです。ポリシーが none というのは「私たちのドメインを名乗って送るメールの送信元が疑わしくても (SPF や DKIM が正しくなくても) 気にせんでそのまま配ってええで」って宣言しています。つまり意味はありません。今はその宣言が盛り込まれていればそれで OK だということになります。
それが嫌なら Reject (拒否しろ) と Quarantine(検疫しろ) というオプションがあります。似てますが、前者はおそらく SMTP の段階で送信元に拒否を示し、後者は検疫して内部で削除 (or 迷惑メール) して葬ってしまうものになると思われます。
確認方法：DKIM/SPF の下に DMARC があるから、これが書かれていれば OK 。 ポリシーが none でもよいということなので、Fail していたとしてもとにかく書かれていればよいものと思われる。
DNS で検索をしてもいいでしょう。
ドメインのアタマに _dmarc ってつければいい。
例えば note さんなら _dmarc.note.com と打ち込んで、 txt をクリック。余計な文字列がいるが、DKIMよりかはずいぶん覚えやすいです。
ちゃんとレコードが出てくる！😊
んで彼らは p=quarantine と書いてあります。 p= がポリシーであり、noteさんは「ワイらを名乗るドメインの DKIM/SPF が失敗したら内々で屠ってしまえ」と指示しています。強気ですが、それぐらいちゃんと、「自分たちの送るメールサーバーのIPや、メールの筆跡 (DKIM) を全て公共（DNS) に登録してあるよ」と胸を張っているといえます。
9) ダイレクト メールの場合、送信者の From: ヘッダー内のドメインは、SPF ドメインまたは DKIM ドメインと一致している必要があります。これは DMARC アライメントに合格するために必要です。
解釈：メーラーから見える皆様の送信元のドメインが、SPF OR DKIM のどちらか一方のドメインと一緒になるようにしなさい。と言っています。
確認方法：note さんでまたも見てみましょう。
まず From ヘッダーのドメインをみると note.com になっています。
ヘッダーもこうですね。だいたいのメーラーはこの From: を採用して表示しています。（余談ですがここに書かれていなければ Mail From: コマンドの From を採用したりします）
From: note noreply@note.com
で先ほどもチェックしたがそれぞれのドメインは
DKIM ドメイン:d=
→ よし！😂
SPF ドメイン : smtp.mailfrom="ワイのメアドgmail.com@email.note.com
→だめ✖😡
ということで DKIM のドメインが、From と一致しています。
これはDKIM のアラインメントがパスした状態で、逆にSPF のアラインメントは失敗した状態となります。（ただこの mailfrom が 宛先のメアド@元のドメインていう形、多分Gmail内で転送してるんじゃないかなあ。。。まあともあれ）
上の要件より、DKIM がアラインメントの要件を満たすのでOKです。
ちなみにまた余談ですが、このアラインメントを満たさないときの挙動も DMARC レコードで指定できます。
aspf/adkim というオプションがあり、relax/strict などのオプションがあります。文字通りですが、上のアラインメントを満たさないとき、気にしないのが relax、Fail として不合格にしてしまうのが strict となります。（不合格時の挙動は先ほどの通り、 p= で指定します）
10) マーケティング目的のメールと配信登録されたメールは、ワンクリックでの登録解除に対応し、メッセージ本文に登録解除のリンクをわかりやすく表示する必要があります
解釈：マーケティング目的のメールに関しては、list-unsubscirbe というヘッダーを付与します。これがあるとメーラー側に、クリックするだけで 購読取り消しになるようなボタンが表示されます。
＊ただし、メーラーがこのヘッダーを正しく認識できる必要があり、挙動は送信者側では強制できないので、送信者側は正しくヘッダーをつけるところまでしか対応できません。ボタンが出ないのはある種仕方がないところもあります。。
確認方法：note さんでまたも見てみましょう。
あれ、ここにきて無い😂
ようやく note さんにピンチが！（って控えたほうがいいのかな)
ここで慌てずヘッダーも見ます。が、 list-unsubscribe の記述がありません。
代わりに linked-in でね。
こんな感じで「メーリングリストの登録解除」ってボタンが出ます。
これを押すと一発解除です。
ヘッダーにもありますね。
List-Unsubscribe: https://www.linkedin.com/aaa/psettings/email-unsubscribe?lipi=パラメーターわらわら。
なお正しい要件は Google 次第ですが、おそらくヘッダーがあるだけではなく、ある程度ちゃんと動作することも要件になってくるんでないかなあと推測しています。URL が書かれているが、実際に全然Unsubされないとか学習すると、おそらく G様の逆鱗に触れるものとおもいます😨 なのでちゃんと動くか確認しましょうね。 おそらくですがどうしても無理ならメール内に簡単アンサブリンクをつけるだけでももしかしたらお許しいただけるんじゃないかと思いますが、、、この辺はG様のみぞ知る。
コラム：数値原理主義は NG
1日5000通という数字がありますが、おそらく Google 様のことですから、「じゃあ4998 件にとどめれば OK なんだね。下回ってるからうちはDMARCしませーん」なんて考えたら間違いなく一網打尽にたたき切られるでしょう。
一定数以上送ってるなら満さないといけないと考えておくべきだし、要件をレビューしてみても「そもそもこの要件規制がなくても必ず満たしておいた方がいいよね」って内容ばかりなので、ぜひこれを機に対応しましょう。多分今後もっときつくなるでしょう。少なくとも甘くなることはもうない。
(なので Gmail に1日何件送っているか今になって数えだすなんて不毛なことはやめてね🫠)
コラム：迷惑メールのフィルターは複雑
迷惑メールになった理由を調べようとしている人がいますが、基本的に明らかにされませんので、「あきらめたほうが得策」です。Google や Microsoft 365 のフィルターはそれはそれは賢く、非常に様々な情報を加味して、迷惑メールかどうかを判断しています。なので、どれか一つの要因を持ってくることはできず「総合的に見て、ユーザーにとって迷惑だと判断した」という話になります。これはベンダーの中の人でも明らかにされないらしく問い合わせなどをしても無駄に終わります。まあ理由を明らかにしたら抜け道になるので、基本的に教えてはくれませんよね。
コラム：SPF/DKIMだけじゃ不満か？DMARCとかめんどくさくね？
上のような送信元を保証する仕組みがあるのに、なぜさらにDMARCを追加する必要があるのでしょうか？しかもDMARCのポリシーは none で良いとなっています。つまり DMARCが正しく認証できなくても気にしないというポリシーでOKというガバガバを許容しています。なのになぜ面倒な設定変更をしなくちゃいけないのでしょうか？
ワイの見解としては「昨今、DKIM / SPF をきっちりパスするが、アラインメントがマッチしない精巧な迷惑メールが出回ることが多くなった」からだと考えています。特に金融機関や有名ECサイト、インフラ企業、あるいはメールサービスなどを名乗る悪質なメールがよく出回っているようです。あれらは本物を厳密にコピーしてますので、リテラシーがある人でも油断してると指示に従ってしまいそうになります。昔某メールサービスを名乗る偽者のの「容量がいっぱいです」メールを見せてもらったことがあるのですが、本物と見分けがつきませんでした。それぐらい精巧です。
さてそんなメールも、ヘッダーを見ると嘘だとわかります。
先ほどの通り SPF も DKIM も、指定したドメインの DNSに正しく情報がアップロードされていれば通ってしまいます。しかしよく見ると、DKIM の認証に使うドメイン (d=)と、我々がメーラーで目にする送信元のドメイン (ヘッダーの from:) が別々になっています。SPFやDKIMに書かれているドメイやIPを見ると、某クラウドウェブサービスのものだったりします。これらのサービスから送ると、ちゃんとSPF/DKIMが成立してPASSしていまうんですよね。。😨
なので、ちゃんと送信元に名乗っている from のドメインに、お伺いを立てるようにしましょうね。ってことだと認識しています。よって、DMARC レコードを立ててアラインメントがおかしい時にどうするか定義しておきましょうということだと認識しています。
いきなり p=r/q(拒否、検疫）にするとエラーラッシュになるので混乱を招くから、今は none でいいからとりあえず入れる習慣をつけろよ、というGoogle様のお気遣いだと思っています。おそらく今後は r/q じゃないと立ち行かなくなるのではとも考えています。なのでメール担当者はできれば速やかに社内全体としてDMARCをデザインし始めることをお勧めしますよ（余計なお世話🤪）。大きい企業さんだと、サブドメインも、痩身サービスも大量にあるから、複数の部門と仲良くして話を進めていきましょうね😊
最後にFAQ行っときましょう。
よく聞かれること
Q) ほかにも同時期に「非アクティブアカウントの削除」が発表されています。非アクティブなアカウントに送ることの何がいけんのですか？
A) メール送信時に "そんなユーザーいませんよ" というエラーが多発する恐れがあります。このエラーが一定数増えると、悪意ある送信者だと目を付けられやすくなります。一定期間ブロックされたりして配信到達性が下がるし、最悪の場合、DNSBL といってブラックリストに載ってしまい、一切の送信を拒否されることがあります。
よって明かにアカウントを使っていないようなメルアドには、今後送信を差し止めることを検討する必要があります（また、この挙動もありまして上の方でも述べた通り、メールアドレスを正確に集める必要があります）
Q) 非アクティブアカウントってどうやって判別するんですか
A) Google様のみぞ知る。あとは送り手側の工夫次第。正解は与えられていませんので、ベストを尽くそう。
例えば、思いつくところだと 「長期間メールを送っているのに、何のリアクションがないユーザーを抽出して配信を差し止める」という感じでしょうか。
ただし、リアクションが集計できていないだけで、本人はメールのタイトルぐらいはみてるケースも少ないながらあるでしょう。エンゲージメントの低いユーザーなら急に送られなくなってもなんとも思われないと思いますが、万が一うっすらと日々見てくれてたようなユーザーだと、差し止めはもったいないかもしれません。
そんなケースは想定しておいてもいいのかもしれません。※例えばメールを送らなくする前に一通最後に送るとか・・・ですかね。わかりませんが。
Q) 要件10の「マーケティング目的の」とあるがこれは例えば、ご注文確認やビジネス上の重要なお知らせなどの必須メールは該当しないのか
A) 多分しないはず。
Q) 迷惑メールに振り分けられたかどうかってどこ見ればわかるの？
A) 個々のメールに関しては、送信者側からはわかりません。そういうフィードバックは普通送信側に戻ってきませんので。統計情報は postmaster tools で見られるかと思いますので、それを使う感じ。
Q) メールアドレスをクリーンに保てというが、具体的にどうすればいいのですか？
A) いろいろある。どれが正解ということもないが合わせ技で頑張れ。例としては例えば以下など。
・手書きのフォームからシステムに手入力するみたいな集め方はしない
・ダブルオプトインをする（会員登録時にメールアドレスにVerify用のリンクを送り付けて、クリックしたら晴れて会員）
・明らかな誤字脱字は訂正する（gmai.com とか gmail.co とか。Gさんはいいけど、こういう似たドメインにメールサーバー立てて待ち受けてる悪い奴いっぱいいますよ）
Q) メールヘッダーを見るのが辛い。難しい。もっと簡単にできない？
A) 巷にCheckツールついてます。ツールごとにやや癖があったり、セレクタの概念知らないと使いこなせないが、ハードルは低いのでまずはここからでもいいよ。ただし、外部ツールなので利用ポリシーは社内で確認してね。
https://dmarcian.com/
https://www.proofpoint.com/jp/cybersecurity-tools/dmarc-spf-creation-wizard#dmarc
など多数
最後に
今回はGoogleの発表した迷惑メール規制強化について各項目の解釈と、確認方法をご紹介しました。
お分かりいただけたと思いますが、ほとんどの情報について「誰でも見られるインターネットに広く公開されている情報」であり、「Gmailに一発メールおくればほとんどわかる」んですよね。なのでワイに確認するのはそろそろやめて（本音）、この記事を参考に手を動かしてみてくださいｗｗ🫠😇 楽しいもんですよ。
長々すみませんでした。
ただこの案件、多分今後も動きがありそうなので追記修正が必要になりそうです。またアプデします。
この記事が気に入ったらサポートをしてみませんか？