MXとA/AAAAを使う配送先の解決

取引先を名乗るメールを調べるときは、送信サーバのIP、配送先を選ぶDNS情報、SMTPのエンベロープ、表示用のFrom、DKIMの署名ドメインを別々に追う必要があります。この記事は、メールが届くまでの経路から実際のヘッダ調査と運用設計までを一続きで学ぶためのSC科目B（午後）教材です。以下のドメイン・IPアドレス・ログはすべて説明用です。

読み順は、①MXとSMTPで配送経路を確かめる、②SPF・DKIM・DMARCで認証対象を分ける、③転送時のSRS・ARCを見る、④ヘッダとログを突き合わせる、⑤演習で判断を確かめる、です。ログではまず『どの受信点が、どの接続元IPを見たか』を決め、その後にMAIL FROM、Header From、DKIM d=を照合します。

1. 最初に把握する全体像

配送先を決める：宛先アドレスのドメインからMXを調べ、MXが指すホストのA/AAAAから接続先IPを得る。
送信を許可する：受信側はSMTP接続元IPとMAIL FROMのドメインを使ってSPFを評価する。
メッセージの署名を検証する：受信側はDKIM-Signatureのd=とs=から公開鍵を探し、署名対象のヘッダと本文を検証する。
表示上の差出人を確かめる：DMARCはHeader Fromと、passしたSPFのMAIL FROMまたはpassしたDKIMのd=が整合するかを調べる。
被害を判断する：認証がpassしても本文の安全性や送信者個人の正当性は証明されない。配送ログ、アカウント操作、URLなども調べる。

MX・A/AAAAは『どこへ配送するか』、SPF・DKIM・DMARCは『そのドメインを名乗ることをどう評価するか』に関係します。役割の異なるDNSレコードを混同しないことが、構成図とログを解く出発点です。

2. メール配送の登場人物とSMTPの経路

MUA（Mail User Agent）：利用者のメールアプリ。送信や閲覧の画面を提供する。
MSA（Mail Submission Agent）：利用者や業務アプリからの投稿を受け付ける。投稿者の認証・送信権限確認・送信制限を担える。
MTA（Mail Transfer Agent）：他ドメインへの中継・配送を行う。送信側MTAと受信側MXの間でもSMTPが使われる。
MDA／メールストア：受信後に宛先のメールボックスへ配送・保存する。受信側の認証判定はMXやフィルタなど、その組織の構成に応じた場所で行う。

典型例では、利用者端末→投稿用MSA→送信MTA→宛先ドメインのMX→受信者のメールボックスと進みます。投稿用の587番ポートとMTA間の25番ポートは目的が違います。465番は投稿時に接続開始からTLSを使う方式です。SMTP AUTHは投稿者とMSAの間の認証であり、受信者が見るHeader Fromの真正性を単独で証明しません。

MXとA/AAAAを使う配送先の解決

宛先ドメインのMXから受信ホストを選び、そのA/AAAAからIPアドレスを得る概略。再帰DNSのキャッシュや上位DNSへの反復問い合わせは省略。

図の前半は宛先ドメインのMXから受信ホスト名を得る段階、後半はそのホスト名のA/AAAAから接続先IPを得る段階です。送信MTAがSMTPで接続する相手は最後に選んだ受信MXであり、SPFで評価する送信側の接続元IPとは別に記録します。

2-1. MX、A、AAAAを1件ずつ読む

次は example.com 宛てメールを受けるために参照する架空のDNSレコードをまとめた例です。複数ドメインに属するレコードを一緒に示しており、単一ゾーンファイルではありません。末尾のドットは完全修飾ドメイン名を表します。TTL 3600 はキャッシュ可能な時間の目安で、3600秒後に必ず全キャッシュが一斉に更新されるという意味ではありません。

text

example.com.       3600 IN MX   10 mx1.example.net.
example.com.       3600 IN MX   20 mx2.example.net.
mx1.example.net.   3600 IN A       192.0.2.25
mx1.example.net.   3600 IN AAAA    2001:db8::25
mx2.example.net.   3600 IN A       192.0.2.26

宛先が user@example.com なら、SMTP配送先を探す送信MTAは example.com のMXを問い合わせる。MXの値はIPアドレスではなくホスト名である。
優先度の数値が小さい mx1.example.net を優先候補とし、利用できなければ別候補を試す。10や20はポート番号ではない。
選んだMXホスト名のA（IPv4）またはAAAA（IPv6）を引き、得られたアドレスへSMTP接続を試みる。Aは『送信者を認証するレコード』ではない。
MXが存在しない場合だけ、宛先ドメイン自身のA/AAAAを配送先として試す規則がある。MXはあるがホスト名を解決できないときに、無条件で宛先ドメインのAへ逃げるわけではない。

MXの参照先にはA/AAAAで解決できるホスト名を用い、CNAMEの別名をMXの参照先にしないのがDNS仕様です。受信しないドメインは『MX 0 .』というNull MXで受信しないことを明示できます。Null MXを通常の予備MXと混在させてはいけません。

同じ優先度のMXが複数ある場合は、送信MTAが候補に負荷を分散できます。MXのホスト名に複数のA/AAAAがあれば接続先IPも複数あり得ます。あるIPへの接続失敗がそのまま全配送の失敗を意味するわけではありません。逆に、MX応答が存在するのに参照先のA/AAAAが壊れている場合は設定障害です。接続できないときはSMTPの一時失敗・再試行・キュー滞留を調べます。

DNSの応答も原因別に区別します。『MXがない』と『ドメイン自体が存在しない（NXDOMAIN）』と『DNSが一時的に応答できない（SERVFAILやタイムアウト）』は同じではありません。MXなしの暗黙的なA/AAAA配送規則、Null MXによる受信拒否の明示、一時的なDNS障害を混同すると、対策を誤ります。

2-2. この教材で使うDNSレコードの役割

MX：宛先ドメインがメールを受けるサーバの名前と優先度。送信ドメイン認証そのものではない。
A／AAAA：ホスト名をIPv4／IPv6アドレスへ変換する。MXホストや送信MTAの名前をIPへ解決する際に使う。
TXT：SPFポリシー、DKIM公開鍵、DMARC方針などを置く。ただし置く名前とレコード内部の書式は技術ごとに違う。
PTR：IPアドレスから名前を引く逆引きレコード。受信側の接続元調査や評判判定に役立つ場合があるが、PTRがあるだけでSPF・DKIM・DMARCがpassするわけではない。
CNAME：別名を示す。DKIM鍵の委任でプロバイダが指示する構成もあるが、MXの参照先をCNAMEにしてよいという意味ではない。

