8割解けるCTF「WEST-SEC」

セキュリティ初心者の方でも楽しめるゲーム形式のセキュリティイベント。CTFや勉強会の依頼があればご相談ください。

送信ドメイン認証

1.送信ドメイン認証とは

1.1 言葉の確認

送信ドメイン認証の説明の前に、メールヘッダについて整理

送信元メールアドレスの種類 概要 コマンド メールヘッダのどこに記載されるか
Envelope-FROM エンベロ－プ（手紙でいう封筒）の送信者メールアドレス。
利用者には見えない		 MAIL FROMコマンド Envelope-FROMそのものは利用者が見えないが、
Return-Pathに同じ情報が転記される
表示名（diplay name） メールの差出人（自由に設定可能） DATAコマンド From: 表示名 ＜mail@test.dom＞
Header-FROM メールデータ内のメールヘッダで指定される送信者メールアドレス（のみ。表示名は含まず） DATAコマンド From: 表示名 ＜（ここ）＞
dタグ DKIM署名をする公開鍵のドメイン DATAコマンド DKIM-Signature:のd=

・メールの機能

機能 内容 具体的な製品 使うプロトコル
MTA (Mail Transfer Agent) メールを送受信するアプリケーション。送信メールサーバ Postfix、Sendmail SMTP
MUA (Mail User Agent) 利用者のメールソフト Microsoft Outlook、Mozilla Thunderbird SMTP（メール送信時）
POP3やIMAP4（MDAにメールを取りに行くとき）
MDA (Mail Delivery Agent) メールボックスを持つメールサーバ。MTAと同居することもある Dovecot MTAからはSMTPでメールが送られる
MUAからはPOP3やIMAP4でメールを取りに行く
1.2 なりすましに対するメールの仕組みの弱点

・受信メールサーバにて、送信者のメールアドレスが正しいか（＝偽装されているか）を検証する仕組みは存在しない
・送信者はEnvelope-FROMやHeader-FROMを自由に設定できるし、両者が一致していなくてもいい。

1.3 メールヘッダ解説

(1)主なもの

項目 例 解説
Return-Path: ＜bad@fake.dom＞ MAIL FROMコマンドで送られたEnvelope-FROMの値がここに転記される。
Reply-To: ＜mailing-list@fake.dom＞ 送信者が、異なるメールアドレスに返信させたいときに使う。（※注）
Authentication-Results: mta7022.mail.djm.ynwp.yahoo.co.jp from=orange.plala.or.jp; domainkeys=neutral (no sig); dkim=pass (ok); header.i=@plala.or.jp; dmarc=pass (p=NONE,sp=NONE,pct=100,domain=plala.or.jp); header.from=red.plala.or.jp 送信ドメイン認証の結果
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=plala.or.jp; q=dns/txt; s=p20240201; t=1717042923;
x=1748578923;（中略）
bh=sjDXyHL6vgVVG4LCQfX6NnNjrwyTgzk25mkBJT759NA=;
b=Iz9cpav56POlN0（省略）=;		 DKIM署名
Received: from [192.168.1.110] (really [153.239.234.128])
by msc11.plala.or.jp with ESMTP		 経由したメールサーバ
Date: Thu, 30 May 2024 22:21:59 +0900 送信日時
To: user1@example.co.jp 宛先メールアドレス
From: =?UTF-8?B?5234d7KV5?= ＜bad@fake.dom＞ 送信元の　表示名＜送信元メールアドレス=Header from＞

※注：たとえば、メーリングリスト宛にメールを送っていて、受信した人が「返信」ボタンを押すと、送信者ではなくメーリングリストを宛先にしたい場合など。この場合の設定は、メーリングリスト側でReply-Toを設定可能

(2)その他
・MLなどで転送経路の場合、ARC-Authentication-Resultsが付与されることがある。
ARC（Authenticated Received Chain）は、メールの転送経由の認証結果を保持したもの。Receivedヘッダは改ざんされる可能性があるが、ARC-Message-Signature（AMS）という署名をつけて、改ざんされていないかの検証ができる。

ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
smtp.mailfrom=example.jp; dmarc=pass action=none header.from=example.jp;
dkim=pass header.d=example.jp; arc=none

