ドメインキー識別メール

DomainKeys Identified Mail ( DKIM ) は、フィッシングや電子メール スパムでよく使用される手法である、電子メール内の偽造された送信者アドレス (電子メール スプーフィング)を検出するために設計された電子メール認証方法です。

DKIMを使用すると、受信者は、特定のドメインから送信されたと主張するメールが実際にそのドメインの所有者によって承認されたものであることを確認できます。^{[1]これは、ドメイン名にリンクされた}デジタル署名を各送信メールメッセージに添付することで実現します。受信者システムは、 DNSで公開されている送信者の公開鍵を検索することでこれを検証できます。有効な署名は、メールの一部（添付ファイルを含む可能性があります）が署名の添付以降に変更されていないことも保証します。^[2]通常、DKIM署名はエンドユーザーには表示されず、メッセージの作成者や受信者ではなくインフラストラクチャによって添付または検証されます。

DKIMはインターネット標準です。^[3] 2011年9月のRFC 6376で定義され、RFC 8301とRFC 8463で更新されています。

電子メールの検証済み識別が必要になるのは、偽造アドレスや偽造コンテンツが簡単に作成でき、スパム、フィッシング、その他の電子メール詐欺に広く使用されているためです。^[4]たとえば、詐欺師はsender@example.comからのメッセージを送信し、受信者にメールを受け取って読んでもらうことを目的としていますが、受信者がこのメッセージを信頼するかどうかを判断するのは困難です。システム管理者は、自分のシステムから送信されたように見えるが実際にはそうではない悪意のあるメールに関する苦情にも対処する必要があります。^[5]

DKIM はメッセージに署名する機能を提供し、署名者 (作成者組織) がどの電子メールが正当であるかを伝えることを可能にします。不正行為を直接防止したり、開示したりするものではありません。

DKIM は、署名されたメッセージを検証するプロセスも提供します。検証モジュールは通常、受信側組織に代わって、場合によっては各ホップで動作します。

これらはすべて、RFC 5321 で定義されている SMTP「エンベロープ」ではなく、RFC 5322 メッセージ (転送されたメールのヘッダーと本文) に対して動作するという点で、 Simple Mail Transfer Protocol (SMTP) ルーティングの側面とは独立しています。したがって、DKIM 署名は、複数のメッセージ転送エージェント間での基本的なリレーを生き残ります。

署名組織は、作成者、メール送信エージェント、サイト、または転送パス上のその他の仲介者などのメッセージの直接ハンドラーである場合もあれば、直接ハンドラーに支援を提供している独立したサービスなどの間接ハンドラーである場合もあります。

署名モジュールは、作成者DKIM-Signature:組織または元のサービスプロバイダーに代わって、1つ以上のヘッダーフィールドを挿入します。仕様では、署名者が署名するヘッダーフィールドを選択できますが、フィールドは常に署名されている必要があります。^{[6] [7]}結果として得られるヘッダーフィールドは、次の例のようにパーツのリストから構成されます。 From:tag=value

DKIM 署名:  v=1;  a=rsa-sha256;  d= example.net ;  s=brisbane;
      c=relaxed/simple;  q=dns/txt; i=foo@eng.example.net ;
 t=1117574938; x=1118006938; l=200;
 h=from:to:subject:date:keywords:keywords;
 z=From: foo@eng.example.net |To: joe@example.com |
 Subject:demo=20run|Date:July=205,=202005=203:44:08=20PM=20-0700;
 bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;
 b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
 VoG4ZHRNiYzR
                                                 

使用されるタグは次のとおりです。

最も関連性の高いものは、メール メッセージの内容 (ヘッダーと本文) の実際のデジタル署名の場合はb 、本文ハッシュの場合はbh (オプションで本文の最初のlオクテットに制限)、署名ドメインの場合はd、セレクターの場合は s です。

オプションでエージェントまたはユーザー識別子 (AUID) を含めることができます。形式は、オプションのローカル部分を含む電子メール アドレスです。ドメインは、署名ドメインと同じか、そのサブドメインである必要があります。AUID のセマンティクスは意図的に未定義のままにされており、署名ドメインによって、よりきめ細かい責任範囲を確立するために使用される場合があります。