特に重要な区別は『受信のMXホストのIP』と『今このSMTPセッションで接続してきた送信MTAのIP』です。SPFは後者を評価します。受信MXが192.0.2.25だから送信元も192.0.2.25と決めつけてはいけません。

3. SMTPエンベロープとメールヘッダは別物

SMTPは配送のためのMAIL FROMとRCPT TOをDATAより前に伝えます。DATAの中にあるFrom・To・Reply-Toは表示や返信に用いるヘッダです。以下は概略で、実際の応答コードやTLS交渉は省略しています。

smtp

S: 220 mx.example.net ESMTP ready
C: EHLO out1.example.com
C: MAIL FROM:<bounce@example.com>
C: RCPT TO:<user@recipient.example>
C: DATA
C: From: 経理部 <invoice@example.com>
C: To: user@recipient.example
C: Reply-To: payment@vendor.example
C: Subject: 請求書
C:
C: ...本文...
C: .

MAIL FROM（エンベロープFrom、reverse-path）：配送エラー通知の返送先などに使うSMTP上の値。SPFの主な評価対象。最終配送時にReturn-Pathヘッダとして記録されることが多い。
Header From（RFC 5322.From）：メールアプリに表示される差出人。DMARCが整合の基準にする。SMTPのMAIL FROMと一致する義務はない。
RCPT TO（エンベロープ宛先）：SMTPで実際に配送する宛先。ToやCcは表示用ヘッダなので、Bccの相手がRCPT TOに含まれてもToには現れない場合がある。
Reply-To：返信操作で使う宛先を指定できる。Fromと違えば調査の手掛かりになるが、違うだけで詐欺とは断定しない。
EHLO／HELO：SMTP接続中に送信側が名乗るホスト名。SPFではHELOを別途評価できるが、DMARCのSPF整合はMAIL FROMの認証結果を用いる。
Sender：代理送信者を示す表示ヘッダ。Header FromやMAIL FROMの代わりにDMARCの基準になるわけではない。

MAIL FROMが空の『MAIL FROM:<>』は配送不能通知などで使われます。このときSPFはHELOドメインを使う特別な評価規則があります。通常メールのMAIL FROMと同じ前提でログを読まないでください。

4. SPF：接続元IPに送信を許す仕組み

4-1. 何を照合するか

受信MTAは接続してきたSMTPクライアントのIP、MAIL FROMのドメイン、HELO名などを把握します。MAIL FROMのドメインのTXTレコードにあるSPF方針を取り、IPが許可条件に当てはまるかを順に評価します。『差出人アドレス全体』や本文を検証する方式ではありません。

text

example.com.  IN TXT "v=spf1 ip4:192.0.2.40 include:_spf.sender.example -all"
out1.example.com. IN A 192.0.2.40

v=spf1：SPFレコードであることを示す。SPFはDNSのTXTに公開し、旧来のSPF専用RRタイプに依存しない。
ip4:192.0.2.40：このIPv4アドレスからの接続を認める。ip6:はIPv6用。必要ならCIDR範囲も指定できる。
include:_spf.sender.example：外部配信サービスなどのSPF方針を評価に取り込む。参照先がpassとなる条件に接続元IPが合うと、このincludeに一致する。単なる文字列のコピーではない。
a：指定ドメインのA/AAAAが接続元IPに一致するか調べる。mx：指定ドメインのMXが指すホストのA/AAAAに一致するか調べる。どちらもDNS参照を増やし得る。
redirect=：前の機構がどれにも一致しなかったとき、別ドメインのSPF方針で評価を続ける修飾子。includeとは動きが違う。
-all：ここまで一致しないIPはfail。~allならsoftfail、?allならneutral、+allならpassで、+は省略可能。これらは評価結果であり、受信側の採用・拒否処理そのものではない。

同じ名前にv=spf1で始まるSPFレコードを複数置くとpermerrorになります。一つのTXTレコードをDNSの長さ制限に合わせて複数の文字列へ分割した場合は、受信側が連結して一つのSPFレコードとして扱います。二つのSPFレコードを公開する場合とは区別してください。

DNS参照を伴うinclude・a・mx・exists・ptr・redirectなどは、参照先の入れ子も含めて最大10件。超えるとpermerrorになる。IPごとの実際のDNSパケット数を数える規則ではない。
ip4・ip6・allは10件の枠に入らない。構成変更時は入れ子のincludeまで数え直す。
存在しない名前への問い合わせで生じるvoid lookupは2件が推奨上限。実装が上限を適用して超過すればpermerrorになる。

4-2. include・redirectを最後まで評価する

次のDNSレコードは別々の所有名の設定例です。比較のため、どの送信元もMAIL FROM:<bounce@example.com>、Header Fromはinvoice@example.comとして、example.comのSPFを評価します。

dns

example.com. IN TXT "v=spf1 ip4:192.0.2.40 include:_spf.sender.example -all"
_spf.sender.example. IN TXT "v=spf1 ip4:203.0.113.20 -all"

接続元192.0.2.40は先頭のip4に一致してpass。後続のincludeは評価しない。
接続元203.0.113.20は先頭のip4に一致しない。include先を評価してpassになるため、親のincludeにも一致し、example.comのSPFはpass。
接続元198.51.100.9はinclude先のip4に一致せず、参照先の-allでfailになる。このfailは親のincludeの『不一致』として扱い、親の次の-allで最終的にfailになる。参照先のfailで親の評価が直ちに終わるわけではない。
参照先がDNS一時障害でtemperror、または構文・参照制限違反でpermerrorなら、親のincludeもそのエラーを返す。参照先にSPF方針がなくnoneなら、includeはpermerrorになる。

上の設定ではincludeは1件のDNS参照を伴う評価項目で、参照先のip4と双方の-allは10件の枠を消費しません。入れ子にさらにincludeやaなどがあれば、その評価分も数えます。IPごとのDNS問い合わせ回数そのものを数える規則ではありません。

redirectは、元のレコードのどの機構にも一致しない場合に別ドメインの方針へ判定を委ねます。たとえば『v=spf1 ip4:192.0.2.40 redirect=_spf.sender.example』で192.0.2.40以外の接続元なら、参照先の最終結果を使います。元のレコードに-allを置くと必ずallに一致するため、redirectは評価されません。

dns

example.com. IN TXT "v=spf1 ip4:192.0.2.40 " "include:_spf.sender.example -all"

最後の行は先頭のSPFレコードを二つの文字列に分割して公開する場合の表記です。二つのTXTレコードを並べる例ではなく、同じ所有名の一つのTXTレコード内で文字列が連結されます。

4-3. 結果をどう読むか

