主なポイント
- ヤフーは2004年に、送信者のドメインの身元を確認し、偽造メールを減らすためにDomainKeysを導入した。
- DKIM(DomainKeys Identified Mail)はIETFによってRFC4871(2007年)で標準化され、YahooのDomainKeysとCiscoのIdentified Internet Mailを1つのオープンスタンダードに統合した。
- DKIMは、送信者が選択したヘッダーと本文の正規化ハッシュに署名することを可能にし、重要でない変更(空白の変更など)が発生した場合でもメッセージの完全性を保証します。
- DKIMのセレクタは、鍵のローテーションを単純化し、異なるサービスに対して複数の鍵を許容する。
- DKIMは、電子メールが署名に記載されたドメインによって承認され、その内容が転送中に変更されていないことを検証します。
- DKIMはDMARCのアライメントチェックに貢献し、ドメイン所有者がなりすまし防止ポリシーを実施するのに役立っている。
DomainKeysとDKIMは、なりすまし、フィッシング、スパムから保護するために設計された、関連はあるが異なる2つの電子メール認証技術である。DomainKeysは、2004年にYahooによって導入され、暗号署名を使用して送信者の真正性を検証するための最初のステップであった。しかし、柔軟性と普及には限界があった。DKIMは、DomainKeysとCiscoのIdentified Internet Mailから発展し、標準化され広く採用されるソリューションとなった。今日、DKIMは安全な電子メール通信の基礎として機能し、送信中にメッセージが真正であり、変更されていないことを保証すると同時に、ポリシー施行のためのDMARCをサポートしています。
ドメインキーズ(DK)とは何だったのか?
ドメインキーは、2004年にYahooによって開発、リリースされた初期の電子メール認証プロトコルである。その目的は、送信者のドメインの身元を確認し、増加するスパム、フィッシング、偽造メールを減らすことである。
DomainKeysの仕組みはこうだ。DomainKeysは、メッセージ全体に暗号署名を適用するシンプルな署名方式を採用していた。これは一歩前進であったとはいえ、ヘッダー選択の柔軟性に欠け、転送やメーリングリストの変更によって簡単に破られるものであった。これらの制限のため、最終的にDKIMに取って代わられ、非推奨となった。
ドメインキーの欠点
以下は、DomainKeysが最終的に交換されなければならなかったいくつかの理由である:
- プロプライエタリだった:ヤフー独自の規格であり、IETFによる標準化が広まることはなかった。
- セレクタ・メカニズムがなかった:セレクタ」がないため、ドメインは1つの公開鍵しか使えない。このため、鍵のローテーションや異なるメール送信サービスの管理が非常に困難だった。
- サインはかなりもろかった:署名の方法は非常に厳格だった。メールが転送されたり、メーリングリストによって少し修正されたりすると、ほとんどの場合、署名は壊れてしまいました。
- 柔軟性が限られていた:署名アルゴリズムや正規化(署名前にメールをどのように処理するか)のオプションはほとんどなかった。
DKIM(DomainKeys Identified Mail)の紹介
DKIMDKIM(DomainKeys Identified Mail)は、電子メールの認証プロトコルで、送信者が配信中に電子メールのコンテンツが操作されるのを防ぐことを可能にする。DKIMは、2004年から2005年にかけてのYahooとCiscoのコラボレーションに端を発し、2007年にIETF標準となった(RFC 4871).
これは、メッセージのヘッダーにデジタル署名を追加することで機能します。受信者はDKIMで署名されたメールを受け取るとすぐに、その署名が有効かどうかを確認する。署名が有効であれば、メッセージは無傷で送信され、ハッカーによって操作されていないことがわかります。
以下はDKIMシグネチャの例です:
DKIM-署名 v=1; a=rsa-sha256; d=example.com; s=selector1; h=from:subject:date; bh=abc123...; b=xyz456...
DKIMの仕組み
DKIMは、秘密鍵と公開鍵という一対の暗号鍵に依存しています。これらの鍵は、電子メールが本物であり、改ざんされていないことを保証するために不可欠です。
電子メールが送信されると、送信者のメールサーバーは秘密鍵を使用してデジタル署名を作成します。この署名は、署名ドメイン、使用されたアルゴリズム、および署名に含まれるヘッダーに関する情報とともに署名自体を含む電子メールの特別な部分であるDKIMヘッダーで電子メールに追加されます。
電子メールが受信者に届くと、受信者のメールサーバーは送信者のDNSから公開鍵を取得する。そしてサーバーはこの公開鍵を使ってDKIMヘッダーをチェックし、署名がメッセージと一致するかどうかを検証する。もし一致すれば、メールは本物であり、変更されていないことが確認される。
要するにDKIMヘッダーが署名を運び、秘密鍵がそれを生成し、公開鍵がそれを検証することで、電子メールの完全性と真正性の両方が保護される。
キー・イノベーション:DKIMのDomainKeysに対する主要な革新は、信頼性の高いドメインベースの認証のために、セレクタと堅牢な正規化を備えた標準化された柔軟な暗号署名を導入したことである。
DomainKeys 対 DKIM:主な違い
頭文字の違いはわずか2文字だが、大きな違いがある。DKIMはDomainKeysの制限を修正するために生まれた。
1.標準化と採用
- ドメインキー:ヤフーが独自に開発したもので、その採用はかなり限られていた。 完全に時代遅れ.
- DKIM:これは オープンなIETF標準.この中立性と技術的優位性が、グーグルやマイクロソフトを含むすべての主要メールプロバイダーが採用する主な理由となった。
2.シグネチャーの柔軟性
- DomainKeys:特定のヘッダーとメッセージ・ボディ全体に署名していたため、メッセージが転送中に変更されると、しばしば署名の破損を引き起こしていた。
- DKIM:DKIMの本文ハッシュと正規化により、ちょっとした書式変更には寛容になりますが、転送やメーリングリストの変更で署名が壊れることはあります。送信者が 正確にどのヘッダに署名するか(h=タグ)。さらに メッセージ本文のハッシュ(bh=タグ)のハッシュを署名する。また、正規化 (c= タグ)を使って、空白のようなメッセージの変更をどのように扱うかを定義します。
3.鍵管理とセレクタ
- ドメインキー:セレクタ・メカニズムが欠落しているため、ドメインからのすべてのメッセージは単一の公開鍵を使用せざるを得ず、鍵のローテーションと管理が複雑になる。
- DKIM: というコンセプトを導入した。 "セレクタ" セレクタは 具体的 公開鍵をDNSに登録する。これにより、以下のことが可能になります:
- Google Workspaceやマーケティングプラットフォームなど、サービスごとにキーを使い分けよう。
- 郵便物の流れを妨げることなく、セキュリティーを確保するためにキーをローテーションします。
DKIMレコードの作成にヘルプが必要な場合は 無料のDKIMレコードジェネレーターをご利用ください。
4.セキュリティと完全性
- DomainKeys:送信者の信頼性に焦点を当てた。
- DKIM:ボディ・ハッシュ・チェック (bh=)は、電子メールの内容が署名されてから変更されていないことを確認します。
DomainKeys 対 DKIM: 比較表
| 特徴 | ドメインキー(DK) | DomainKeys Identified Mail (DKIM) |
|---|---|---|
| 開発者 | 2004年のヤフー(独占 | ヤフーとシスコの共同開発で、後にIETFで標準化された。2007年に導入され(RFC 4871)、RFC 6376(2011年)で更新された。 |
| 目的 | 送信者のドメインを認証し、偽造メールやスパムを減らす | 送信者のドメインを認証し、メッセージの完全性を確保する。 |
| ヘッダー・フィールド名 | ドメインキー署名: | DKIM-署名: |
| セレクター機構 | 非対応 | 対応(selector._domainkey.example.com) |
| キーマネージメント | ドメイン全体の単一キー | セレクターによる複数キー、簡単なキーローテーション |
| 署名の範囲 | メッセージ本文全体とヘッダーの一部 | 送信者が選んだ特定のヘッダー(h=タグ)とハッシュ化されたメッセージ本文(bh=タグ) |
| 正規化オプション | ベーシックまたはなし | シンプルで柔軟な正規化オプション |
| ボディ・ハッシュ | 全身に直接サイン | ボディ・ハッシュ(bh=)を使用することで、細かな変更にも対応。 |
| 検証領域 | 差出人」または「送信者」ドメインに基づく | 署名のd=タグに基づく |
| DMARCとの統合 | 非対応 | 完全サポートでアライメントチェックに使用 |
| 採用とステータス | 採用は限定的、時代遅れ | 広く採用され、積極的に利用されている |
| 主な制限 | 厳格な署名プロセス、セレクタなし、署名破損 | 目に見える "From "ヘッダーを保護しない(DMARCが必要) |
DKIMがDomainKeysに取って代わった理由
DKIMがDomainKeysに取って代わったのは、プロトコルの主な技術的限界、つまり標準化の欠如、キーローテーションのためのセレクタメカニズムがないこと、ちょっとしたメッセージの変更で壊れてしまう脆弱な署名などを解決したからである。DKIMは、柔軟なヘッダー署名、より強力な暗号、およびIETF標準化を導入し、より信頼性が高く、スケーラブルで、電子メール認証に広く採用されるようになった。
DKIM導入のビジネス上のメリット
DKIMには多くの利点がある:
なりすましとフィッシングの防止
DKIMだけではなりすましやフィッシング攻撃を防ぐことはできないが、DMARCと連携してドメインのセキュリティを強化し、偽物を排除することができる。
ブランド保護
詐欺師があなたのドメインを使って悪意のあるメールを送ると、あなたのブランドの評判が落ちます。受信者はあなたの名前を スパムと詐欺を連想させ、信頼の失墜につながります。DKIMは受信箱の中であなたのブランドの完全性を維持します。
メール配信
以下のような主要な受信箱プロバイダー グーグルやマイクロソフトなどの主要な受信箱プロバイダーは、有効な認証を期待し、要求している。DKIMをパスしたメールはより信頼できるとみなされる。
メッセージの完全性
DKIM署名は、メールの内容が送信後に改ざんされていないことを保証します。これは、受信者が読むメッセージが、あなたが送信したメッセージそのものであることを保証するのに役立ちます。
DKIMだけでは不十分な理由
DKIMは強力なツールだが、単独で使用する場合、1つの大きな制限がある: それは、ヘッダーの "From "のなりすましを止められないことである。
DKIMは、電子メールが d=タグに記載されたドメインによって署名されたメールであることを確認する。しかし はドメインが 目に見える「のアドレスと一致する必要はない。フィッシャーは、CEOの代理として "From "メールを送信することができるが、自分の悪意のあるドメインで署名することができる。そのメールはDKIMチェックをパスするだろうが、なりすまし攻撃であることに変わりはない。
そこで DMARC の出番だ。
DMARCは、認証とアイデンティティの間のギャップを埋める。DKIMまたはSPFによって認証されたドメインと、受信者が "From "ヘッダーで確認できるドメインが一致することを保証する。
まとめ
DomainKeysが道を切り開きましたが、DKIMは今日でも信頼できるメール認証の標準です。DKIMをDMARCと組み合わせることで、なりすましやフィッシングから確実に保護することができます。
設定を間違えると、正当なメールでさえもブロックされてしまいます。このような問題やDKIMに関するその他の課題を回避するために、PowerDMARCの ホスティングDKIMサービスが役立ちます。これは、DKIM管理プロセスのあらゆる側面を引き受けるクラウドサービスです。一元化されたダッシュボードから、DNSレベルの変更に対処することなく、すべてのドメインの複数のセレクタとキーを追加、編集、管理することができます。
無料トライアル今すぐ無料トライアルを開始し、配信能力を高め、認証を改善し、なりすましからドメインを保護しましょう!
よくあるご質問
- DomainKeysは今でも使われているのですか?
今は違う。非推奨となり、最新のDKIMプロトコルに取って代わられた。
- PowerDMARCはDKIM管理にどのように役立ちますか?
PowerDMARCは、自動DKIM展開、セレクタ、キー管理を可能にするホスト型DKIMソリューションを提供します。
- IPレピュテーションとドメインレピュテーション:どちらが受信トレイへの到達率を高めるか? - 2026年4月1日
- 保険金請求詐欺は受信トレイから始まる:なりすましメールが、日常的な保険業務の流れを保険金横領へと変える仕組み - 2026年3月25日
- FTCセーフガード規則:貴社の金融会社にはDMARCが必要ですか? - 2026年3月23日