ヘッダーと本文の両方が署名に寄与します。まず、メッセージ本文がハッシュ化されます。常に先頭からハッシュ化され、指定された長さl (ゼロの場合もあります) に切り詰められる可能性があります。次に、選択されたヘッダー フィールドが、hで指定された順序でハッシュ化されます。繰り返されるフィールド名は、ヘッダーの下部から上に向かって一致しますReceived:。これは、ヘッダーにフィールドが挿入される順序です。存在しないフィールドは空の文字列と一致するため、その名前のフィールドを追加すると署名が壊れます。DKIM-Signature:作成中の署名のフィールド(計算された本文ハッシュに等しいbhと空の文字列に等しい)は、2 番目のハッシュに暗黙的に追加されますが、その名前がhに出現してはなりません。出現すると、別の既存の署名を参照します。両方のハッシュで、テキストは関連するcアルゴリズムに従って正規化されます。署名者の秘密鍵で暗号化し、Base64 を使用してエンコードした後の結果はbです。

hにリストされているヘッダー フィールドのリストに加えて、署名時に存在するヘッダー フィールドのリスト (フィールド名と値の両方を含む) がzで提供される場合があります。このリストは、 hのヘッダーのリストと一致する必要はありません。

アルゴリズム、フィールド、本文の長さは、送信中に発生する避けられない変更に対して署名が存続できるようにしながら、明確なメッセージ識別を保証するように選択されることを意図しています。エンドツーエンドのデータ整合性は暗示されていません。^[2]

検証したい受信SMTPサーバーは、ドメイン名とセレクターを使用してDNSルックアップを実行します。^[8]たとえば、上記の署名の例では、dタグは検証する著者ドメインexample.netを提供し 、sタグはセレクターbrisbane を提供します。文字列_domainkeyは仕様の固定部分です。これにより、次のように検索される TXTリソースレコードが提供されます。

brisbane._domainkey.example.net

国際化された電子メールでは、セレクタとドメイン名は UTF-8 にできることに注意してください。^{[9]その場合、ラベルは検索前に}IDNAに従ってエンコードする必要があります。このレコードのクエリから返されるデータも、タグと値のペアのリストです。これには、ドメインの公開鍵と、その他の鍵使用トークンおよびフラグ (たとえば、コマンドラインから: nslookup -q=TXT brisbane._domainkey.example.net) が含まれます。次の例をご覧ください。

"k=rsa; t=s; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDDmzRmJRQxLEuyYiyMg4suA2Sy
MwR5MGHpP9diNT1hRiwUd/mZp1ro7kIDTKS8ttkI6z6eTRW9e9dDOxzSxNuXmume60Cjbu08gOyhPG3
GfWdg7QkdN6kR4V75MFlw624VY35DaXBvnlTJTgRg/EW72O1DiYVThkyCgpSYS8nmEQIDAQAB"

利用可能なタグは次のとおりです: ^[3]

CNAME レコードは、たとえばある組織が別の組織に代わって電子メールを送信する場合など、別の TXT レコードを指すためにも使用できます。

受信者は公開キー ( pタグの値) を使用して、ヘッダー フィールドのハッシュ値の署名を検証し、受信したメール メッセージ (ヘッダーと本文) のハッシュ値と照合することができます。 2 つの値が一致する場合、メールが指定されたドメインによって署名され、送信中に改ざんされていないことが暗号的に証明されます。

署名検証の失敗によってメッセージが拒否されることはありません。その代わりに、メッセージの信頼性を証明できなかった正確な理由を下流プロセスと上流プロセスに提供する必要があります。これを行う方法には、FBL メッセージを返送するか、Authentication-Results:RFC 7001 で説明されているようにメッセージにヘッダー フィールドを追加することが含まれます。

DomainKeysは、現在期限切れとなっている米国特許6,986,049号で保護されています。Yahoo!は、その特許権を、DomainKeys Patent License Agreement v1.2、^[10]またはGNU General Public License v2.0（他のバージョンなし）の2つのライセンス方式でライセンスしました。^{[11] [12]}