pass：接続元IPがそのSPFドメインの方針に合う。Header Fromとの一致や本文の安全性はまだ判断できない。
fail／softfail：明示的な不許可／弱い不許可。拒否するかは受信側の方針、DMARC、他の情報で決まる。
none：評価対象ドメインに有効なSPF方針がないなど。
temperror：DNS障害など一時的な評価不能。permerror：複数SPFレコードや制限超過など、レコードの恒久的な問題。

SPFのmx機構はMAIL FROM側のドメインのMXホストを利用する場合の話です。『宛先ドメインのMXレコードがあるからSPFもpass』という解釈は誤りです。また、転送で接続元IPが変わると元のMAIL FROMドメインのSPFは失敗し得ます。

5. DKIM：署名されたヘッダと本文を検証する仕組み

5-1. 署名者と公開鍵の位置

送信側は秘密鍵でメールの一部ヘッダと本文のハッシュに対する署名を作ります。受信側はDKIM-Signatureのd=（署名ドメイン）とs=（セレクタ）から『s=の値._domainkey.d=の値』というDNS名を組み立て、TXTにある公開鍵で検証します。秘密鍵はDNSに公開しません。

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=example.com; s=s2026; h=from:to:subject:date;
  bh=<本文ハッシュのBase64>; b=<署名のBase64>

s2026._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=<公開鍵のBase64>"

d=は署名に責任を持つドメイン。DMARCのDKIM整合でHeader Fromと比べる。s=は鍵を切り替えるセレクタ。
h=は署名対象のヘッダ名。Fromは署名対象に含める必要がある。署名されていないヘッダは後段で変えられる場合がある。
bh=は正規化後の本文のハッシュ。b=はヘッダと本文ハッシュを含むデータに対する署名値。両者を同じものとして読まない。
a=は署名アルゴリズム。c=はヘッダ／本文の正規化方法で、relaxedは一部の空白・改行表現の差を吸収するが、意味のある本文変更を無条件に許すものではない。
t=は署名時刻、x=は有効期限として使える。l=は署名する本文長を制限できるが、末尾の未署名部分が残るため運用上の注意が必要。

DKIMがpassするのは、署名された範囲が検証時に整合し、そのd=のドメインの鍵で検証できたという意味です。本人の氏名、表示名、送信内容の善悪、添付ファイルの安全性を保証しません。一通に複数のDKIM署名がある場合もあり、DMARCではそのうち整合する有効な署名を使えます。

5-2. 失敗・運用の落とし穴

メーリングリストや転送サービスが件名、本文、フッタを変えると、署名対象に応じてDKIMがfailになり得る。単純な転送なら残る場合もある。
公開鍵レコードが存在しなければRFC 6376の検証手順ではPERMFAIL（no key for signature）。DNSが応答しない場合のTEMPFAIL、公開鍵はあるが署名・本文ハッシュが一致しない場合のPERMFAILを分ける。Authentication-Resultsのdkim=fail・permerror・temperrorなどの表示と理由文は実装ごとに確認する。
鍵をローテーションするときは新旧セレクタの公開鍵を適切に併存させる。配送中の旧署名メールとDNSのキャッシュ・負のキャッシュを考えずに古い鍵を即時削除しない。
配信サービスが自社ドメインではなく vendor.example のd=で署名するとDKIM自体はpassしても、Header Fromがexample.comならDMARCのDKIM整合には使えない。

6. DMARC：表示Fromとの整合と受信側への方針提示

DMARCはHeader Fromを基準にします。適用可能な有効なDMARC方針レコードが取得できた場合、SPFでpassしたMAIL FROMのドメイン、またはDKIMでpassしたd=のドメインのうち、少なくとも一方がHeader Fromと整合すればDMARCはpassになります。SPFとDKIMの両方がpassする必要はありません。逆に、両方passでもどちらも整合しなければDMARCはfailです。

SPF・DKIM・DMARCの評価対象

SPFとDKIMのpassは各方式の検証結果。DMARCはpassした識別子とHeader Fromの整合を判定する。

次の式と判定図は、Header Fromに適用可能な有効なDMARC方針を取得できた場合の認証判定です。方針が存在しなければDMARCは適用されず、Authentication-Resultsではdmarc=noneなどとして表されます。DNSの一時障害や不正な方針レコードも、単なる整合失敗とは分けて調べます。受信側による配送・隔離・拒否は、DMARCのpass・failとは別の判断です。

text

DMARC pass = (SPF pass かつ MAIL FROM が Header From と整合)
          または (DKIM pass かつ d= が Header From と整合)

DMARC pass・failの判定

1. はい
2. いいえ
3. はい
4. いいえ

有効なDMARC方針を取得できた場合の判定。SPFとDKIMはpassに加えてHeader Fromとの整合が必要。方針なし・DNS障害・レコード不正は図の対象外。

判定図では、整合するSPFがpassした時点でDMARCはpassです。そうでない場合に整合するDKIMを確認します。両経路とも成立しなければDMARC failですが、配送を拒否するかどうかは受信側の方針で判断します。

6-1. relaxedとstrictの違い

Header From=example.com、MAIL FROM=mail.example.com：aspf=r（既定）なら、組織ドメインが一致するので整合し得る。aspf=sなら完全一致ではないため不整合。
Header From=example.com、DKIM d=example.com：adkim=rでもadkim=sでも、DKIMがpassすれば整合する。
Header From=example.com、DKIM d=vendor.example：署名がpassしても別ドメインなので整合しない。
Header From=example.com、MAIL FROM=example.net：SPFがpassしても別ドメインなので整合しない。

relaxedは単なる末尾文字列の部分一致ではありません。組織ドメインの判定に基づきます。RFC 9989ではDMARC方針の探索・組織ドメインの扱いが従来のRFC 7489から更新されています。試験問題では問題文の定義や与えられたドメイン階層も確認します。

6-2. DMARCレコードと方針タグ

dns

_dmarc.example.com. IN TXT (
  "v=DMARC1; p=none; sp=quarantine; adkim=r; aspf=r;"
  " rua=mailto:dmarc-report@example.com"
)

_dmarc.example.comのTXTに置く。v=DMARC1はバージョン。DMARCレコードを通常のexample.com直下のSPF TXTと混同しない。
p=noneは監視、quarantineは隔離希望、rejectは拒否希望。これは送信ドメイン側が示す評価方針で、最終的な配送・例外扱いは受信側の判断が入る。
sp=は既存サブドメイン向けの方針。RFC 9989のnp=は存在しないサブドメイン向けの方針。未指定時の継承関係にも注意する。
adkim=／aspf=はそれぞれDKIM／SPFの整合モード。rがrelaxed、sがstrict。省略時はr。
rua=は集計レポートの送付先。送信元IP、認証結果、適用方針などの傾向把握に使う。ruf=は失敗レポートの送付先だが、提供状況や個人情報への配慮が必要。
古い資料にあるpct=は2026年のRFC 9989では廃止扱い。新しいt=はテスト運用に関するタグであり、百分率で適用する仕組みではない。