・SPFの認証結果。client-ipが送信元のメールサーバのIPアドレス。今はAuthentication-Results:に統合されて、最近はあまり使わない（ただ、たとえばGoogleなど、未だにReceived-SPFを入れているところもある。）

Received-SPF: pass (msc117.plala.or.jp: domain of xxx@red.plala.or.jp designates 60.36.166.39 as permitted sender) receiver=msc117.plala.or.jp; client-ip=60.36.166.39;
1.4 そもそも送信ドメイン認証とは何か？

A1.送信者のメールアドレスが偽装されていないかを確認する
→×　メールアドレスの@より前が正しいかまではわからない。
A2.送信者のメールアドレスのドメイン部分（@以降）が偽装されていないかを確認する
→○

・3つの技術できることの整理。具体的な仕組みは後ほど解説

技術 できること
（チェックする箇所）		 できないこと
SPF Envelope fromの偽装 Header from（利用者に見える送信元メールアドレス）の改ざん
DKIM ・メールの受信経路における改ざん
・第三者署名をしなかった場合、Header from（利用者に見える送信元メールアドレス）の改ざん		 ・Envelope fromの偽装
・送信者が第三者署名をした場合、Header fromの改ざん（送信者が保有していないドメインに書き換えられること）
DMARC （SPFやDKIMの結果をアライメント（調整）することで、）
・Envelope fromの偽装
・Header fromの偽装
詳しくはDMARCのところで説明		 ・紛らわしいドメインを使ったメール（amado.dom）→BIMIが必要
・偽装していないただの迷惑メール
BIMI 　 　
1.5 メールの詐称と対策技術の変遷

❶（背景）メールはなりすまし放題
送信側では、勝手にヘッダを設定できる。かつ、受信側で検証をしない。→なりすましメールが横行
↓
❷SPFの登場
SPFによって、正規のメールサーバから送られてくるかを検査するようにした。（Envelope-FROMをもとに送信元を判断）
↓
❸SPFの弱点が露呈
メールヘッダを検査しない。
SPFは、EnvelopFrom（封筒のヘッダ）を検査するが、メールヘッダ（Header-FROM）は検査しない。利用者に見えるメールヘッダがなりすまされるので、本物のメールに見える
↓
❹DKIMの登場
DKIMでは、メールヘッダ（HeaderFROM）を検査するようにした。これなら、利用者に見えるメールヘッダがたとえばAmazonになりすまされると、DKIMがFailになって気が付くことができる
↓
❺DKIMの欠点
第三者署名という抜け道がある。
↓
❻DMARCの登場
なりすましメールはかなり防げる
↓
❼なりすましではない、本物そっくりメールが届く
なりすましなら気が付けるが、本物の送信元に似せたメールが、利用者には気が付かない
↓
➑BIMIの登場

1.6 【参考】送信元ドメイン認証のテスト

なりすまし対策ポータル「ナリタイ」　https://www.naritai.jp/

check@naritai.jpにメールを送ると、自分のメールサーバが、SPF/DKIM/DMARCが正しく設定されているかを判定してくれます。

[SPF]
接続元IPアドレス : 60.x.x.33
認証結果は PASS でした。

[DKIM]
認証結果は pass でした。
署名ドメインは plala.or.jp でした。

[DMARC]
認証結果は pass でした。
認証ドメインは orange.plala.or.jp でした。
ポリシーは none でした。

2.SPF

2.1 SPFについて

https://ent.iij.ad.jp/articles/172/
https://salt.iajapan.org/wpmu/anti_spam/admin/tech/explanation/spf/

Q.メールは複数のメールサーバを転送して送られるが、SPFでは、どの送信元IPを見るのか。
たとえば、PCがメール送信→内部メールサーバ→外部メールサーバ→受信側の外部メールサーバ→受信側内部メールサーバと経由してメールが届く場合、受信側の外部メールサーバは、どの送信元IPにたいして、SPFレコードに存在するのかを確認するのか？

SPFの検証は、直接送られたサーバのIPアドレスが、SPFレコードに含まれるかを検証している。

Q.メールは中継されるもの。中継したことを想定して、Recievedで一致するIPアドレスがが一つでもあればいい？

