メールのしくみ 6：DKIM ― メールに押す電子署名

DKIM：メールそのものに、送り主の印を押す

5本目の SPF は、「どこから来たか」（送信元の番号）を確かめる仕組みでした。そのため、転送されて経路が変わると壊れてしまいます。

この作品で見る DKIM（DomainKeys Identified Mail）は、考え方がまったく違います。経路ではなく、メールそのものに印を押す方式です。

昔の手紙で、封筒に封蝋を押して「確かに私が出した」と示したのに近いものです。印はメールと一緒に運ばれるので、どんな経路を通っても、受け取った人はその印を確かめられます。

ただし、封蝋と違って、DKIM の印は真似できません。その仕組みの土台が、次のページで見る「2つ1組の鍵」です。

鍵を2つ1組で作る：秘密鍵と公開鍵

DKIM の印（電子署名）は、公開鍵暗号という仕組みで作ります。難しそうな名前ですが、使い方は次の3つの性質だけ押さえれば十分です。

性質	意味
鍵は2つ1組で作る	秘密鍵と公開鍵のペア
秘密鍵で作った印は、対の公開鍵でしか確かめられない	別の鍵で作った印は「正しくない」と判定される
公開鍵から秘密鍵は作れない	だから公開鍵は誰に見せてもよい

使い方はこうなります。送る側は秘密鍵を自分だけで大切に持ち、それで印を作ります。公開鍵は世界中に公開します。受け取った人は、公開鍵で印を確かめます。

印が正しいと判定されれば、「この印を作ったのは、対の秘密鍵を持っている人だ」と分かります。秘密鍵を持っているのは本人だけなので、本人が作った印だと言えるわけです。

署名の作り方：まず要約を作り、それに印を押す

実際の署名は、メール全体に直接印を押すのではなく、2段階で作ります。

最初に、メールの本文と主要なヘッダーから、要約（ハッシュ）を作ります。ハッシュは、どんなに長いデータからでも、決まった長さの短い値を作る計算です。

ハッシュには、DKIM にとって都合のいい性質が2つあります。

性質	DKIM にとっての意味
元のデータが1文字でも違えば、まったく別の値になる	書き換えがあれば必ず分かる
ハッシュから元のデータを作り直すことはできない	要約を見ても中身は分からない

次に、この要約に秘密鍵で印を押します。これが署名です。

要約に印を押すのは、長いメール全体に直接印を押すより計算が軽いからです。それでいて、ハッシュの性質のおかげで、メールのどこか1文字でも変われば署名が合わなくなります。

署名は DKIM-Signature というヘッダーに入れて送る

作った署名は、メールのヘッダーに `DKIM-Signature` という欄を追加して、メールと一緒に送ります。

DKIM-Signature: v=1; a=rsa-sha256;
  d=mail.animemo.app; s=resend;
  h=from:to:subject:date:message-id;
  bh=（本文の要約）; b=（署名そのもの）

主な項目の意味は次のとおりです。

項目	意味
`d=`	署名したドメイン。「このドメインとして署名しました」
`s=`	セレクタ。どの鍵で署名したかの名札
`h=`	署名に含めたヘッダーの一覧。`From` は必ず含める決まり
`a=`	計算の方式
`bh=`	本文の要約
`b=`	署名そのもの

受け取る側にとって大事なのは d= と s= です。この2つから、「公開鍵をどこに取りに行けばいいか」が分かります（次のページ）。

h= に From が必ず入るのもポイントです。署名の後で From: を書き換えると、署名が合わなくなります。

公開鍵は DNS の決まった名前に置く

受け取る側は、DKIM-Signature の s= と d= を使って、公開鍵が置いてある場所の名前を組み立てます。

（s= の値）._domainkey.（d= の値）
→ resend._domainkey.mail.animemo.app

真ん中の _domainkey は、「ここは DKIM の公開鍵の欄です」という決まった目印です。2本目で見たとおり、_ で始まる名前は機械の名前とぶつからないので、宣言専用の欄として使えます。