方針は『最初から必ずp=rejectへ』と機械的に決めません。特に転送やメーリングリストを使う一般用途ドメインでは、RFC 9989が相互運用上の問題を指摘しています。正規送信経路の洗い出しとレポート分析、受信側の例外処理を踏まえて選びます。

6-3. 集計レポートで認証結果と適用結果を読む

rua宛ての集計レポートは一通ごとの完全なヘッダではなく、観測期間内の送信元IP・認証結果・方針適用結果をまとめたXMLです。次の二つはRFC 9990のrecord要素を抜き出した架空の例で、完全なレポートにはreport_metadataやpolicy_publishedも含まれます。実際の受信者、本文、個々の送信者はこの集計だけでは特定できません。

例Aの公開方針はp=quarantineです。送信元203.0.113.20から観測された12通では、vendor.exampleのSPF自体はpassしてもHeader Fromのexample.comと整合せず、policy_evaluatedのspfはfailです。

xml

<record>
  <row><source_ip>203.0.113.20</source_ip><count>12</count>
    <policy_evaluated><disposition>quarantine</disposition>
      <dkim>fail</dkim><spf>fail</spf></policy_evaluated></row>
  <identifiers><envelope_from>vendor.example</envelope_from>
    <header_from>example.com</header_from></identifiers>
  <auth_results><spf><domain>vendor.example</domain>
    <result>pass</result></spf></auth_results>
</record>

例Bの公開方針はp=rejectですが、受信側のローカル方針で例外処理した3通です。policy_evaluatedのdispositionがnoneでも、認証がpassしたという意味ではありません。reasonのlocal_policyは受信側が上書きした理由を表します。

xml

<record>
  <row><source_ip>198.51.100.30</source_ip><count>3</count>
    <policy_evaluated><disposition>none</disposition>
      <dkim>fail</dkim><spf>fail</spf>
      <reason><type>local_policy</type></reason></policy_evaluated></row>
  <identifiers><envelope_from>example.com</envelope_from>
    <header_from>example.com</header_from></identifiers>
  <auth_results><spf><domain>example.com</domain>
    <result>fail</result></spf></auth_results>
</record>

source_ipはその受信側が見たSMTP接続元。転送時は元の送信MTAのIPとは限らない。countは同じ観測組の通数であり、一通の配送経路の長さではない。
auth_resultsはSPF・DKIMそのものの検証結果。policy_evaluatedのspf・dkimはHeader FromとのDMARC整合まで評価した結果。両欄にpass／failがあるときは評価対象を区別する。
policy_publishedは送信ドメインが公開した希望。dispositionは受信側が適用した扱い。reasonがあれば例外理由を読み、受信者のメールボックスへの最終到達は配送ログで確認する。
あるsource_ipを正規の配信元だと確定するには送信元台帳、委託先設定、接続・投稿ログを照合する。集計レポートの増減だけで攻撃・漏えいを断定しない。

以下の図は、集計レポートの各結果が受信側で作られるまでの概略です。図のDNS照会は必要な情報の取得を示し、製品が必ずこの順序で問い合わせることを意味しません。

受信側の認証とDMARC整合確認

接続元IPとMAIL FROMでSPF、署名のd=とs=でDKIMを検証し、最後にHeader Fromとの整合を判定する概略。

SPFとDKIMはそれぞれの対象を検証し、DMARCではpassした識別子とHeader Fromの整合を調べます。図の最後の『配送』には受信側の隔離・拒否・例外処理という分岐もあるため、認証結果と最終到達は別のログで確認します。

7. 転送・SRS・ARCで何が変わるか

7-1. 単純転送とメーリングリスト

A社の送信MTA→転送サーバ→最終受信MTAという経路では、最終受信MTAから見える接続元IPは転送サーバです。元のMAIL FROMを保持すると、元ドメインのSPFに転送サーバのIPが載っていないためSPFは失敗し得ます。DKIMはメッセージが変わらなければ生き残る場合がありますが、リストの件名追加・フッタ付与などで失敗し得ます。

7-2. SRSによるエンベロープの書換え

SRS（Sender Rewriting Scheme）：転送サーバがエンベロープMAIL FROMを自分の管理するドメインに書き換え、配送エラーを元送信者へ戻せるようにする方式。転送先で転送サーバのSPFがpassしても、元のHeader FromとのDMARC整合が自動で得られるわけではない。

次はexample.comからforwarder.exampleを経てrecipient.exampleへ届く一通の例です。元のexample.comのSPFは192.0.2.40だけを許し、forwarder.exampleのSPFは203.0.113.50を許すものとします。書換え後のローカル部の形は実装ごとに異なるため、SRS0から始まる次のアドレスは説明用の例です。

text

元のホップ: peer=192.0.2.40 MAIL FROM:<bounce@example.com>
            Header From: invoice@example.com
転送後:    peer=203.0.113.50
            MAIL FROM:<SRS0=abc=xy=example.com=bounce@forwarder.example>
            Header From: invoice@example.com
最終受信点: spf=pass smtp.mailfrom=forwarder.example
            dkim=fail header.d=example.com（転送時に本文へフッタを追加した場合）
            dmarc=fail header.from=example.com

元のホップでのSPF passは192.0.2.40とexample.comの方針による。転送後の受信点では接続元が203.0.113.50に変わり、元のMAIL FROMをそのまま使えばexample.comのSPFはfailになり得る。
SRSでMAIL FROMをforwarder.exampleへ変えると、転送先では203.0.113.50をforwarder.exampleのSPFで評価してpassし得る。Header Fromはexample.comのままなので、このSPF passはDMARCのSPF整合に使えない。
本文にフッタを追加して元のDKIM署名もfailした例では、整合する認証結果がなくDMARCはfail。元のDKIM署名が保たれれば、整合するDKIMによりDMARCはpassし得る。
配送不能通知は転送後のエンベロープ宛先へ戻る。forwarder.exampleはSRSの検証・復号によって元のbounce@example.comを特定し、必要な返送処理を行う。正しく書き換えても、転送経路やバウンスが必ず成功する保証にはならない。

多段転送で再びエンベロープを書き換える構成では、後段が既存のSRSアドレスを包むSRS1形式を用いる実装もあります。SRS0・SRS1という文字列だけから元の送信者や認証結果を断定せず、各ホップのSMTPログと実装の変換規則を確認します。

7-3. ARCが残す中継前の評価