A.そういう仕様ではない。なので、転送するとSPFエラーになることが多い。

2.2 SPFの設定と動作

(1)送信者側
・送信するメールサーバの設定は特に無し
・DNSサーバにTXTレコードを設定する

設定項目 設定値 内容
~all ~ その前に記載したIP以外の場合もメールを破棄しないことを推奨(soft fail)
~all - その前に記載したIP以外のメールを削除(fail)

・設定できたかをnslookupで確認する。

(2)受信側の設定
メールサーバでの設定例は以下です。policyd-spf.confの設定ファイルで、SPFに失敗したメールを拒否するのか、それとも受信するのかなどを設定できます。
https://admnote.paix.jp/2022/07/postfix%E3%81%ABspf%E5%B0%8E%E5%85%A5/

Q.受信側として、受信側の外部メールサーバ→受信側内部メールサーバのような場合、SPFを設定するのはどのサーバか？

A. 一番外側でチェックをする。なので、受信側の外部メールサーバが該当する。

(3)受信サーバの動作　
・受信メールのEnvelope-Fromの@以降のドメインのDNSからTXT（SPF）レコードを取得し、メールの送信元IPアドレスがこの中に含まれているかを検証
・たとえば、Postfixの場合、policyd-spf.confの設定に従って、失敗したメールを破棄するのか、メールの「Received-SPFヘッダ」に結果を付与して次のメールサーバ（例えば内部メールサーバ）に配信するなどのアクションを行う。

2.3 SPFの欠点

・メールの転送に弱い
・SPFは、Envelope-FROMでチェックをする。しかし、攻撃者からすると、Envelope-FROMを改ざんする意味が無い。なぜなら、メールの受信者にはパッと見では見えないから。（メールヘッダを開いて、Return-pathを見れば確認はできる）
Envelope-FROMを改ざんせず、fake.domのままにして、堂々と送る。fake.domのSPFレコードが正しく設定されていれば、SPFはPASSするので、攻撃者にとっては、なんら問題がない。
Q.実際、SPAMメールはEnvelope-FROMを改ざんしているのか？
→あまり意味が無いので、ほぼない。

3.DKIM

3.1 DKIMの仕組み

大前提として、DKIM署名では、Header-fromのドメインだけを見ている。Envelope-Fromは見ていない。SPFとは逆である。
https://ent.iij.ad.jp/articles/172/
https://salt.iajapan.org/wpmu/anti_spam/admin/tech/explanation/dkim/

3.2 DKIMの設定：送信側の設定

・秘密鍵を作成する。たとえば、以下のように、「s=」と「d=」を指定して作成する。
今回はDKIMのソフトとしてOpenDKIMを使用した場合は以下。

opendkim-genkey –s 20240123 –d fake.dom

・今回は作成者署名になるが、設定ファイル(/etc/opendkim/SigningTable)に、以下の記載をする。

＊@fake.dom 20240123._domainkey.fake.dom

意味は、前半が署名をするメールアドレス。*が付与されているので@fake.domのドメインのメールはすべて、20240123._domainkey.fake.domの秘密鍵で署名するという意味。送信元のメールアドレス（Header-From）が@fake.domになっているメールが対象（確認済）。
・送信側のメールサーバで、送信者の公開鍵をDNSのTXTレコードに格納する。
nslookupでテストすると、以下のようになっています。

3.3 メールヘッダにおけるDKIM署名

・DKIMヘッダの説明
https://salt.iajapan.org/wpmu/anti_spam/admin/tech/explanation/dkim/

タグ 説明 補足
v バージョン 　
a 署名のアルゴリズム 　
b 本文とメールヘッダのハッシュ値を、送信メールサーバの秘密鍵で署名した署名値 h=from:to:subject:date;などと、「hタグ」で指定された箇所のハッシュ値を求め、そのデジタル署名（のみ）をBase64形式に変換
bh 本文（のみ）のハッシュ値 送信メールサーバは、「c=」タグで指定されたアルゴリズムを使用して正規化し、「l=」タグで指定された長さに切り詰められたメール本文をハッシュする。ハッシュ値をbase64形式に変換し、DKIM-Signatureヘッダーの「bh=」タグに挿入する。デジタル署名は付与しない
c メール本文の正規化の方式 simpleまたはrelaxed
d 署名する送信メールサーバのドメイン名 　
h 署名するデータをここで指定 たとえば、「:cc:to:subject:message-id:date:from」などとヘッダのどの部分化を細かく指定できる。しかし、本文に関しては、どこからどこまでという指定はできない
l 署名を行うメール本文の先頭からの長さ 省略した場合は本文全て
s セレクタ 公開鍵を識別するセレクタ。これがあることで、1つのドメインで複数の公開鍵を設定できる