本質的に、DKIM とSPF はどちらも電子メールの信頼性を異なる方法で測定します。DMARCは、組織がそのドメインから電子メールを送信するときにどのメカニズム (DKIM、SPF、またはその両方) を使用するか、From:エンドユーザーに表示されるフィールドをどのようにチェックするか、受信者が失敗に対処する方法、およびそれらのポリシーに基づいて実行されたアクションの報告メカニズムを指定するポリシーを公開する機能を提供します。^[13]

このシステムの電子メール受信者にとっての主な利点は、署名ドメインが正当な電子メールのストリームを確実に識別できるようにすることで、ドメインベースのブラックリストとホワイトリストをより効果的にすることができることです。^{[14]これにより、特定の種類の}フィッシング攻撃の検出が容易になる可能性があります。

メール送信者が送信メールに署名することには、いくつかのメリットがあります。

• 電子メールの受信者が DKIM システムを使用して、そのドメインからのものであると主張する偽造電子メール メッセージを識別すると、DKIM 対応ドメインの不正使用の事務作業が大幅に削減されます。
• ドメイン所有者は、実際にそのドメインを不適切に使用している自社のユーザーに対して不正使用対策チームのエネルギーを集中させることができます。

DKIM はメッセージにラベルを付ける方法であり、それ自体がスパムをフィルタリングしたり識別したりするものではありません。しかし、DKIM が広く使用されることで、スパム送信者がメッセージの送信元アドレスを偽造するのを防ぐことができます。これは現在よく使われる手法です。スパム送信者が正しい送信元ドメインを表示せざるを得ない場合、他のフィルタリング手法がより効果的に機能します。特に、送信元ドメインをレピュテーション システムに入力することで、スパムをより適切に識別できます。逆に、DKIM を使用すると、スパムではないことがわかっていてフィルタリングする必要のないメールを簡単に識別できます。受信システムが、ローカルで管理されているか、サードパーティの認証機関から提供されている、既知の送信元ドメインのホワイトリストを持っている場合、それらのドメインからの署名付きメールのフィルタリングをスキップし、残りのメールをより積極的にフィルタリングできます。^[14]

DKIM はフィッシング対策技術として役立ちます。フィッシング被害の多いドメインのメール送信者は、メールが本物であることを示すために署名することができます。受信者は、これらのドメインからのメールに有効な署名がない場合、そのメールは偽造されている可能性が高いと見なすことができます。このレベルの精査に値するドメインのセットを決定する最善の方法は、まだ未解決の問題です。DKIM には、すべてのメールに署名する作成者が自己識別できるADSPと呼ばれるオプション機能がありましたが、2013 年 11 月に歴史的地位に降格されました。^[15]代わりに、DMARC を同じ目的で使用できます^[16]。これにより、ドメインはどの技術 ( SPFや DKIM を含む) を採用しているかを自己公開できるため、受信者は特定のメールがスパムであるかどうかについて、情報に基づいた判断を下しやすくなります。^[17]例えば、eBayとPayPalはDMARCを使用して、すべてのメールが認証されているというポリシーを公開し、Gmailなどの受信システムでは認証されていないメールを拒否するように要求しています。^[18]

DKIMはDNSレコードと追加されたRFC 5322ヘッダーフィールドを使用して実装されているため、既存の電子メールインフラストラクチャと互換性があります。特に、DKIMをサポートしていない既存の電子メールシステムに対して透過的です。^[19]

この設計アプローチは、 S/MIMEやOpenPGPコンテンツ保護標準などの他の関連サービスとも互換性があります。DKIM は、 DNSSEC標準およびSPFと互換性があります。

DKIM では、メールサーバー経由で送信される各メッセージに対して暗号チェックサムを生成する必要があるため、電子メールの配信には通常必要のない計算オーバーヘッドが発生します。この追加の計算オーバーヘッドはデジタル消印の特徴であり、大量のスパムを送信すると (計算上) コストが高くなります。 ^{[20] DKIM のこの側面は}ハッシュキャッシュ に似ているように見えるかもしれませんが、受信側の検証はごくわずかな作業量であるのに対し、一般的なハッシュキャッシュアルゴリズムでははるかに多くの作業が必要になります。^[要出典]