ARC-Authentication-Results（AAR）：中継者が受信した時点でのSPF・DKIM・DMARCなどの評価結果を記録する。後段の現在の認証結果とは区別する。
ARC-Message-Signature（AMS）：中継者が扱ったメッセージの内容に署名する。後続の改変で検証できなくなる場合がある。
ARC-Seal（AS）：その中継者のARCセットとそれ以前の連鎖を封印する。i=はセットの順序、cv=はその時点で検証した従前の連鎖の状態を示す。最初のi=1ではcv=none、次のi=2では検証できればcv=pass、破損していればcv=failとなる。

次は二つの中継者が付けたヘッダを生成順に並べた概念例です。実際のヘッダの表示順ではなく、署名値や署名に必要なタグも省略しているため、この断片自体は検証できません。forwarder.exampleは受信時のDMARC passを記録し、件名を変更してからi=1のARCセットを付けます。relay.exampleでは元のDKIMがfailする一方、i=1のARC連鎖は検証できたとします。

ARC-Authentication-Results: i=1; forwarder.example;
  spf=pass smtp.mailfrom=example.com;
  dkim=pass header.d=example.com; dmarc=pass header.from=example.com
ARC-Message-Signature: i=1; d=forwarder.example; s=arc2026; b=<署名値>
ARC-Seal: i=1; d=forwarder.example; s=arc2026; cv=none; b=<署名値>
ARC-Authentication-Results: i=2; relay.example;
  spf=fail smtp.mailfrom=example.com;
  dkim=fail header.d=example.com; dmarc=fail header.from=example.com;
  arc=pass
ARC-Message-Signature: i=2; d=relay.example; s=arc2026; b=<署名値>
ARC-Seal: i=2; d=relay.example; s=arc2026; cv=pass; b=<署名値>

AARのi=1とi=2は各中継者がその時点で観測した結果です。後段のdmarc=failをi=1のdmarc=passで上書きするわけではありません。最終受信側はARC連鎖の検証結果と中継者への信頼を別々に判断し、自組織の方針で配送上の例外を認めることがあります。cv=passやarc=passだけでは元の内容の安全性も中継者の信頼性も証明できません。

科目B（午後）の問題で転送経路が出たら、各ホップごとに『接続元IP』『MAIL FROM』『Header From』『DKIM署名が維持されたか』を並べ直します。最初の受信点のSPF結果を最終受信点の結果にそのまま流用しません。

8. SMTP AUTHとTLSは送信ドメイン認証とどう違うか

SMTP AUTH：端末やアプリが投稿用MSAへ認証する仕組み。認証成功は投稿権限の根拠だが、盗まれたアカウントからの詐欺メールも送れてしまう。
STARTTLS：SMTP接続後にTLSへ切り替え、当該ホップを暗号化する。平文での配送を許す構成ではダウングレードの検討が必要。
465番のImplicit TLS：投稿接続の開始時からTLSを使う。587番でのSTARTTLSと同じ『送信者ドメインのDMARC検証』ではない。
MTA-STSなどの配送TLS方針：MTA間のTLSやMX名の検証を強めるための別の設計。SPF・DKIM・DMARCの代替ではない。
オープンリレー：認証や中継元・宛先の制限を誤り、第三者が任意の宛先へ中継できる状態。SPFレコードを公開しただけでは解消しない。

通信路の暗号化、投稿者のアカウント認証、ドメインを名乗る権限の検証、メール本文の危険判定は別の層です。設問で『何を防ぐ対策か』を必ず区別します。

9. Authentication-ResultsとReceivedを調査で読む

9-1. まず信頼できる行を選ぶ

Authentication-Resultsには判定を実行したauthserv-idが記録されます。外部から同名ヘッダを偽装して持ち込むこともできるため、自組織の受信境界が付けた行を選び、必要ならMTAのSMTPログと照合します。Receivedも古い行ほど外部が付けた可能性があり、上から機械的に全部信用しません。メールアプリの画面だけでなく、原本の.emlや管理側のログを保存して分析します。

9-2. 接続ログ・DNS・ヘッダを1通分つなげて読む

以下は受信側mx.recipient.exampleが記録した架空の1通です。DNSレコードは同時点で観測したものとします。SMTP接続元IPと宛先MXのIPを取り違えないように、値を並べます。

text

受信側SMTPログ:
  peer=192.0.2.40 helo=out1.example.com
  mail_from=bounce@example.com rcpt_to=user@recipient.example
宛先DNS: recipient.example MX 10 mx.recipient.example.
宛先DNS: mx.recipient.example A 192.0.2.25
認証用DNS: example.com TXT "v=spf1 ip4:192.0.2.40 -all"
認証用DNS: s2026._domainkey.example.com TXT
  "v=DKIM1; k=rsa; p=<公開鍵>"
認証用DNS: _dmarc.example.com TXT "v=DMARC1; p=quarantine"

Return-Path: <bounce@example.com>
Authentication-Results: mx.recipient.example;
  spf=pass smtp.mailfrom=example.com;
  dkim=pass header.d=example.com header.s=s2026;
  dmarc=pass header.from=example.com
Received: from out1.example.com (out1.example.com [192.0.2.40])
  by mx.recipient.example with ESMTPS; Thu, 24 Sep 2026 10:00:00 +0000
From: 経理部 <invoice@example.com>
DKIM-Signature: v=1; d=example.com; s=s2026; ...

recipient.exampleのMXは、recipient.example宛てメールを受けるmx.recipient.exampleを示す。192.0.2.25は受信側ホストのIPであり、このメールのSPFで照合するIPではない。
受信側が実際に観測した接続元は192.0.2.40。MAIL FROMのexample.comのSPF TXTにあるip4条件と一致するためSPF pass。
DKIMのd=example.com、s=s2026から公開鍵の名前を組み立て、署名された内容を検証できたのでDKIM pass。鍵レコードが存在するだけではpassにならない。
Header Fromがexample.comで、passしたSPFのMAIL FROMとDKIMのd=もexample.com。少なくとも一方が整合すればよいのでDMARC pass。p=quarantineはDMARC fail時の希望であり、この例のメールを自動隔離する指示ではない。

宛先DNSのMXは、この受信処理のSPF判定には不要です。設問で『受信先を求めるDNS参照』と『認証に使うDNS参照』を色分けすると、AレコードとSPFの取り違えを防げます。

9-3. 複数ホップのReceivedとMTAログを対応させる

次はout1.example.com→forwarder.example→mx.recipient.example→store.recipient.exampleという別の一通です。転送では元のMAIL FROMを維持し、DKIMが保たれたとします。mx.recipient.exampleが付けたSPF fail・DKIM pass・DMARC passは、この受信点での評価です。上から新しいReceivedが並びます。

Received: from mx.recipient.example (mx.recipient.example [192.0.2.25])
  by store.recipient.example with ESMTP id IN-803
  for <user@recipient.example>; Thu, 24 Sep 2026 10:02:00 +0000