・サンプルは以下。

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=spf.sclocalgovntt.ne.jp; s=20240423; t=1716719795;
	bh=E6pDkwiKDLkzB5AnsLo85U15f8W/tGYNS/EvvKvaWNg=;
	h=From:To:Subject:Date;
	b=cp/kil7YQaNMnl+D34SajMdL9dHCCulSL3SdKaEXz19cZnQKDFtfzr4csy+JuvREf
	 /BtBNxSsmBllsuHRbaBOO4Qycbc5iOMSWKCyjcvnycjgcaBXygSD7CIJQfPnjTmBcU
	 r+uMWvFy5uOYDXhqBYxQ0/5C6B+DocmTLZ50TnJY=
3.4 署名と検証の詳細

(1)署名
❶DKIM署名の範囲
メールヘッダとメールのボディの両方を署名します。エンベロープの情報は署名の対象外です。正規化方法には、simpleとrelaxedがあり、cタグで指定する。
メールサーバは、中継するたびにヘッダを付加したり、微修正をする。simpleは改編をほぼ認めないが、relaxedは、連続したスペースを一つにまとめるなどの変更を許容する。
❷DKIM署名の方法
・メール送信時に、（メールを送信したPCではなく、）送信メールサーバが、ハッシュ値を求め、送信者の秘密鍵で署名をする。署名した内容をメールヘッダに付与する。
・ハッシュ関数は、DKIMヘッダの「a=」で指定されたアルゴリズム（通常はSHA-256）を使う。
・本文のハッシュ値はDKIM署名の「bh=」に格納され、「h＝」で指定された情報をハッシュ化し、その値のデジタル署名をBase64エンコードした値は「b=」に格納される。
・DKIM署名のイメージは以下

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=plala.or.jp; q=dns/txt; s=p20240201; t=1717042923;
x=1748578923;（中略）
bh=sjDXyHL6vgVVG4LCQfX6NnNjrwyTgzk25mkBJT759NA=;
b=Iz9cpav56POlN0（省略）=;

・dタグを付加するが、変更不可と考えていいだろう。送信メールサーバのドメインに該当する。OpenDKIMの設定ファイル（/etc/opendkim/SigningTable）に指定しているので、もちろんdタグは変更は可能ではある。しかし、仮に偽装してamazon.co.jpにしたとしても、受信側はamazon.co.jpのDNSに問い合わせをしてしまうので、偽装する意味がない。業務委託なでで、正規に委託を受けている場合は、送信するメールごとに
ドメインが異なるのでdタグを変更することは可能である。
・署名するサーバは、送信側で決めればいい。
Q.内部メールサーバと外部メールサーバがあれば、どちらが一般的？
A.一番外なので、外部メールサーバ

(2)DKIM署名の検証
・受信側のメールサーバは、メールヘッダに記載がある「d=」のドメインを見て、そのドメインのDNSサーバに問い合わせ、そのドメインの公開鍵を取得する。TXTレコードは、(セレクタ)._domainkey.example.comという形式で記載されています。このとき、セレクタは、メールヘッダのDKIM署名において、「s=」で記載されている。
・受信したメールヘッダの署名を検証する。具体的には、よくあるデジタル署名と同じで、公開鍵で署名を基に戻し、自らハッシュした値と一致するかを確認する。
bhタグとbタグでは、ハッシュする対象がそもそも違う。以下を参照。
https://datatracker.ietf.org/doc/html/rfc6376#section-3.7
❶bhタグの検証
メール本文（※ヘッダは含まず）をハッシュ化し、計算されたハッシュ値がbhタグの値と一致するかを確認。
よくわかっていないのであるが、なぜbhが必要か？　本文の改ざんかヘッダの改ざんかを判断するためかもしれない。
なぜ、デジタル署名を付けないのか？bタグで本文を含めた検証するから不要ではないのか、という疑問がある。

