DKIM・SPF・DMARC によるメール認証の原理

なりすましが成立する根本：SMTP には送信者検証がない

メール認証を理解する出発点は、SMTP が設計上送信者を検証しないプロトコルだという事実です。送信側は接続後、MAIL FROM でエンベロープ送信者（Envelope From、別名 Return-Path）を、DATA の中の From: ヘッダでヘッダ送信者を、それぞれ自由に名乗れます。この二つは別の層にあり、一致する保証はありません。受信者がメールソフトで目にするのはヘッダ From: だけなので、攻撃者はここに boss@example.com と書くだけで上司を装えます。

SPF・DKIM・DMARC は、後付けでこの欠落を埋める三層です。重要なのはそれぞれが守る対象が違うことで、三つを組み合わせて初めてヘッダ From のなりすましを実用的に塞げます。

SPF：IP アドレスによる送信元認可

SPF（Sender Policy Framework）は「このドメインを名乗って送ってよい IP アドレスはどれか」を、ドメイン所有者が DNS の TXT レコードで宣言する仕組みです。

example.com.  TXT  "v=spf1 ip4:192.0.2.0/24 include:_spf.google.com -all"

受信側 MTA は、MAIL FROM のドメイン（＝エンベロープ送信者のドメイン）の SPF レコードを引き、接続元 IP がマッチするかを評価します。末尾の -all（hardfail）は「列挙以外はすべて拒否」、~all（softfail）は「疑わしいが受理してマーク」を意味します。include は他ドメインのレコードを取り込む参照で、a / mx などのメカニズムも使えます。

SPF の本質的な限界は二つあります。第一に、評価対象がエンベロープ送信者であって、受信者が見るヘッダ From ではないこと。攻撃者は自分が支配するドメインを MAIL FROM に置けば SPF を合格させたうえで、ヘッダ From を偽装できます。第二に、転送に弱いこと。メールが転送サーバーを経由すると接続元 IP が転送者のものに変わり、元ドメインの SPF からは外れて失敗します。SPF 単体ではなりすましを止めきれない理由がここにあります。

DKIM：暗号署名による完全性と発信元証明

DKIM（DomainKeys Identified Mail）は、SPF の IP 認可とは独立に、メールに暗号署名を付ける方式です。送信側は選んだヘッダ群と本文のハッシュを取り、ドメインの秘密鍵で署名し、DKIM-Signature ヘッダとして付加します。検証側は署名ヘッダ中の d=（署名ドメイン）と s=（セレクタ）から DNS を引いて公開鍵を取得し、署名を検証します。

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

mail2026._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=<公開鍵>"

ここで本質的なのは二つの要素です。bh= は本文のハッシュ（body hash）で、本文の改ざんを検知します。b= は h= で指定したヘッダ列＋署名ヘッダ自身に対する署名で、対象ヘッダの改ざんとなりすましを検知します。c= の正規化（canonicalization）は、転送中に起こりがちな空白や改行の揺れを relaxed で吸収し、署名が壊れにくくします。署名・検証の数学的な土台は 署名方式 を、ハッシュと完全性の考え方は MAC・HMAC を参照してください。

DKIM は SPF と違い接続元 IP に依存しないため、転送されても署名は壊れません（正規化が吸収できる範囲の改変であれば）。一方で、h= に含めなかったヘッダは保護されないこと、l=（本文署名長の制限）を使うと末尾追記を許してしまうこと、といった落とし穴があります。セレクタ（s=）は鍵のローテーションを支え、mail2026 のように世代を分けて新旧の公開鍵を並行公開できます。

なぜ SPF と DKIM だけでは不十分か：アライメントの不在

ここまでで SPF と DKIM はそれぞれ「合格」を出せますが、どちらも『合格に使ったドメイン』と『受信者が見るヘッダ From のドメイン』が一致しているかを問いません。

• SPF が合格しても、それは MAIL FROM のドメインについての合格に過ぎない。
• DKIM が合格しても、それは d= のドメインについての署名検証成功に過ぎない。

攻撃者は自分のドメイン attacker.example で SPF と DKIM を正しく整え、合格させたまま、ヘッダ From: に ceo@bank.example と書ける。受信側のフィルタは「認証は通っている」と判断してしまう。この認証は成功しているのに偽装が成立する穴を塞ぐのが、次の DMARC のアライメントです。

DMARC：アライメント判定とポリシー

DMARC（Domain-based Message Authentication, Reporting and Conformance）は新しい認証技術を足すのではなく、SPF と DKIM の結果を『ヘッダ From のドメイン』に紐づけ直す統合層です。判定の中核は**アライメント（identifier alignment）**です。