Authentication-Results: mx.recipient.example;
  spf=fail smtp.mailfrom=example.com;
  dkim=pass header.d=example.com; dmarc=pass header.from=example.com
Received: from forwarder.example (forwarder.example [203.0.113.50])
  by mx.recipient.example with ESMTPS id MX-517
  for <user@recipient.example>; Thu, 24 Sep 2026 10:01:00 +0000
Authentication-Results: mx.recipient.example;
  spf=pass smtp.mailfrom=example.com; dkim=pass header.d=example.com
Received: from out1.example.com (out1.example.com [192.0.2.40])
  by forwarder.example with ESMTPS id FW-204
  for <user@recipient.example>; Thu, 24 Sep 2026 10:00:00 +0000
Message-ID: <invoice-42@example.com>
From: 経理部 <invoice@example.com>

二つ目のAuthentication-Resultsは外部から持ち込まれた偽行という想定です。受信境界が規格どおり同じauthserv-idを名乗る外部行を削除していれば、実際の受信メールにこの形では残りません。残った場合も『mx.recipient.example』という文字列だけでは信用せず、MX-517の受信ログと自組織の境界設定で上の行を確かめます。

text

mx.recipient.example: id=MX-517 peer=203.0.113.50
  mail_from=bounce@example.com rcpt_to=user@recipient.example
  result=accepted
store.recipient.example: id=IN-803 peer=192.0.2.25
  rcpt_to=user@recipient.example result=delivered

fromはそのReceivedを付けたMTAから見た直前の接続相手、byは受信したMTA、withは使った転送方式、idはそのMTAが付けたキュー識別子、forは記録されていればそのホップの宛先、末尾は受信時刻。古い行へ向かって10:02→10:01→10:00とたどる。
自組織が管理するstoreとmxのReceivedは、それぞれIN-803とMX-517のMTAログへ照合する。FW-204はforwarder側の識別子であり、自組織のMX-517と同じ値になる必要はない。外部ログを入手できなければforwarderより前の経路は確定できない。
mxが観測した接続元は203.0.113.50。元のexample.comのSPFにこのIPが含まれなければspf=failでも、Header Fromと整合するDKIM passでDMARCはpassし得る。下の偽行のspf=passを採用すると接続元の判断を誤る。
Message-IDは送信者側が付けられるため、同じ値だけで信頼できる配送経路や送信者本人を証明しない。複数MTA間の照合では時刻・宛先・送信元・サイズ・キューID・原本を合わせて確認する。

9-4. ケースA：SPFもDKIMもpassだがDMARC fail

From: 経理部 <invoice@example.com>
Return-Path: <bounce@vendor.example>
Authentication-Results: mx.recipient.example;
  spf=pass smtp.mailfrom=vendor.example;
  dkim=pass header.d=vendor.example;
  dmarc=fail header.from=example.com

spf=pass はvendor.exampleのMAIL FROMについての結果。Header Fromのexample.comのSPFがpassしたと読まない。
dkim=pass はvendor.exampleのd=で署名が検証できた結果。example.com自身の署名ではない。
どちらの認証ドメインもexample.comと整合しないのでDMARCはfail。正規の外部配信サービスなら、整合するDKIM d=やMAIL FROMを使うよう設定を見直す。

9-5. ケースB：転送先でSPF fail、DKIM pass、DMARC pass

Authentication-Results: mx.final.example;
  spf=fail smtp.mailfrom=example.com;
  dkim=pass header.d=example.com;
  dmarc=pass header.from=example.com

転送サーバのIPがexample.comのSPFに含まれずspf=failでも、DKIM署名が維持され、d=とHeader Fromが整合すればDMARCはpassします。SPF failだけで『確実になりすまし』とは言えません。

9-6. ケースC：認証は全てpassだが詐欺の可能性

From: 経理部 <invoice@payments-example.com>
Authentication-Results: mx.recipient.example;
  spf=pass smtp.mailfrom=payments-example.com;
  dkim=pass header.d=payments-example.com;
  dmarc=pass header.from=payments-example.com

攻撃者が自分の紛らわしいドメインを正しく設定すれば、そのドメインについて全てpassし得ます。表示名が『経理部』でも本物のexample.comではありません。正規アカウントが侵害された場合も、正規ドメインの認証はpassし得ます。取引先の既知ドメイン、過去の会話、返信先、添付・URL、振込先変更の別経路確認まで調べます。

認証を通過する類似ドメイン詐欺の流れ

1. 類似ドメイン：証跡正規の取引先と異なるドメイン／防御・対処既知の取引先ドメインと照合
2. 認証がpass：証跡 SPF・DKIM・DMARCの結果／防御・対処認証したドメイン自体を確認
3. 振込先変更依頼：証跡件名・本文・返信先・URL／防御・対処既知の連絡先へ別経路で確認

認証がpassしたドメイン自体が正規の取引先とは限らない。証跡と確認手段を段階ごとに示す。

この図で認証がpassするのはpayments-example.comです。既知の取引先example.comからの正規の依頼かは、登録済みの連絡先や取引記録で確認します。

9-7. ケースD：DNS障害と設定誤り

spf=temperrorはDNSの一時障害など。spf=permerrorはSPFレコードの構文や10件制限などを疑う。failと同じく『攻撃確定』と短絡しない。
DKIMの署名・本文ハッシュが一致しない場合と、公開鍵の不存在、DNSの一時障害は別の原因。dkim=failだけに決めつけず、permerror・temperrorなど実装が記録した結果と理由、署名のd=・s=、該当DNS TXTを照合する。
dmarc=noneは方針未公開などを意味する場合がある。Authentication-Resultsの実装ごとの注記を読み、単なる『全検査に成功』とは解釈しない。

9-8. 攻撃と障害が成立する条件を分ける

第三者によるHeader From詐称：攻撃者に、自分のSMTPサーバなどから任意のFromを付けて送る能力が必要。example.comのSPF許可IPやDKIM秘密鍵を持たなければ、example.comと整合する認証を通常は通せない。受信側がDMARCを検証し、その結果を配送判断に使う位置で対策が効く。ただし、受信側の例外処理や正規転送による失敗は別に調べる。
類似ドメイン詐欺：攻撃者がpayments-example.comなど別のドメインを管理し、そのドメインのSPF・DKIM・DMARCを正しく設定できれば、三つともpassし得る。受信側の認証はそのドメインを評価するだけなので、取引先の既知ドメインとの照合と振込先変更の別経路確認が必要。
正規アカウントの侵害：攻撃者が投稿用の認証情報や有効なセッションを得て、正規MSAから送れれば、送信ドメイン認証がpassしても不正な依頼を届けられる。MFAや異常ログイン検知は投稿・アカウントの層で働くが、盗まれた既存セッションや既に送られたメールの被害は別途調べる。
委任先・鍵の悪用：委任したサブドメインのDNSや外部配信サービスのDKIM秘密鍵を攻撃者が制御できると、整合する認証結果が得られる場合がある。relaxed整合では組織ドメインが同じサブドメインも整合し得るため、委任範囲、配信権限、鍵の保管と失効を確認する。
転送・設定障害：転送先のSPF failやDKIM failだけでは攻撃者の存在を示さない。元のMAIL FROMを保った転送、本文の改変、DNSの一時障害、鍵の切替漏れなどでも起こる。前後のホップと変更履歴が原因判定に必要。