❷bタグの検証　
・署名bを公開鍵で検証する。具体的には、署名を公開鍵で（秘密鍵で演算される前の）元に戻し、その値が、メール本文を含むヘッダのハッシュ値と一致するかを確認する。このとき、メール本文を使うのではなく、メール本文のハッシュ値はbhタグを使うようなことを聞いたが、定かではない。

Q.どういう場合に正規なメールでもDKIMのエラーになるか？　★★

3.5 作成者署名と第三者署名

(1)DKIMではなりすましが防げない
では問題です。
fake.domのドメインを持つ攻撃者が、メールヘッダ（Header-from）をauto-confirm@amazon.co.jpに偽装したとする。このとき、DKIM署名をつけたとすると、受信側ではDKIM署名の検証に失敗するか。

答えであるが、通常であれば、攻撃者のメールサーバでは、@amazon.co.jpがfake.domではないので、DKIM署名をしない。ところが、第三者署名の設定をしておくと、このヘッダも署名をする。
また、そのときのdタグはfake.domなので、受信側はfake.domに公開鍵を取りに行く。DKIM検証では途中で改ざんされていないかの確認しかできないので、DKIMはPassしてしまう。
これって困るよね。→DMARCにおいて、Header-fromとEnvelope-FROMは一致するけど、dタグはfake.domでHedderfromはamazon.co.jpなのでDMARCは失敗する。だからDMARCは重要。

(2)設定で確認
❶fake.domのメールサーバが、fake.domのメールを送る場合
・普通は作成者署名になるので、設定ファイル(/etc/opendkim/SigningTable)は以下のようになっている。

＊@fake.dom 20240123._domainkey.fake.dom

前半が署名をするメールアドレス。*が付与されているので@fake.domのドメインのメールはすべて、20240123._domainkey.fake.domの秘密鍵で署名するという意味。
参考までに、このセレクタに関して、秘密鍵の情報は以下のように設定ファイル（/etc/opendkim/KeyTable）に記載される。

# DKIMレコード名　ドメイン名:セレクタ名:秘密鍵ファイル
20240123._domainkey.fake.dom　fake.dom:20240123:/etc/opendkim/keys/fake.key

❷fake.domのメールサーバが、amazon.co.jpのメールを送る場合
・第三者署名として、送信元のメールアドレス（Header-From）が@amazon.co.jpの場合であっても、fake.domの秘密鍵でDKIM署名を付与する。

＊@fake.dom 20240123._domainkey.fake.dom
＊@amazon.co.jp 20240123._domainkey.fake.dom

秘密鍵の情報は変更無し。

# DKIMレコード名　ドメイン名:セレクタ名:秘密鍵ファイル
20240123._domainkey.fake.dom　fake.dom:20240123:/etc/opendkim/keys/fake.key

❸仮に、正規に第三者署名を行う場合。
amzonはありえないが、委託を受けてAmazonからのメールも送っているとする。その場合、dタグはamazon.co.jpにして、AmazonのDNSサーバに問い合わせるようにする。その場合の設定を述べる。
まず、設定ファイル(/etc/opendkim/SigningTable)は❷とは変える。ようは、fake.domとamazon.co.jpで異なる設定にするのである。

＊@fake.dom 20240123._domainkey.fake.dom
＊@amazon.co.jp amasel._domainkey.amazon.co.jp

一方、秘密鍵の情報の設定ファイル（/etc/opendkim/KeyTable）は、2行になる。Amazonから秘密鍵をもらっておく必要がある。これであれば、dタグはd=amazon.co.jpなので、DMARCも失敗することはない。

# DKIMレコード名　ドメイン名:セレクタ名:秘密鍵ファイル
20240123._domainkey.fake.dom　fake.dom:20240123:/etc/opendkim/keys/fake.key
amasel._domainkey.amazon.co.jp　amazon.co.jp:amasel:/etc/opendkim/keys/amazon.key