DKIMの否認防止機能は、送信者（スパマーなど）がメールの送信を否定するのを防ぎます。これは、DKIM本文署名を利用して漏洩したメールが本物であり、改ざんされていないことを証明することができたWikiLeaksなどのニュースメディアにとって有用であることが証明されています。 ^[21]

多くの人は、否認防止は、今説明したような動作によって強制される、DKIM の望ましくない機能であると考えています。実際、DKIM プロトコルは有効期限を設けています。各署名にはオプションのxタグがあり、正式な有効期限が設定されますが、検証者はこれを無視できます。さらに、ドメイン所有者は、レコードから暗号化データを削除して公開鍵を取り消すことができます。これにより、誰かが事前に公開鍵データを保存していない限り、署名の検証ができなくなります。DKIM の鍵ローテーションは、侵害された鍵の影響を最小限に抑えるためだけに推奨されることがよくあります。ただし、否認防止を完全に無効にするために、期限切れの秘密鍵を公開すると、誰もが偽の署名を作成できるようになり、元の署名の重要性が無効になります。^{[22] [23] [24]}

RFC自体はいくつかの潜在的な攻撃ベクトルを特定している。^[25]

DKIM 署名には、リターンパスとメッセージの受信者を保持するメッセージ エンベロープは含まれません。DKIM はアドレスの誤指定に対する保護を試みないため、これがその有用性に影響を与えることはありません。

2013年の標準化の際には、多くの懸念が提起され、反論された。^[26]

あらゆる暗号化ソリューションの懸念事項は、メッセージのリプレイの 悪用です。これは、現在、大規模なドメインからの悪用レベルを制限している技術をバイパスします。 ^{[説明が必要]}リプレイは、メッセージごとの公開キーを使用し、それらのキーの DNS クエリを追跡し、大規模なメーリング リストに送信された電子メールや悪意のある人物による悪意のあるクエリによる多数のクエリをフィルター処理することで推測できます。

この問題に対処するさまざまな方法の比較については、「電子メール認証」を参照してください。

上で述べたように、認証は不正使用防止と同じではありません。評判の良いドメインの悪意のあるメール ユーザーは、不正なメッセージを作成し、DKIM 署名を付けて、そのドメインから任意のメールボックスに送信し、そこからファイルとして取得して、署名されたメッセージのコピーを取得できます。署名にlタグを使用すると、このようなメッセージの改ざんがさらに容易になります。その後、署名されたコピーは、たとえばボットネットを介して、制御なしに 100 万人の受信者に転送できます。メッセージに署名したメール プロバイダーは、違反ユーザーをブロックできますが、すでに署名されたメッセージの拡散を止めることはできません。このようなメッセージの署名の有効性は、署名に常に有効期限タグを含めるか、公開キーを定期的にまたはインシデントの通知時に失効させることによって制限できます。送信メールをフィルタリングすることでシナリオの有効性を制限することはほとんどできません。これは、メッセージがスパマーにとって潜在的に有用である可能性があるかどうかを検出できることを意味します。^[27]

DKIM には現在、シンプルとリラックスの2 つの正規化アルゴリズムがありますが、どちらもMIMEに対応していません。^[28] メールサーバーは別の文字セットに正当に変換することができ、多くの場合、ヘッダーフィールドでこれを文書化します。さらに、サーバーは特定の状況下では MIME 構造を書き換える必要があり、それによってプリアンブル、エピローグ、エンティティ境界が変更され、DKIM 署名が破損します。MIMEヘッダーフィールドが署名されていないことを条件として、us-asciiで書かれたプレーンテキストメッセージのみが^[29]エンドツーエンドの整合性に必要な堅牢性を享受します。 X-MIME-Autoconverted:

OpenDKIMプロジェクトは、21台のメールサーバーと数百万件のメッセージを対象としたデータ収集を組織しました。観測された署名の92.3%が正常に検証されましたが、メーリングリストのトラフィックのみを考慮すると、成功率はわずかに低下します（90.5%）。^[30]

フィルタリングや中継ソフトウェアがメッセージに変更を加えると、問題が悪化する可能性があります。送信者が特別な予防措置を講じなければ、ほとんどのメーリングリストや多くの集中型ウイルス対策ソリューションで実行されるフッターの追加によって、DKIM 署名が破られてしまいます。可能な緩和策は、メッセージ本文の指定されたバイト数のみに署名することです。これは、DKIM 署名ヘッダーのlタグで示されます。メッセージ本文の指定された長さを超えて追加されたものは、DKIM 署名の計算では考慮されません。これは MIME メッセージでは機能しません。^[31]

別の回避策としては、 SPFなどを使用して既知の転送元をホワイトリストに登録することが挙げられます。さらに別の回避策として、転送元が署名を検証し、電子メールを変更してから、Sender:ヘッダーを使用してメッセージに再署名することが提案されました。^{[32]ただし、この解決策には、RFC 5617} ADSPプロトコルを サポートするSMTP受信者が受信した転送された第三者署名付きメッセージにはリスクがあります。したがって、実際には、受信サーバーは既知のメッセージストリームをホワイトリストに登録する必要があります。

認証受信チェーン（ARC）は、メーリングリストや転送サービスなどの中間メールサーバーがメールの元の認証結果に署名できるように設計されたメール認証システムです。これにより、中間サーバーの処理によってメールのSPFレコードとDKIMレコードが無効になった場合でも、受信サービスはメールを検証できます。[ ^33] ARCは、2019年7月に公開されたRFC 8617で「実験的」と定義されています。^[34]

2012 年 10 月、Wired は、数学者の Zach Harris が、google.com企業ドメインおよび他のいくつかの有名ドメインの短い DKIM キーによるメール ソース スプーフィングの脆弱性を検出し、実証したと報じました。彼は、384 ビット キーによる認証は「私のラップトップ」で 24 時間ほどで、512 ビット キーはクラウド コンピューティング リソースを使用して約 72 時間で因数分解できると述べました。Harris は、多くの組織がこのような短いキーでメールに署名していることを発見し、それらをすべて因数分解して、組織に脆弱性を通知しました。彼は、768 ビット キーは非常に大きなコンピューティング パワーにアクセスすることで因数分解できるため、DKIM 署名では 1,024 を超えるキー長を使用する必要があると述べています。

Wired は、ハリスが報告し、Google がそれを認めたと報じた。ハリスが情報開示した直後に、Google は新しい長い鍵を使い始めた。RFC 6376 によれば、受信側は 512 ビットから 2048 ビットの範囲の鍵で署名を検証できなければならないため、512 ビットより短い鍵の使用は互換性がない可能性があるため、避けるべきである。RFC 6376 では、署名者は長寿命鍵には少なくとも 1024 ビットの鍵を使用しなければならないとも規定されているが、長寿命かどうかは規定されていない。^[35]

DKIMは、2004年にYahooの「enhanced DomainKeys」とCiscoの「Identified Internet Mail」という2つの類似した取り組みを統合して生まれました。^{[36] [37]この統合された仕様は、} IETF 標準化過程の一連の仕様とサポート文書の基礎となり、最終的にはSTD 76（現在はRFC 6376）となりました。 ^[38] 「Identified Internet Mail」は、署名ベースのメール認証標準としてCiscoによって提案されました。 ^{[39] [40]} 一方、DomainKeysは、電子メール送信者のDNSドメインとメッセージの整合性を検証するためにYahooによって設計されました。 ^{[41] [42]}

DomainKeysの側面とIdentified Internet Mailの一部が組み合わされて、DomainKeys Identified Mail (DKIM)が誕生しました。^{[41] [43] [44] DKIMを実装しているトレンドセッターのプロバイダーには、} Yahoo、Gmail、AOL、FastMail などがあります。これらの組織からのメールにはDKIM署名が必要です。^{[41] [45] [46] [47]}