その名前の TXT を DNS で引くと、公開鍵が書かれています。

resend._domainkey.mail.animemo.app  TXT  "p=MIGfMA0GCSqGSIb3DQEB…"

ここで、2本目の「DNS は持ち主しか書けない」が効いてきます。この場所に公開鍵を置けるのは mail.animemo.app の持ち主だけです。つまり、ここにある公開鍵は、持ち主が「この鍵で署名されたメールは、うちのメールです」と認めた鍵です。

送る側（Resend）が、送るたびに署名を付ける

ここから、5本目と同じ舞台に戻って、実際の流れを追います。

送る側の Resend は、mail.animemo.app 用の秘密鍵を保管しています。Animemo からメールを頼まれるたびに、次のことをします。

1通ずつ、本文と主要なヘッダーから要約を作ります。その要約に秘密鍵で署名します。DKIM-Signature のヘッダーに d=mail.animemo.app; s=resend と署名を書いて、メールに追加します。そして送ります。

図の封筒に「署名: d=mail.animemo.app」の行が増えたのがこれです。この時点で、受け取る側の検査欄では、SPF はすでに合格しています（5本目）。DKIM はまだ確かめていません。

受け取る側は、DNS の公開鍵で署名を確かめる

受け取った Gmail は、次の順で DKIM を確かめます。

順番	やること
1	`DKIM-Signature` から `d=mail.animemo.app` と `s=resend` を読む
2	`resend._domainkey.mail.animemo.app` の TXT から公開鍵を取ってくる
3	届いたメールから、自分で要約を作り直す
4	公開鍵を使って、署名が「その要約に対して、対の秘密鍵で押されたものか」を確かめる

すべて合えば、DKIM は合格（pass）です。

作り直した要約が送る側の要約と一致するのは、途中でメールが1文字も変わっていないときだけです。そして署名を確かめられるのは、対の秘密鍵で押されたときだけです。この2つが同時に成り立ったことになります。

署名が合えば、2つのことが同時に分かる

DKIM が合格したとき、受け取る側が分かることを整理します。

1つ目：`mail.animemo.app` の持ち主が認めた送り手が送った。 公開鍵を DNS に置けるのは持ち主だけで、対の秘密鍵を持っているのは Resend だけです。だから、この署名を作れたのは「持ち主が鍵を預けた相手」だけです。

2つ目：途中で書き換えられていない。 1文字でも変われば要約が変わり、署名と合わなくなります。

一方で、分からないこともあります。画面に出る `From:` のドメインが、署名したドメイン（`d=`）と同じかどうかです。DKIM は「d= に書いたドメインとして、正しく署名されている」と言っているだけです。この点は後の「DKIM の穴」で見ます。

書き換えられたメールは、署名が合わない

途中で誰かがメールを書き換えたとします。たとえば、本文のリンクを偽のサイトへ差し替えた場合です。

受け取る側が要約を作り直すと、送る側が署名したときの要約とは別の値になります。署名は合わず、DKIM は不合格（fail）になります。SPF は経路の話なので合格したままでも、DKIM が改ざんを見つけてくれます。

ただし、書き換えが善意でも壊れる点には注意が必要です。メーリングリストのように、転送するときに件名に [お知らせ] を足したり、本文の末尾に案内文を足したりする仕組みを通ると、DKIM は合わなくなります。

「DKIM が fail ＝必ず偽物」とは限らないのはこのためです。受け取る側は、DKIM だけで決めずに、ほかの結果（7本目の DMARC や、8本目の評判）と合わせて判断しています。

署名はメールと一緒に運ばれるので、転送に強い

では、単純な転送ではどうでしょうか。5本目で、大学のメールから Gmail へ自動転送されると SPF が落ちる、という例を見ました。