9-9. 正常・異常の証跡と、そこから言える範囲

次は同じ受信ゲートウェイがDATA受信後に認証を終えて記録した、説明用の正規化ログです。三つの行は別々のメールを表します。配送結果はそのゲートウェイでの処理であり、受信者の閲覧や送金を示しません。

text

id=normal peer=192.0.2.40 mail_from=bounce@example.com
  header_from=example.com spf=pass dkim=pass dmarc=pass
  action=delivered
id=spoof peer=203.0.113.66 mail_from=bounce@example.com
  header_from=example.com spf=fail dkim=none dmarc=fail
  action=quarantined
id=account peer=192.0.2.40 mail_from=bounce@example.com
  header_from=example.com spf=pass dkim=pass dmarc=pass
  action=delivered

normal：この受信点ではドメイン認証が成立し、メールボックスへの配送を記録した。ただし、本文が安全か、受信者が読んだか、依頼が正当かは分からない。
spoof：接続元IPは提示されたexample.comのSPFに合わず、整合するDKIM署名もないためDMARC failとなり隔離された。この一通がexample.comの正規アカウント侵害や情報流出を示すわけではない。実際のDNS方針、転送経路、隔離後の扱いを照合する。
account：認証結果と配送結果はnormalと同じ。これだけでは正常利用と乗っ取りを区別できない。投稿用MSAの認証ログ、送信者の端末・セッション、送信済みメール、転送ルール、取引先への依頼内容を追加で調べる。

SMTPの接続成功は認証成功ではなく、認証成功は本文の安全性やアカウントの正当利用を保証しません。配送成功、開封、URLへのアクセス、機密情報の流出、振込実行も別の事実です。各段階に対応するログや取引記録がない限り、次の段階まで起きたと断定しません。Authentication-Resultsは信頼できる受信境界で付いたものを使い、必要なら原本とMTAログを突き合わせます。

10. 侵害・なりすましが疑われる場合の調査順序

不審メールの調査と対処の順序

1. 原本保全：対応ヘッダを含む原本とログを保存／確認する証跡 .eml・受信MTAログ
2. 認証確認：対応信頼できる判定行を特定／確認する証跡 Authentication-Results
3. 経路照合：対応接続元IPと各ホップを並べる／確認する証跡 Received・SMTPログ
4. 原因判定：対応詐称・設定ミス・侵害を分ける／確認する証跡 DNS変更・ログイン履歴
5. 封じ込め：対応侵害範囲と被害を抑える／確認する証跡送信・転送・取引の履歴
6. 復旧確認：対応正規配送と再侵入防止を検証／確認する証跡試験配送・監視・権限確認

原本を保全して認証結果と配送経路を照合し、原因に応じた封じ込めと復旧確認まで進める。

原本を保全する。ヘッダを含む.eml、受信時刻・タイムゾーン、受信MTAのログ、検疫結果、メッセージIDを記録する。画面のスクリーンショットだけを証拠にしない。
表示名・Header From・Reply-To・Return-Path・DKIM d=・Authentication-Resultsのauthserv-idを分けて抜き出す。信頼できる受信境界が付けた認証結果か確認する。
SMTP接続元IP、HELO、MAIL FROM、各Received、転送・メーリングリスト経路を時系列で突き合わせる。DNSレコードは調査時点と配送時点の差、TTLや変更履歴にも注意する。
詐称された側か、正規アカウントが乗っ取られた側かを切り分ける。正規アカウントならログイン履歴、MFA、転送ルール、送信済みメール、APIトークンを調べる。
送信経路の設定ミスならSPF・DKIM整合を修正する。侵害なら資格情報の失効、悪性転送ルール削除、端末調査、取引先への連絡、被害拡大防止を優先する。

SPFやDMARCのレコード変更だけで、すでに侵害されたメールアカウントや支払先詐欺を解決したことにはなりません。対策は原因と攻撃経路に合わせて選びます。

10-1. 対処後に何を確認して再開するか

第三者による詐称なら、受信側で信頼できるAuthentication-Resultsを付け、DMARCの結果と受信側の処理が想定どおりかを試験メールとゲートウェイログで確かめる。既に配信・閲覧されたメールの宛先を洗い出し、必要な注意喚起や取引先確認を行う。
正規アカウントが侵害されたなら、影響した端末・認証セッション・APIトークン・アプリパスワード・代理送信権限・自動転送ルールを調査し、使われた資格情報を失効させる。再認証後に不審な送信やログインが止まり、正規利用者が送受信できることを確認して再開を判断する。
DKIM鍵や外部配信サービスが侵害されたなら、署名権限を止め、新しい鍵・セレクタへ切り替える。古い鍵を残したままでは不正署名が続き得る。公開鍵を削除してもDNSキャッシュが残る間は旧鍵を検証できる受信側があるため、失効操作だけで即時停止したと判断しない。影響期間の署名付きメールを追跡し、新鍵での正規配送と旧鍵を使った不正送信の停止を監視する。
設定変更が原因なら、正規の送信元を含むSPF、DKIM署名・整合、DMARC、転送・メーリングリストを複数の受信先で試す。キューに滞留したメールの再配送、バウンス、集計レポート、隔離件数を監視し、誤隔離が解消したことを確認する。
振込先変更など業務被害が疑われるなら、メール認証の復旧とは別に、既知の連絡先で取引先と依頼の真偽を確認する。取引や支払の再開は業務責任者とインシデント対応担当が影響範囲・残存リスクを共有して決める。

11. 自社ドメインを運用するときの実装チェック

正規の送信元を棚卸しする：人のメール、業務システム、監視通知、請求書配信、クラウドサービス、委託先、転送経路を漏らさない。
宛先を受けるMXと送信するMTAを別々に設計する。MXホストのA/AAAA、配送ポート、TLS、監視を確認する。送信用のIPが受信用MXと同じとは限らない。
各送信経路に合うMAIL FROMとSPFを設定する。外部サービスを使う場合は整合する独自のバウンスドメインか、整合するDKIM署名を検討する。
DKIM秘密鍵を安全に管理し、セレクタごとに公開鍵をDNSへ置く。署名ヘッダ、配信サービスのd=、鍵ローテーション手順を確認する。
DMARCは正規メールの認証結果と集計レポートを確認しながら方針を決める。転送・メーリングリスト利用、サブドメインの運用、受信側の例外処理を見落とさない。
サブドメインの委任や廃止済み配信サービスを点検する。残存するSPF include、DKIM鍵、DNS委任は攻撃面になる。

