ガイド · DKIMの設定

プロダクトチームはDKIMをどう安全に設定すべきか

DKIMを設定するには、組織が所有する署名ドメインを選び、プロバイダーや署名システムごとに固有のセレクターを用意し、保護されたサービスで鍵ペアを生成し、selector._domainkey.example.comに公開鍵だけを公開し、実際の送信経路で対象となるすべてのメッセージに署名するよう設定します。外部のメールボックスで受信した元のメッセージのバイト列に対して署名を検証し、DMARCがDKIMに依存する場合はd=ドメインが表示上のFromドメインとアライメントしていることを確認してから、段階的に展開します。本番トラフィックを移す前に、セレクターの担当、ローテーション、失効、ロールバックを文書化してください。

鍵を生成する前に、実際の送信経路をすべて洗い出す

DNSレコードではなくインベントリから始めてください。組織の表示Fromドメインを使用してメールを送信できるすべてのシステムを列挙します。アプリケーションワーカー、トランザクションプロバイダー、マーケティングプラットフォーム、サポートツール、IDシステム、チケット管理ソフトウェア、リレー、緊急時の経路です。それぞれについて、所有者、メッセージ種別、エンベロープ送信者、表示Fromドメイン、現在のDKIM d=ドメイン、セレクター、署名コンポーネント、その後に別のリレーがメッセージを変更するかを記録してください。あるプロバイダー向けに公開したDKIMキーは、その秘密鍵を使用しない別の経路には何の効果もありません。同様に、1つの検証済みドメインを示す一般的なプロバイダーダッシュボードだけでは、すべてのテナント、リージョン、ストリーム、テンプレート、フォールバックが署名されていることを証明できません。すべての経路から管理されたサンプルを取得し、元のヘッダーを保持してください。署名を有効化する前に、どの経路が許可されているかを決めます。DKIMは署名に対するドメインの責任を認証しますが、受信者の同意やメッセージ内容の真実性を認証するものではありません。

DMARCのアライメントに対応できる署名ドメインを選ぶ

DKIMのd=タグは署名ドメインを示します。組織が管理し、メールストリームを運用する期間を通じて統制できるドメインを選んでください。DMARCがDKIMに依存する場合、d=ドメインは、該当するrelaxedまたはstrictのアライメントルールのもとで、表示上のRFC 5322 Fromフィールドのドメインとアライメントしている必要があります。プロバイダーが所有する署名ドメインでは、DKIMの結果は有効でも、組織のFromドメインとはアライメントしないことがあります。所有権、レピュテーションの分離、DNSの委任、インシデントの切り分けを考慮し、各ストリームの署名をApexドメインで行うか、用途別のサブドメインで行うかを決めてください。レピュテーションやポリシーの問題を回避するためだけに余分なドメインを作ってはいけません。組織ドメインとの関係と、想定するDMARCのモードを記録します。アライメントは最終的に受信したヘッダーでテストしてください。メッセージが別のd=の値を使っている可能性があるため、セレクターのルックアップだけから推測してはいけません。

セレクターを運用上のIDとして割り当てる

セレクターにより、ドメインは複数のキーを公開し、1つのグローバルレコードを置き換えずに変更できます。秘密情報を漏らさずにプロバイダーまたは署名者とローテーション世代を識別する、決定論的なセレクターポリシーを作成してください。たとえば、product-a-2026q3はdefaultより明確かもしれませんが、名前はDNSの規則とツールの制限内に収めてください。DNSレコードを減らすためだけに、無関係なプロバイダー、環境、テナント間で1つの秘密鍵を再利用してはいけません。セレクター、d=ドメイン、用途、署名サービス、所有者、作成日時、アルゴリズム、公開鍵フィンガープリント、デプロイ状態、ローテーション期限、廃止の証拠を含むレジストリを維持します。公開前に正確なセレクター名を確認してください。ルックアップは`selector._domainkey.signing-domain`です。表示Fromドメイン、return-pathドメイン、または誤ったDNSゾーンに誤ってレコードを作成しても、意図した署名は検証されません。これで署名された遅延メールと再試行が期限切れになるまで、古いセレクターを削除しないでください。

