朝から昼寝

ITや家計、身近なことの整理

[お知らせ]
当サイトは、2024年1月1日に
新URL(happynap.net)に引っ越しました





このページの内容は、最新ではない場合がありますので、新URLをご確認ください。






当サイトには広告を含みます。"オススメ"として紹介している商品やサービスは、個人的にそう思えたものだけです。
共感、興味をもっていただけるものがあればご利用ください (広告掲載ポリシー)。

DKIM認証の整理しておきたいポイント

概要

電子メールの送信元ドメインが詐称されていないかを検証する送信ドメイン認証(Sender Domain Authentication)。
本記事は、DKIM認証についてまとめたものです。
SPF、DKIM、DMARC、ARC、BIMIといった送信ドメイン認証を俯瞰的にまとめた記事はこちらです。

DKIMの設定例として、別記事にPostfixとOpenDKIMの設定(図解)をまとめてあります。

本記事の目的

  • DKIM認証の概要を理解する。
  • DKIM対応の際してのポイントを把握する。

※本記事では、整理しておきたいポイントを中心に記載しています。ネット上に解説記事が多そうな内容については省略している場合があります。


目次

基本

DKIMの認証対象と認証成否

  • メールヘッダ(DKIM-Signatureヘッダ)にある電子署名を認証します。
  • 電子署名の中で指定されたドメインのDNSに登録されたDKIMレコードに基づいてその署名を検証し、正しいものであると判断できれば認証成功です。
  • DKIMレコードを保有するDNSドメインの管理元により、「メールに署名することを認められたメール送信システム、あるいはメール中継システムが、そのメールの配送経路上に存在した」という点が担保されます。
    (”署名することを認められた"という表現は、検証に成功する署名を作成できるのは、DNSレコード上の公開鍵とペアになる秘密鍵を持つシステムのみであるという意味)
    ※なお、DKIMは、必ずしもFromドメインと一致するドメインに対する署名を検証するとは限らないので、DKIMが担保できる範囲を簡潔に表現するのは難しいように思います。RFC 6376の中では、"to claim some responsibility for a message(そのメールにいくぶんか責任を持つ/主張する)"といった表現が使われています(これは私の備忘用ですが"claim responsibility"は犯行声明を出す意味でも使われる表現)。
  • また、別の観点では、「そのメールにおいて、電子署名の範囲(hタグで指定したヘッダ、および、本文の全部もしくはlタグで指定した一部)については(署名された時点から)改ざんされていない」という点も担保されます。

認証時の動作

  • メールを受信する側が、上記の認証を行います。
  • DKIM署名の検証は、DKIM-Signatureヘッダで指定されているドメイン(dタグ)に対してDNS問合せを行い公開鍵を取得することで可能となります。
    その際のDNSクエリは、DKIM-Signatureヘッダ内のdタグ、sタグの値をもとに生成されます。
    一般的に、以下のTXTレコードをDNSに問い合わせます。
    (selector:sタグの値)._domainkey.(domain:dタグの値)
  • DKIM署名には種類が2つあります。
    基本的に作成者署名が望ましいです。なお、第三者署名によるDKIMはDMARC対応不可です。
    • 第三者署名:メール作成者ドメイン(メールヘッダのFromフィールドに書かれているドメイン)とは異なるドメインでDKIM署名する方式(例:メール配信サービスが標準で提供するDKIM機能)
    • 作成者署名:メール作成者ドメインと同じドメインでDKIM署名する方式(メール作成者ドメインの組織内で鍵を準備すべき)
  • 署名に使用する鍵は定期的に更新が必要です。IIJの資料によると、3か月~1年程度と記載がありますが、基本的に鍵の強度(鍵長)によると思われます。

DKIM対応に必要な設定

  • DNSレコード登録と、DKIM署名追加機能の実装が必要です(鍵の準備を含む)。設定に際しての補足事項は別記事にまとめる予定です。

認証結果

  • DKIMの認証結果は、大きく"Pass"か、"Pass以外"("Fail"等)に分類できます。種類は以下の通りです。
    • DKIM(RFC 6376)では、以下が定義されています。
      • SUCCESS
      • PERMFAIL
      • TEMPFAIL
    • ただし、メール配送時の認証結果を把握する上で実用的なものとしては、Authentication-Resultsヘッダ(RFC 8601)におけるDKIM認証結果("dkim=")の値として、以下が定義されています。
      • none
      • pass
      • fail
      • policy
      • neutral
      • temperror
      • permerror
  • 認証結果は、送信ドメイン認証において共通的に使用されるAuthentication-Results(AR)ヘッダに記録されます。ARヘッダの詳細は別記事にまとめる予定です。

詳細

導入ステップや運用ポリシーに応じた調整のポイント

  • DKIM自体には、SPFにおける修飾子やDMARCにおけるポリシー(p=)のような、検証基準を調整するパラメタはありません。
    よって、DKIM単独では、(送信元ドメイン側としては)試験的な段階を設けることは難しいでしょう。
  • DKIM単独でなく、SPF、DMARCも併用することで、メールを受信する側でDKIM認証が何らか失敗した場合にも、SPFやDMARCの認証結果、DMARCのポリシー(p=)と合わせて判断することが可能です。
    また、自ドメイン側としても、その際のDMARCレポートを受け取ることで状況分析が可能になります。
  • ちなみに、DKIM ADSP(RFC 5617)というものがありますが、既にIETFによって"Historic"の扱いに変更されています。今後新規に対応する必要性は無いと思われます。
    ADSPは、あるメールのDKIM署名検証が失敗した際、メールを受信した側がそのメールを実際に拒否/破棄すべきかどうかの判断を補助する情報を示す仕組みです。