普通の自動転送は、メールの中身を書き換えずにそのまま次へ渡します。DKIM の署名はメールそのものに付いているので、経路が変わっても署名はそのまま残ります。受け取った Gmail が確かめれば、DKIM は合格します。

図の検査欄では、SPF は不合格、DKIM は合格になっています。これで、SPF の穴②（転送に弱い）は DKIM が補えるようになりました。

DKIM の穴：署名のドメインと From が別でも合格する

ここまでで、DKIM はかなり頼もしく見えます。ところが、DKIM にも穴があります。

DKIM の署名に書かれるドメイン（d=）は、手紙の From: のドメインと同じである必要がありません。

図のなりすましは、自分のドメイン evil.example 用に鍵を作り、公開鍵を自分の掲示板に置き、本物の署名を付けています。自分のドメインなので、正しい手順で作れてしまいます。DKIM は合格します。SPF も、5本目で見たとおり合格します。

それでいて、手紙の From: には 〇〇銀行 <[email protected]> と書いてあります。

SPF も DKIM も、「何かのドメインの身元」は確かめてくれます。でも、それが画面に出ている差出人と同じドメインかどうかは、どちらも見ていません。これが最後に残った穴で、7本目の DMARC がこれを塞ぎます。

セレクタがあるから、鍵を複数持てる・入れ替えられる

最後に、セレクタ（s=）がなぜあるのかを見ておきます。

1つ目の理由は、1つのドメインで複数のサービスから送るためです。mail.animemo.app から Resend でも Google Workspace でも送る場合、それぞれのサービスが自分の秘密鍵で署名します。鍵が別なので、公開鍵も別々に置く必要があります。セレクタで名前を分ければ、resend._domainkey と google._domainkey のように並べて置けます。

2つ目の理由は、鍵の入れ替えです。同じ鍵を何年も使い続けると、漏れたときの被害が大きくなります。そこで定期的に新しい鍵に替えます。このとき、新しいセレクタで公開鍵を先に追加し、署名を新しい鍵に切り替えてから、古いセレクタの公開鍵を消します。こうすれば、切り替えの途中でも、どちらの鍵で署名されたメールも確かめられます。

受け取る側は、署名の s= を見るだけで、どの鍵で確かめればよいかが分かります。

Resend では、秘密鍵を見ることすらない

ここまで読むと、「秘密鍵の管理が大変そう」と感じるかもしれません。Resend を使う場合、その心配はほとんどありません。

Resend にドメインを登録すると、Resend が鍵のペアを作り、秘密鍵は Resend の中に保管されます。こちらの画面には公開鍵だけが表示され、「この値を resend._domainkey.mail という名前の TXT に入れてください」と案内されます（10本目）。

こちらがやるのは、その公開鍵を DNS に写すことだけです。一度入れれば、あとは送るたびに Resend が自動で署名を付けます。

秘密鍵が自分の手元に無いということは、自分のサーバーから秘密鍵が漏れる心配もないということです。DKIM の仕組みのうち、いちばん繊細な部分を丸ごと任せられるのは、送信サービスを借りる大きな利点の1つです（9本目）。

まとめ：DKIM

この作品で見たことをまとめます。

項目	内容
何をするか	メールそのものに電子署名を付ける
仕組み	秘密鍵で要約に印を押し、DNS の公開鍵で確かめる
公開鍵の場所	`セレクタ._domainkey.署名したドメイン` の TXT
分かること	持ち主が認めた送り手が送った。途中で書き換えられていない
強み	経路が変わっても残る（SPF の穴②を補う）
弱み	メーリングリストなどの書き換えで壊れる
穴	署名のドメイン（`d=`）と画面の `From:` が別でも合格する
Resend では	秘密鍵は Resend が持つ。こちらは公開鍵を DNS に写すだけ

SPF と DKIM は、どちらも「何かのドメインの身元」を確かめます。残った穴は、「それが画面の差出人と同じか」です。次の作品で、その穴を塞ぐ DMARC を見ていきます。