秘密鍵を生成して保護する

プロバイダーが対応している場合は、マネージドの鍵管理サービスか、厳重に管理された署名システムの内部で鍵ペアを生成してください。秘密鍵は、公開DNS、ソース管理、ブラウザのコード、CIの出力、分析、通常のログ、チケット、ドキュメント、プロンプト、共有チャットに決して含めてはいけません。署名へのアクセスは鍵を必要とするメールコンポーネントにのみ許可し、本番環境とそれ以外の環境を分け、管理者のアクセスを記録します。RFC 8301はDKIMの暗号要件を更新しており、署名者は1024ビット以上のRSA鍵を使わなければならず、2048ビット以上を使うべきだとしています。また、より長い鍵に関するDNSの運用上の制約にも触れています。古い例をそのまま写すのではなく、選択した署名者と受信側の現在の機能と推奨事項に従ってください。Ed25519を検討する場合、RFC 8463がDKIMでの使用を定義していますが、相互運用性をテストし、必要に応じて互換性のある署名方式も維持しなければなりません。ローテーションは、秘密鍵をエクスポートせずに行えるようにしておく必要があります。

公開鍵を正確に公開する

正確な`selector._domainkey.signing-domain`オーナー名にTXTレコードを公開します。DKIMキーレコードには、v=DKIM1、必要に応じたキータイプを示すa=、秘密鍵ラッパーを含まない公開鍵マテリアルを保持するp=などのタグが入ります。署名者が指定する正確なレコード形式と、DNSプロバイダーの引用符の扱いに従ってください。保存前に、DNSインターフェースがゾーンを自動で追加するか、長い文字列を分割するか、文字をエスケープするかを確認します。公開後、まず権威DNSサーバーを直接クエリし、次に独立したキャッシュリゾルバーをクエリして完全なTXT値を再構築します。1つのTXTレコード内の複数の文字列はDNSクライアントによって連結されますが、競合する複数のリソースレコードは曖昧さを生む可能性があります。ロールバック用に以前の応答とTTLを保持してください。チェッカーを黙らせるためだけに、より広いキーを公開したり、本番環境にテストフラグを残したりしてセキュリティを下げてはいけません。表示されるレコードはDNSへの公開を証明しますが、送信者が一致する秘密鍵を使用することを証明するものではありません。

最終段の署名者と署名対象フィールドを設定する

最終的なメッセージを送信経路に渡すコンポーネントで署名を設定するか、後段のコンポーネントが署名済みの内容を変更しないようにしてください。DKIM署名は、本文ハッシュと、h=に列挙されたヘッダーフィールドを対象とします。RFC 6376は、有効な署名のためにFromヘッダーフィールドへの署名を必須としています。プロダクトにとってIDの観点で重要なヘッダーを含め、同じヘッダーが複数ある場合にどれが選ばれるかを理解し、必要な後段のシステムが書き換えなければならないフィールドは、その変換を管理できる場合を除いて署名対象から外してください。正規化は意図をもって選びます。relaxedの正規化は、定義された空白やヘッダーの書式の変更を許容しますが、本文の任意の編集は許容しません。simpleの正規化はより壊れやすくなります。署名後のフッターの挿入、リンクの書き換え、MIMEの境界の変更、転送エンコーディングの変換、件名へのタグ付け、改行コードの正規化は、検証を失敗させる可能性があります。承認済みの変換を終えた、完全にレンダリングされたメッセージに署名し、信頼できないユーザーがd=、s=、ヘッダーのリスト、鍵を選べないようにしてください。

受信した元のメッセージをエンドツーエンドで検証する