ちなみに、SigningTableやKeyTableにおけるamazon.co.jpの部分を、fake.comに変更すると、d=fake.comとして署名されるはずである（以下のように、全部を変える必要があるのか、部分的に変えてもそうなるのかは未検証なので要確認）

＊@fake.dom 20240123._domainkey.fake.dom
＊@amazon.co.jp amasel._domainkey.fake.dom

秘密鍵の情報の設定ファイル（/etc/opendkim/KeyTable）

# DKIMレコード名　ドメイン名:セレクタ名:秘密鍵ファイル
20240123._domainkey.fake.dom　fake.dom:20240123:/etc/opendkim/keys/fake.key
amasel._domainkey.fake.dom　fake.dom:amasel:/etc/opendkim/keys/amazon.key

4.偽装メール

4.1 攻撃者の考えで考える

たとえば、本物のamazonのメールに見せたいと思ってメールを送る

❶メールの表示名を偽装。
送信元メールアドレスはもっともらしいドメインを使う（正規に取得）

項目 値 偽装状態
本来のメールアドレス bad@amadon.dom 　-　
以下は実際に送るメール
送信元のメールサーバのIPアドレス x.x.x.x 　-　（偽装不可）
エンベロープ（Envelope-from） Return-Path:bad@amadon.dom 　-　（偽装無）
メールヘッダ（Header-From） From:Amazon.co.jp ＜auto-confirm@amadon.dom＞ 偽装
dタグ d=amadon.dom 　-　

Envelope-from、Header-Fromは、（いかがわしいドメインであるが、）どちらも正規。正規なので、SPFもDKIMもpassしてしまう。
認証結果は以下

認証技術 結果 理由
spf pass amadon.domでDNSサーバにSPFを設定すればいい
DKIM pass d=amadon.domであるが、普通にDKIM署名をすればいい
DMARC pass SPFがPassかつエンベローブfromとヘッダfromが一致しているため

このメールは送信元ドメイン認証では防げない。DMARCでも、Envelope-fromとHeader-Fromが一致しているので、防げない。
BIMIという手法がある。
https://www.naritai.jp/technology_bimi.html

❷メールの表示名と送信元メールアドレスを偽造する（普通の場合：作成者署名）

エンベロープ（Envelope-from） Return-Path:123456@fake.dom
メールヘッダ（Header-From） Subject:アカウント異常
From:Amazon.co.jp ＜admin@amazon.co.jp＞
dタグ d=fake.dom

つまり、Header-Fromが偽物。
・この場合、攻撃者がSPFレコードとして、fake.domのメールサーバのIPアドレスを指定していれば、SPFはエラーにならない。

ゾーンファイル
 $ORIGIN fake.dom.
  　IN　  TXT　 "v=spf1 ip4:203.0.113.25  ~all"　←IPアドレスを指定

・DKIMは、送信メールサーバにて、Header-Fromのadmin@amazon.co.jpはfake.domではないので、そもそも署名をしない。署名が無いからエラーになる。
・認証結果は以下

認証技術 結果 理由
spf pass 　
DKIM fail 　
DMARC FAIL SPFはPassしているがエンベローブfromとヘッダfromが不一致。また、DKIMは署名が無い

❸メールの表示名と送信元メールアドレスを偽造する（第三者の設定を入れる）

エンベロープ（Envelope-from） Return-Path:123456@fake.dom
メールヘッダ（Header-From） Subject:アカウント異常
From:Amazon.co.jp ＜admin@amazon.co.jp＞
dタグ d=fake.dom

つまり、Header-Fromが偽物。
・この場合、攻撃者がSPFレコードとして、fake.domのメールサーバのIPアドレスを指定していれば、SPFはエラーにならない。

ゾーンファイル
 $ORIGIN fake.dom.
  　IN　  TXT　 "v=spf1 ip4:203.0.113.25  ~all"　←IPアドレスを指定

