DKIM2とDMARCbisが登場

DKIM2とDMARCbisが登場し、Stalwartがそれらを最初に扱います。 7月6日、2026年 - 27分間の読書 Mauro D. プロジェクトメンテナー メール認証は、インターネットのメールシステムを20年間にわたり静かに支えてきましたが、今、その歴史上最大の進歩を遂げました。2つの取り組みが同時に登場しました。 DKIM2（現在ドラフト-04）は、DKIMを改変し、署名が単なる内容に関する孤立した声明ではなく、送信者から最終受信者までメッセージを追跡する検証可能な連鎖の一部となるようにしました。これにより、転送による署名の破損がなくなり、再送されたメールは検証できなくなり、バウンスが正当性を証明できるようになります。DMARCbis（2026年5月にRFC 9989、RFC 9990、RFC 9991として公開）は、待望のDMARCの後継です。静的な公開サフィックスリストをライブのDNSツリーウォークに置き換え、機能しなかったタグを廃止し、10年間の苦労して得られた運用上の教訓を標準に組み込んでいます。 どちらも重要です。なぜなら、メール認証はフィッシャーがあなたの銀行のドメインをFrom:行に置くことを防ぐものであり、これまでそれを実行してきた仕組みは古くなっていたからです。この記事では、各プロトコルが何を変更し、なぜそれが重要なのかを説明します。これは発表でもあります。Stalwart v0.16.12の時点で、DKIM2とDMARCbisの両方が完全に実装されており、Stalwartがそれらをサポートする最初のメールサーバーです。興味のある方は、インストール不要で、mail-authプレイグラウンドでブラウザから直接DKIM2メッセージに署名したり検証したり、DMARCbisチェックを実行したりできます。詳細は後ほど。まずはプロトコルからです。 DKIM2について DKIM（DomainKeys Identified Mail、RFC 6376）は、 deceptively simple なことを1つ行います。それは、ドメインがメッセージに対する責任を負うことを可能にすることです。送信サーバーは、選択したヘッダーフィールドと本文のハッシュを計算し、秘密鍵で結果に署名し、その結果をDKIM-Signatureヘッダーとしてメッセージに添付します。対応する公開鍵は、selector._domainkey.domain のDNSに存在するため、受信者はそれを取得し、ハッシュを再計算して、2つのことを確認できます。メッセージが本当にそのドメインによって承認されたこと、そして署名でカバーされていた内容が変更されていないことです。それがその約束の全てです。有効な署名は「このドメインはこの内容を保証する」という意味です。メッセージの宛先、どこを経由してきたか、次にどこへ行くかについては何も語りません。 約20年間、それで十分であり、DKIMは静かにメール認証の支柱の1つとなりました。それ自体では、DKIMのパスは単なるドメインに関する真実の声明です。DMARCがそれを決定に変えます。DMARCは、人間が実際に目にするドメイン、From:ヘッダーにあるドメインに認証を結びつけます。これは、identifier alignment というルールを通じて行われます。DKIMの結果がDMARCにカウントされるのは、署名ドメイン（d=）がFrom:ドメインと一致する場合のみです。DKIMまたはSPFのいずれかでアライメントをパスすれば、メッセージはDMARCをクリアします。両方失敗した場合、ドメインの公開ポリシーに合致し、それは隔離または outright rejection を意味する可能性があります。これが、破損したDKIM署名が化粧品的な問題ではない理由です。ドメインがp=rejectを公開しているメッセージのDKIMが破損し、SPFもそれを救えない場合、そのメッセージは失われます。 これがDKIM2が存在する理由です。20年以上にわたる実際のルーティングにおいて、DKIM1署名は望まれるよりもはるかに頻繁に破損し、いくつかのケースでは、破損してほしくないときに破損したままになります。 DKIM1の問題点 以下の内容は、元の設計に対する非難ではありません。これらは、20年間の展開によって引き剥がされた継ぎ目であり、DKIM2が閉鎖しようとしているまさにそのリストです。 誰でも受信者になれる。DKIM1署名は、宛先ではなく、内容にバインドされています。合法的に署名されたメッセージをキャプチャすれば、それを変更せずに何百万もの他のアドレスに再送でき、すべてのコピーが検証されます。再送は元の署名者の良い評判に乗るため、悪用者にとって価値があるのです。 転送が署名を静かに、曖昧に破損させる。メーリングリストが件名にタグを付けたり、ゲートウェイがリンクを書き換えたり、転送アプリがフッターを追加したりすると、署名されたハッシュは一致しなくなり、署名は失敗します。さらに悪いことに、検証者は、無害な[リスト]プレフィックスと攻撃者による wholesale replacement を区別できません。どちらも同じように見えます：破損しています。 移動した経路の記録がなかった。DKIM1は、メッセージがたどった経路の信頼できる痕跡を残しません。ReceivedおよびReturn-Pathヘッダーは認証されておらず、偽造が容易であるため、推論できるような追跡記録はありません。ARCは、受信者が信頼するのに苦労するパッチでした。ARCは、各ホップが見たものを証明させることで、仲介者間の認証を維持しようとしましたが、DKIMの横に別個のオーバーレイとして存在し、実際にはほとんどの受信者はARCシールを自信を持って信頼できないと報告しています。 ヘッダー署名の一貫性がなかった。DKIM1では、署名者はどのヘッダーをカバーするかを選択でき、複数の正規化モードを提供しているため、攻撃者が署名されていないヘッダーを滑り込ませる隙間ができ、署名を不必要に脆くしています。 バウンスが信頼できず、傍観者を傷つけた。Return-Pathはメッセージを処理しなかったドメインを指定できるため、Delivery Status Notification（DSN）は偽造された無関係な第三者に届く可能性があります。これはbackscatterであり、その恐怖のために、プロバイダーが1時間後にメッセージをスパムと判断した後に送信するような遅延バウンスは、今日ではほとんど実用的ではありません。 フィードバックが場当たり的だった。仲介者と送信者は、メールのパフォーマンスに関する非公式なシグナルを交換しますが、そのフィードバックを要求またはルーティングするための標準がないため、一貫性がなく、しばしば役に立ちません。 DKIM2、要するに DKIM2は、機能したすべてのものを取り込み、機能しなかったものを変更します。暗号化は馴染み深いものです。メッセージをハッシュし、署名し、DKIM1が既に使っているのと同じ_domainkeyの場所に公開鍵をDNSに公開します。変更されたのは、署名が内容に関する孤立した声明ではなくなり、送信者から最終受信者までメッセージを追跡する検証可能な追跡記録の一部となることです。それを実現するために、DKIM2は古い単一ヘッダーを2つに分割し、それぞれが独自のジョブを持ちます。 Message-Instanceヘッダーは、ある時点でのメッセージを記述します。リビジョン番号、そのリビジョンでのヘッダーと本文の暗号化フィンガープリントのセット、そしてホップが何かを変更した場合、変更を元に戻す方法を説明するコンパクトな「レシピ」（後述する転送を生存可能にするメカニズム）を運びます。DKIM2-Signatureヘッダーは、メッセージが実際に通過したエンベロープを記録し、それを署名します。馴染みのあるDKIMの断片、署名ドメイン、セレクター、署名自体、タイムスタンプに加えて、そのホップのSMTP MAIL FROMとRCPT TO、署名が順序付けられた連鎖を形成するシーケンス番号、そして送信者または仲介者がファンアウトを禁止したり、正当なファンアウトをマークしたり、フィードバックを要求したりするために上げることができる小さなフラグのセットをキャプチャします。 エンベロープを署名の中に入れることが、連続するホップの一貫性をチェックできるようにします。誰が署名し、どの順序で署名したかを記録することが、署名の山を連鎖に変えます。 2つのカウンターがすべてを駆動します。1つはホップごとに1つの署数を数えます。もう1つはメッセージリビジョンを数え、ホップが実際に内容を変更した場合にのみインクリメントされます。何も触れない完全に透過的なフォワーダーは、DKIM2を意識する必要さえありません。 壊れた約束ごとのための1つのメカニズム DKIM2の優雅さは、いくつかのメカニズムが上記のリスト全体を一度に解消することです。再送は、エンベロープを署名に入れることで対応します。各DKIM2-Signatureは、送信されたMAIL FROM (mf=) と RCPT TO (rt=) を記録し、連続するホップは一致する必要があります。あるホップの送信ドメインは、前のホップの受信ドメインと一致する必要があります。異なる受信者に再送されたメッセージは、もはや有効な連鎖を形成しません。送信者はファンアウトを禁止するためにdonotexplodeを追加でき、メーリングリストは正当なファンアウトをexplodedでマークします。 転送の破損は、回答されます。