本番と同じ形をした実際の各経路を通して、チームが運用する外部のテスト用メールボックスに管理下のメッセージを送信します。コピーした本文や再シリアライズされたチケットの添付ファイルではなく、元のrawメッセージを保存してください。DKIM-Signatureのd=とs=の値、署名対象ヘッダーのリスト、本文ハッシュ、アルゴリズム、正規化、タイムスタンプ、有効期限があればそれも確認します。独立したネットワークから公開鍵を問い合わせ、標準に準拠した検証ツールを元のバイト列に対して実行します。RFC 8601の信頼境界を尊重しつつ、信頼できる受信側のAuthentication-Resultsヘッダーを自分の検証ツールの結果と比較してください。プレーンテキスト、multipart/alternative、想定される添付ファイル、Unicodeの件名、長いヘッダー、テンプレート、トラッキングによる変換、再試行、リレーの経路をテストします。ネガティブテストには、フィクスチャ内で意図的に変更した署名対象ヘッダー、存在しないセレクター、期限切れまたは廃止済みのセレクター、署名を迂回する経路を含めるべきです。テストのために実際の顧客のメールを改変してはいけません。

DKIM、DMARC、配信は別々の結果として評価する

DKIM passは、検証者が署名対象のフィールドと本文に対し、特定された署名ドメインの有効な署名を見つけたことを意味します。これは、未署名のすべてのヘッダーを認証すること、人間の作成者を確認すること、受信者の同意を証明すること、法令遵守を確立すること、受け付けや受信トレイ到達率を保証することを意味しません。DMARCは、passしたDKIMまたはSPFドメインが表示Fromドメインとアライメントしているかを別途評価し、ドメイン所有者のポリシーを適用します。管理されたテストでは、少なくともDKIM結果と理由、d=ドメイン、セレクター、表示Fromドメイン、アライメント結果、SPF結果、DMARC結果、受信側、タイムスタンプを記録してください。日常的なメトリクスから完全な受信者アドレスとコンテンツを除外します。SMTPプロバイダーによる受け付け、受信者サーバーによる受け付け、その後のバウンス、メールボックスフォルダーでの配置、エンゲージメントは後の状態です。DKIMがpassしてもメールが拒否またはフィルタリングされる場合は、キーを繰り返しローテーションするのではなく、DMARCアライメント、SPF、IPとドメインのレピュテーション、苦情率、メッセージポリシー、レート、受信側のガイダンスを調査してください。

検証の空白期間を生まずにローテーションする

セレクターを重複させて運用します。まず新しい保護された鍵を生成し、その公開レコードを新しいセレクターで公開します。権威DNSとフルリゾルバーでの結果を確認し、署名者が新しいセレクターを使うよう設定して、すべての経路で管理下のテストを送信します。古いセレクターと新しいセレクターを使った署名の割合と、その検証結果を監視してください。古い公開鍵は、キュー内のメッセージの最大滞留時間、再試行期間、DNSのキャッシュ期間に、明示的な安全マージンを加えた期間は利用可能な状態に保ちます。その後、古いセレクターによる署名をすべて止め、それを参照している有効な設定がないことを確認し、ポリシーに従ってレコードを廃止します。秘密鍵が漏えいした後の緊急の失効では、より迅速な削除、トラフィックの一時停止、プロバイダーの認証情報のローテーション、インシデントの連絡が必要になる場合があります。そのトレードオフは事前に文書化しておいてください。通常のローテーションで1つのセレクターをその場で上書きしてはいけません。キャッシュされた古い公開鍵のせいで、新しい秘密鍵で署名されたメッセージの検証が失敗することがあるからです。

失敗は署名を起点に外側へ向かって診断する

署名がない場合は、メッセージが署名されないストリーム、許可されていないFromドメイン、フォールバックのリレー、テンプレートの経路のどれを使ったのかを特定します。鍵が見つからない場合は、s=とd=による正確なルックアップ、ゾーンの委任、権威サーバーの応答、DNSSECやリゾルバーのエラー、反映状況を確認します。本文ハッシュが一致しない場合は、署名前と受信後のrawのMIMEを比較して、署名後の変換を見つけます。署名が一致しない場合は、公開されている公開鍵が有効な秘密鍵と対応していることを確認し、正規化と署名対象ヘッダーを調べます。DKIMは合格してDMARCが失敗する場合は、表示上のFromドメインとのアライメントを評価します。一時的なDNSルックアップのエラーは、恒常的な設定上の不具合とは分けて分類し、送信経路での上限付きの再試行は、SMTPの応答が一時的なものである場合に限って行ってください。ドメインをまたいだ署名、不明な鍵、広範な検証失敗、鍵の漏えいの疑いがある場合は、影響を受けるストリームを一時停止します。プライバシーに配慮して最小化した証拠を保存し、管理下の再テストごとに変更する変数は1つにとどめてください。