・DKIMは、Header-Fromのadmin@amazon.co.jpという情報から、amazon.co.jpというドメインに対してTXTレコードを確認に行くのではなく、DKIM-Signatureの　d=で指定している公開鍵で署名検証をします。（攻撃者によ第三者署名）。なので、攻撃者は、fake.domのドメインのメールサーバなので、（自動で？）d=fake.domになる。ヘッダFROMが今回のように、@amazon.co.jpとなっていて、違うドメインであれば、本来であればDKIM署名をしない。しかし、メールサーバの設定にて、@amazon.co.jpであっても署名するという設定を施すと、DKIM署名を付けて相手に送る（これを第三者署名という）。そうされると、受信側で、DKIMの認証が成功する（途中で改ざんなどがされていない限り）　
・メールヘッダは以下

Return-Path: <Return-Path:123456@fake.dom>
・・・
Authentication-Results: dkim=pass (ok); dmarc=fail (p=QUARANTINE,sp=QUARANTINE,pct=100,domain=amazon.co.jp); header.from=amazon.co.jp
・・・
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=fake.dom; s=202406; t=1716357456;
  bh=nyD3E9bdpkPB/bNp2eKknmOxk5hds4z1khu2H/ZKLa0=;
  h=From:To:Subject:Date;
  b=VWcSqQUC8xVMuQtNsWDmePxUF9hEjrmHmCTNa4aBzH1cmBMApKRuObaLLQnWo42Md
   U0fdmpXBdBCdShUqADNx96Ihiqna5FhHyXjhN8VIoQQgjexXfHIZirf98fTk5rLLbV
   jbqU532Bp74M086u1bxJ48aMK0nIioVV6SuV2KNY=
From: amazon@amazon.co.jp

・認証結果は以下

認証技術 結果 理由
spf pass 　
DKIM pass 　
DMARC FAIL SPFはPassしているがエンベローブfromとヘッダfromが不一致。また、DKIMはPassしているが、dタグとヘッダfromが不一致のため。


であれば、SPFやDKIMでは防げない。Envelope-fromとHeader-Fromを比較するDMARCが必要。

❹Envelope-FROMを偽装
攻撃者が、Envelope-FROMも偽装して、本格的なメールに見せようとする。（ただし、攻撃者がEnvelope-FROMを偽装することはほぼない。受信者には表示されないのに、偽装する意義はない。）

エンベロープ（Envelope-from） Return-Path:auto-confirm@amazon.co.jp
メールヘッダ（Header-From） From:Amazon.co.jp ＜auto-confirm@amazon.co.jp＞
dタグ d=fake.dom

そもそも、DKIMはエンベロープFROMを見ていないし、先の❷と同様に、攻撃者のドメインのメールサーバから送られるので、dタグは攻撃者のドメインになる。よって、DKIMの署名でエラーになることはない。

Return-Path: <auto-confirm@amazon.co.jp>
・・・
Received-SPF: softfail (mxa.acity.co.jp: domain of transitioning auto-confirm@amazon.co.jp does not designate 122.1.91.97 as permitted sender) receiver=mxa.acity.co.jp; client-ip=122.1.91.97; envelope-from=auto-confirm@amazon.co.jp;
Authentication-Results: zmta7003.mail.djm.ynwp.yahoo.co.jp  from=amazon.co.jp; domainkeys=neutral (no sig); dkim=pass (ok); dmarc=fail (p=QUARANTINE,sp=QUARANTINE,pct=100,domain=amazon.co.jp); header.from=amazon.co.jp
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=fake.dom; s=20240423; t=1716719795;
	bh=E6pDkwiKDLkzB5AnsLo85U15f8W/tGYNS/EvvKvaWNg=;
	h=From:To:Subject:Date;
	b=cp/kil7YQaNMnl+D34SajMdL9dHCCulSL3SdKaEXz19cZnQKDFtfzr4csy+JuvREf
	 /BtBNxSsmBllsuHRbaBOO4Qycbc5iOMSWKCyjcvnycjgcaBXygSD7CIJQfPnjTmBcU
	 r+uMWvFy5uOYDXhqBYxQ0/5C6B+DocmTLZ50TnJY=
From: auto-confirm@amazon.co.jp

認証結果は以下

spf Soft-fail（つまり認証失敗） amazon.co.jpのメールサーバからメールが送られていないため
DKIM pass 第三者署名するから
DMARC fail dタグは.gov.ne.jpでhedderfromはamazon.co.jpなのでDMARCは失敗

このように、SPFが失敗する。なので、攻撃者はEnvelope-FROMを偽装してくることはないだろう。
・ちなみに、Envelope-FROMだけを偽装した場合、