間接的なメールフローを介したDKIM署名に関する議論は、正式にはDMARCワーキンググループで、新しいプロトコルの最初の採用が通常のメーリングリストの使用に大混乱をもたらした直後に行われました。しかし、提案されたDKIMの変更はどれも承認されませんでした。代わりに、メーリングリストソフトウェアが変更されました。^{[48] [無関係な引用]}

2017年には、署名技術の見直しという特定の制限を課したDKIM Crypto Update（dcrup）という別のワーキンググループが立ち上げられました。^{[49] RFC 8301は2018年1月に発行されました。SHA} -1を禁止し、鍵のサイズを更新しました（512-2048から1024-4096へ）。^[50] RFC 8463は2018年9月に発行されました。既存のRSAに楕円曲線アルゴリズムを 追加しました。追加された鍵タイプは十分に強力でありながら、短い公開鍵を特徴としており、DNSでより簡単に公開できます。^[51]k=ed25519

オリジナルのDomainKeys はYahoo! のMark Delanyによって設計され、2004 年以降、多くの人々からのコメントによって強化されました。これは Historic RFC 4870 で指定され、Standards Track RFC 4871、DomainKeys Identified Mail (DKIM) Signatures に置き換えられました。どちらも 2007 年 5 月に公開されました。その後、多くの明確化と概念化が収集され、既存の仕様の修正という形で 2009 年 8 月の RFC 5672 で指定されました。2011 年 9 月、RFC 6376 は後者の 2 つのドキュメントを統合して更新しましたが、DKIM プロトコルの本質は保持されています。以前の DomainKeys との公開キーの互換性も可能です。

DKIM は当初、非公式の業界コンソーシアムによって作成され、その後、Barry Leiba 氏と Stephen Farrell 氏 が議長を務め、 sendmailのEric Allman 氏、 PGP CorporationのJon Callas 氏、Yahoo!のMark Delany 氏と Miles Libbey 氏、 Cisco Systemsの Jim Fenton 氏と Michael Thomas 氏が主な作成者として挙げられる、 IETF DKIM ワーキング グループによって機能強化と標準化のために提出されました。

共通ライブラリのソースコード開発はOpenDKIMプロジェクトが主導しており、最新のプロトコル追加に従っており、新BSDライセンスの下でライセンスされています。^[52]

電子メール プロバイダーは、ユーザーのメールボックスにメールを正常に配信するために、送信者に電子メール認証の実装を要求する傾向が高まっています。

2024年2月、Googleは、メールをGoogleがホストするメールボックスに正常に配信するために、大量送信者に対してDKIMによるメールの認証を要求し始めました。^{[53] [54]}

同様に、2024年2月、YahooはメールをYahooユーザーに正常に配信するために、大量送信者にSPFとDKIMの実装を要求し始めました。^[55]

• 認証受信チェーン(ARC)
• 著者ドメイン署名の実践
• バウンスメッセージ
• コンテキストフィルタリング
• DMARC (ドメインベースのメッセージ認証、レポート、適合)
• ドメインキー
• メール認証
• オープンPGP
• SMIME
• 送信者ポリシーフレームワーク(SPF)
• 参照による保証

• RFC 4686 ドメインキー識別メール (DKIM) の脅威の分析
• RFC 4871 ドメインキー識別メール (DKIM) 署名の提案標準
• RFC 5617 ドメインキー識別メール (DKIM) 作成者ドメイン署名プラクティス (ADSP)
• RFC 5585 ドメインキー識別メール (DKIM) サービスの概要
• RFC 5672 RFC 4871 ドメインキー識別メール (DKIM) 署名 - 更新
• RFC 5863 DKIM の開発、展開、運用
• RFC 6376 ドメインキー識別メール (DKIM) 署名ドラフト標準
• RFC 6377 ドメインキー識別メール (DKIM) とメーリングリスト
• RFC 8301 暗号化アルゴリズムとキー使用法の DomainKeys Identified Mail (DKIM) への更新
• RFC 8463 ドメインキー識別メール (DKIM) の新しい暗号署名方式

• ドメインキー識別メール (DKIM)