送信システムのDKIMドキュメントを使用する

実際の送信システムと権威DNSサーバーでDKIMを設定し、元の受信メッセージを検証して、最新のIETF標準とプロバイダー固有のドキュメントを参照してください。

よくある質問

DKIMの公開鍵はどこに公開しますか？

selector._domainkey.signing-domainにTXTレコードとして公開します。送信時の署名に含まれるのと同じ正確なセレクターとd=ドメインを使ってください。

DKIMの秘密鍵をDNSに置いてもよいですか？

いいえ。DNSに含めるのは公開鍵の情報だけです。秘密鍵は、アクセス範囲を狭く絞り、ローテーションを管理できるマネージドの署名者または秘密情報の境界の内側に保管してください。

1つのDKIMセレクターをすべてのメールプロバイダーで使い回せますか？

そのような設計は避けてください。ローテーションや漏えいが無関係な経路に影響しないよう、セレクターと秘密鍵はプロバイダー、署名者、環境、リスクの境界ごとに分けましょう。

DKIMが合格すればDMARCも合格しますか？

必ずしもそうではありません。DMARCでは、アライメントしたSPFの合格で代わりにDMARCを満たす場合を除き、合格したDKIMのd=ドメインが表示上のFromドメインとアライメントしている必要があります。

フッターの追加やトラッキングによる書き換えの後にDKIMが失敗するのはなぜですか？

DKIMは選択したヘッダーと本文ハッシュを対象とします。選択した正規化ルールの範囲外で後段が変更を加えると、作成済みの署名が無効になることがあります。

DKIMの鍵はどのようにローテーションすべきですか？

まず新しいセレクターを公開して検証し、管理しながら署名をそのセレクターに切り替え、結果を監視します。古い公開鍵は再試行期間とキャッシュ期間が過ぎるまで残し、その後に廃止します。

DKIMは受信トレイへの到達を決めるものですか？

いいえ。DKIMが提供するのは、範囲を限定したドメイン署名の証拠です。受信側は配信の結果を決める前に、DMARC、SPF、レピュテーション、苦情、コンテンツ、送信レート、メールボックスのポリシーをそれぞれ独立に評価します。

公開DNSレコードはDKIM署名が有効であることを証明しますか？

いいえ。公開されたキーに対して元の受信メッセージを検証し、DKIM-Signatureヘッダーのd=値とs=値を確認してください。

出典

さらに学ぶ

アプリケーションメールのDKIMを確認する方法実際の署名を調べ、セレクターとドメインを問い合わせ、メッセージを検証し、受信側の結果を読み取り、アライメントをテストしてDKIMを確認します。アプリケーションメールのDMARCを確認する方法DMARCレコードの検出、構文、SPFとDKIMのアライメント、ポリシー、レポート、実際のアプリケーションメッセージを、DNSルックアップと配信を混同することなく確認します。アプリケーションメールのSPFレコードを確認する方法アプリケーションメールについて、正しいSPFドメイン、構文、メカニズム、入れ子になったDNSの予算、送信元IPの許可、結果、DMARCのアライメントを確認します。メール到達率サービスの評価方法対象範囲、根拠、認証、フィードバックループ、サプレッション、プライバシー、移行のしやすさ、運用への適合性でメール到達率サービスを評価します。メールプロトコルSMTP：アプリケーションメールが届く仕組みSMTPのサブミッション、リレー、エンベロープ、応答コード、TLS、再試行、メッセージの内容が、アプリケーションメールのワークフローをどう形作るのかを学びます。