spf Soft-fail（つまり認証失敗） amazon.co.jpのメールサーバからメールが送られていないため
DKIM pass 第三者署名するから
DMARC pass 　

❹正規メールが届いた場合
本当に正規のメールだが、標的型メール訓練のように、若干あやしい。それと、知らないドメインからのメール

Envelope-from Return-Path:admin@kennko-center.dom
Header-From Subject:健康診断のお知らせ
From:健康センター

認証結果は以下。正規なメールだから、全部passする

認証技術 結果 理由
spf pass
DKIM pass
DMARC pass

5.DMARC

5.1 DMARCの必要性

DMARCを導入しないとメールが拒否されるようになってきた。さらに、ポリシーはRejectにする必要がある。（これはレポート運用が結構大変なので、外部の運用会社に委託するのも選択肢）
・Googleのポリシー
https://support.google.com/a/answer/81126?hl=ja
・クレジットカード会社等に対するフィッシング対策強化の要請
「DMARC導入にあたっては受信者側でなりすましメールの受信拒否を行うポリシーでの運用を行うこと。」とあり、「受信拒否」が明記されている。
https://www.soumu.go.jp/menu_news/s-news/01kiban18_01000184.html

5.2 DMARCの導入状況

なりすましメール対策の実態調査結果を発表
https://emberpoint.com/news/release/release20240522.html

5.3 アライメント

Alignmentは、「調整」という言葉の意味通り、SPFやDKIMの結果に対して、Envelope-Fom、Header-FROM、dタグなどを確認することで、より正しい結果に調整をします。
具体的には、以下を確認します。

SPF エンベローブFromとヘッダFromの一致
DKIM ヘッダFromとDKIM署名のdタグの一致

DMARCでは、両方とも一致している必要はなく、どちらか一方でよかったりとか、どの場合にDMARCが合格になるかは少し複雑で、以下に表が記載されています。
https://baremail.jp/blog/2023/09/26/3474/?utm_source=google&utm_medium=cpc&utm_campaign=dsa&gad_source=1&gclid=CjwKCAjwx-CyBhAqEiwAeOcTdYZ-dstG4f30jHmm8hMJnqwCF6hYtm9Gm4Bl2BTguusn5dtT3Dg3LBoCW2sQAvD_BwE

Q.dmarcで送信側でp=noneにしてもアライメントのチェックはできる？

→A.できる。送信側のポリシー（P=の値）を無視することもできる。

Q.送信側でDMARCの設定をしていなくても、受信側でアライメントのチェックはできる？

→A.DMARCのレコードが無い。DMARCの結果がnoneなので、できない。
余談だが、Microsoft365はDMARCのレコードが書いて無くても、DMARCのレコードが書いてあったらどうなるか、アライメントン確認をして、best guess passに記載する。

Q.DMARCの設定を有効にした場合、受信側で、DKIMの設定を確認するドメインは何か。Envelope-FromのドメインではなくHeader-FROMのドメイン？

A.yes　Header-FROMのドメイン。

6.BIMI

DMARCであっても、類似ドメインを取得されると、人間だから気がつきにくい。もちろん、攻撃者が類似ドメインで正しい設定をすれば、SPF/DKIM/DMARCはPASSする。
たとえば、onetwo.domという正規のドメインがあったとすると、onetw0.domとして、最後を「o（オー）」→「0（ゼロ）」にする場合などです。
この場合の対処策として、認証をパスしたメールドメインに紐づくロゴ画像を表示する仕組みとしてBIMIがあります。BIMIは正規の商標登録がないと、利用できません。
以下、TwoFive社さんの資料からの引用です。

7メーラでできるフィッシングメール対策

ThunderbirdやGmailなどを例に、具体的な設定を解説。
Gmailはけっこうしっかりしていて、SPF、DKIM、DMARCがすべてOKじゃないと、メールを受け取らない。それ以外にも独自の仕様で迷惑メールに入れる。
個人でプロバイダのメールを持ち、Thunderbirdで運用していると、迷惑メールがたくさんくる。→Extentionの機能でDMARCの検査をしてくれるので、それを試してみるといいかも。