DMARC の合格条件は 「SPF か DKIM の少なくとも一方が、合格しつつヘッダ From とアラインしている」 ことです。アライメントには二モードあります。strict はドメインの完全一致を要求し、relaxed（既定）は**組織ドメイン（Organizational Domain）**が一致すれば許容します。たとえばヘッダ From が news.example.com、DKIM の d= が example.com なら、relaxed では同じ組織ドメイン example.com に属するためアライン合格、strict では不一致で失敗です。

ポリシーはヘッダ From のドメインの DNS に公開します。

_dmarc.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:agg@example.com;
  ruf=mailto:fail@example.com; pct=100; adkim=s; aspf=r; sp=quarantine"

p= が DMARC 失敗時の指示で、none（観測のみ）・quarantine（迷惑メール隔離）・reject（受信拒否）の三段階です。pct= は適用率で、段階導入のため p=quarantine; pct=10 のように一部だけ強制する運用ができます。adkim / aspf で各認証のアライメント厳格度を個別指定します。

レポート：rua（集約）と ruf（失敗）

DMARC が「Reporting」を名に含むとおり、運用の鍵はレポートにあります。rua 宛には受信側 ISP が**集約レポート（aggregate report）**を通常 1 日 1 回、XML（gzip 圧縮）で送ります。これは個々のメール本文ではなく、「送信元 IP ごとに何通届き、SPF/DKIM/DMARC がどう判定され、どのポリシーが適用されたか」の統計です。これにより所有者は、自分のドメインを名乗るすべての送信元（正規の SaaS も、なりすましも）を俯瞰でき、未整備の正規送信元を発見してから締められます。

ruf 宛の**失敗レポート（forensic report）**は、認証に失敗した個別メッセージの詳細（ヘッダなど）を送る仕組みですが、プライバシー上の懸念から送出する受信側は少なく、現実には集約レポート中心で運用します。

サブドメインのポリシー委任と組織ドメインの決定

DMARC は階層を扱うために二つの仕組みを持ちます。第一に sp=（subdomain policy）で、サブドメインに親と別のポリシーを与えられます。p=reject; sp=none とすれば、本体は厳格に守りつつ、検証中のサブドメインは緩める、といった委任ができます。sp= を省略すると p= がサブドメインにも継承されます。

第二に、relaxed アライメントと sp= の継承を正しく行うには、ホスト名から組織ドメインを切り出す必要があります。news.mail.example.co.jp の組織ドメインが example.co.jp だと判定するには、co.jp のような**公開サフィックス（Public Suffix List）**の知識が要ります。単純に「右から二要素」では example.co.jp を co.jp と誤判定するため、PSL に基づく「公開サフィックス＋その左 1 ラベル」が組織ドメインの定義です。この境界判定を誤ると、アライメントもポリシー継承も破綻します。

BIMI：DMARC 強制を前提にしたロゴ表示

BIMI（Brand Indicators for Message Identification）は認証そのものではなく、DMARC を実施しているドメインに対し、受信トレイにブランドロゴを表示する上位の仕組みです。前提が厳しく、ドメインが p=quarantine か p=reject（かつ pct=100）で DMARC を強制していることが条件です。なりすませないドメインにだけロゴという「正規である視覚的証明」を与える、という設計思想です。

ロゴは DNS の BIMI レコードが指す SVG（Tiny PS プロファイル）で公開し、主要メールプロバイダではさらに **VMC（Verified Mark Certificate）**という、ロゴの商標所有を証明する X.509 証明書の提示を求めます。つまり BIMI は「DMARC で送信者ドメインの真正性を担保した上に、ロゴの権利まで証明書で裏付ける」二重構造で、ブランド偽装フィッシングへの抑止を狙います。

まとめ

メールのなりすましは、SMTP がエンベロープ送信者もヘッダ From も検証しないことに根があります。SPF は IP による送信元認可（照合対象はエンベロープ）、DKIM は暗号署名による完全性と発信元証明（IP 非依存で転送に強い）を与えますが、どちらも単体では「合格に使ったドメイン」とヘッダ From の不一致を許します。

この穴を DMARC がアライメントで塞ぎ、失敗時の処理を none/quarantine/reject のポリシーで指定し、rua/ruf のレポートで運用を可視化し、sp= と組織ドメイン判定でサブドメインまで統制します。最後に BIMI が、DMARC 強制を達成したドメインにロゴ表示と VMC による権利証明を与えます。三層を「何を守り、何を守らないか」で整理することが、到達率と対なりすましの両立に直結します。署名と検証の基礎は 署名方式、証明書チェーンは X.509 証明書チェーン検証 と合わせて押さえると、メール周辺の信頼の全体像がつながります。