調査時のDNSコマンド例です。結果は実際の時点・問い合わせ先DNSによって変わります。『MX→MXホストのA/AAAA』と『SPF・DKIM・DMARCのTXT』を別々に確認します。

bash

dig MX example.com
dig A mx1.example.net
dig AAAA mx1.example.net
dig TXT example.com
dig TXT s2026._domainkey.example.com
dig TXT _dmarc.example.com

11-1. 変更・障害・廃止で崩れやすい条件

MXや受信サービスの切替：新旧MXのA/AAAA、25番の到達性、証明書・配送先、受信キューを事前に検証する。TTLだけを短くしても古い経路のメールが直ちに消えるわけではない。移行中は旧経路も監視し、配送遅延やバウンスを確認してから廃止する。
送信サービスの追加・切替：実際に接続するIP、MAIL FROM、DKIM d=、Header Fromを各経路で採取する。SPFの10件制限や外部サービス側のIP変更、整合しない署名を確認する。新経路が安定するまで旧経路を誤って削除しない。
DKIM鍵の定期更新：新セレクタの公開鍵を先に公開し、新鍵で署名したメールのpassを確認する。配送中の旧署名メールが届く期間を考慮して旧公開鍵を残し、利用状況を見て削除する。公開鍵の追加・削除後もDNSキャッシュと負のキャッシュを考慮して複数の受信点で確認する。秘密鍵漏えい時は旧鍵を速やかに無効化し、キャッシュに残る間の不正署名と遅延メールへの影響を監視する。
DMARC方針の強化：p=noneで送信元と集計レポートを観測し、正規経路の整合を直してからquarantineやrejectを検討する。受信側の判断には例外があり、方針変更後も隔離・拒否・誤判定の件数を監視する。転送先とメーリングリストへの影響も確認する。
サービス廃止と障害時：使わなくなったSPF include、DKIM鍵、DNS委任、外部配信サービスの送信権限を棚卸しして取り消す。DNSのSERVFAILや鍵レコードの欠落では直ちに攻撃と決めず、権威DNSと受信側キャッシュ、変更履歴、正常配送への影響を比べる。

12. SC科目B（午後）での読み解き方：小さな演習

演習1：MXとSPFの混同を見抜く

条件：example.comのMXはmx1.example.net（192.0.2.25）。実際の送信MTAはout1.example.com（192.0.2.40）で、MAIL FROM:<bounce@example.com>、Header Fromはinvoice@example.com。example.comのSPFは『v=spf1 ip4:192.0.2.40 -all』。問い：この送信はMXホストとIPが違うからSPF failか。

考え方：SPFはSMTP接続元の192.0.2.40をexample.comのSPFで評価します。MXホスト192.0.2.25と同じである必要はなく、この例ではip4条件に合うのでSPFはpassです。次にHeader FromとのDMARC整合を別途調べます。

演習2：二つのpassとDMARC fail

条件：Header Fromはexample.com。MAIL FROMとDKIM d=はvendor.exampleで、両方pass。example.comに適用できる有効なDMARC方針も取得済み。問い：なぜDMARC failか。

考え方：SPFとDKIMが認証したのはvendor.exampleです。example.comとの整合が両経路で成立しないため、DMARCはfailです。『DKIMの公開鍵が引けた』『SPFに送信IPが載っていた』だけでは解けません。

演習3：転送後の判断

条件：最終受信点では元のMAIL FROMのSPFはfail。元のHeader Fromと同じドメインのDKIM署名はpassし、そのHeader Fromに適用できる有効なDMARC方針も取得済み。問い：DMARCはどうなるか。

考え方：整合するDKIMがpassしているのでDMARCはpassし得ます。本文改変でDKIMがfailに変われば、他に整合する認証結果がなければDMARCもfailです。各ホップの接続元IPと変更内容を確認します。

演習4：全てpassした振込先変更メール

条件：既知の取引先はexample.com。受信メールのFromは『経理部 <invoice@payments-example.com>』で、信頼できる受信MTAのSPF・DKIM・DMARCはいずれもpass。本文は新しい振込先への変更を求める。問い：原因として考えるべきこと、追加調査、直ちに取る対策を答える。

解答例（判断）：認証されたのはpayments-example.comであり、既知のexample.comではありません。類似ドメインを使った詐欺の可能性があります。このログだけでは攻撃者の身元や送金被害は確定しません。

追加調査と対策：原本・ヘッダと過去の取引先アドレスを照合し、同じ差出人からの配信範囲と振込処理の状態を調べます。支払を保留し、登録済みの電話番号などメール以外の既知経路で取引先へ確認します。

誤答の理由：『DMARCがpassなので依頼は正当』は不十分です。passは当該ドメインの認証結果であり、既知の取引先本人や依頼内容の正当性までは示しません。

演習5：鍵更新後のDKIM検証エラーと復旧判断

条件：example.comの新セレクタs2026へ切り替えた直後から、正規送信メールの一部で『dkim=permerror (no key for signature) header.d=example.com header.s=s2025』が記録された。s2025._domainkey.example.comの公開鍵は既に削除され、送信側のキューには旧鍵で署名された未配送メールが残る。問い：原因、追加調査、復旧と再開の条件を答える。

解答例（原因）：旧署名メールが届く前に旧公開鍵を削除し、鍵を取得できない受信側で検証エラーになった可能性が高いです。受信側の理由文、署名のd=・s=、権威DNSと再帰DNSの応答、送信時刻、各MTAのキュー、DNS変更履歴、SPF・DMARCの結果を突き合わせます。

復旧：旧秘密鍵の侵害がないと確認できれば旧公開鍵を一時復旧し、新鍵での署名を続けます。負のDNSキャッシュが残る受信側では再公開後も直ちに検証できない場合があるため、送信キューの再試行と複数受信点での結果を観測します。鍵漏えいが疑われる場合は旧鍵を再公開せず、キャッシュに残る旧公開鍵の影響も監視します。

再開条件：旧署名メールの配送完了、正規メールの認証・到達、誤隔離の解消を確認して旧鍵の廃止と運用再開を決めます。誤答の『SPFに送信IPを足せばDKIMの鍵取得エラーが直る』は、SPFがDKIM公開鍵の取得を補えないため不十分です。