DomainKeys または DKIM 電子メール認証では、送信側が公開キー暗号化を使用して、電子メールに署名します。これにより、検証済みのドメインを使用して、電子メールの From:（または Sender:）ヘッダーのドメインと比較して、偽造を検出できます。

DomainKeys と DKIM は、署名と検証の 2 つの主要部分から構成されます。AsyncOS では、DomainKeys の「署名」部分のプロセスをサポートし、DKIM の署名と検証の両方をサポートします。バウンスおよび遅延メッセージで DomainKeys および DKIM 署名を使用することもできます。

1. 管理者（ドメイン所有者）が公開キーを DNS 名前空間にパブリッシュします。
2. 管理者は発信メール転送エージェント（MTA）に秘密キーをロードします。
3. そのドメインの権限のあるユーザによって送信される電子メールが、各秘密キーによってデジタル署名されます。署名は DomainKey または DKIM 署名ヘッダーとして電子メールに挿入され、電子メールが送信されます。
4. 受信側 MTA は、電子メールのヘッダーから DomainKeys または DKIM 署名と、要求された送信側ドメイン（Sender: または From: ヘッダーによって）を抽出します。DomainKeys または DKIM 署名ヘッダー フィールドから抽出された要求された署名ドメインから、公開キーが取得されます。
5. 公開キーは、DomainKeys または DKIM 署名が適切な秘密キーによって生成されているかどうかを確認するために使われます。

Yahoo! または Gmail アドレスを使用して、送信 DomainKeys 署名をテストできます。これらのサービスは無料で提供され、DomainKeys 署名されている着信メッセージを検証します。

AsyncOS の DomainKeys および DKIM 署名は、ドメイン プロファイルによって実装され、メール フロー ポリシー（一般に、発信「リレー」ポリシー）によってイネーブルにされます。詳細については、「Configuring the Gateway to Receive Mail」の章を参照してください。メッセージの署名は、メッセージ送信前にアプライアンスによって実行される最後の操作です。

ドメイン プロファイルはドメインとドメイン キー情報（署名キーと関連情報）を関連付けます。電子メールはアプライアンスのメール フロー ポリシーによって送信されるため、いずれかのドメイン プロファイルに一致する送信側電子メール アドレスは、ドメイン プロファイルに指定されている署名キーを使用して DomainKeys 署名されます。DKIM と DomainKeys の両方の署名をイネーブルにすると、DKIM 署名が使われます。DomainKeys および DKIM プロファイルは、domainkeysconfig CLI コマンドまたは GUI の [メールポリシー（Mail Policies）] > [ドメインプロファイル（Domain Profiles）] および [メールポリシー（Mail Policies）] > [署名キー（Signing Keys）] ページを使用して実装します。

DomainKeys および DKIM 署名は次のように機能します。ドメイン所有者はパブリック DNS（そのドメインに関連付けられた DNS TXT レコード）に格納される公開キーと、アプライアンスに格納され、そのドメインから送信されるメール（発信されるメール）の署名に使われる秘密キーの 2 つのキーを生成します。

（注）	AsyncOS 10.0 以降、Web インターフェイスの [DKIMグローバル設定（DKIM Global Setting）] ページで [DKIM署名へのFromヘッダーの使用（Use From Header for DKIM Signing）] オプションを選択できるようになっています。DKIM 署名に From ヘッダーを使用することが重要なのは、主に、適切な DMARC 検証のためです。

有効なアドレスが見つからない場合、メッセージは署名されず、イベントが mail_logs に記録されます。

（注）	DomainKey および DKIM プロファイルの両方を作成した（およびメール フロー ポリシーで署名をイネーブルにしている）場合、AsyncOS は DomainKeys と DKIM の両方の署名で送信メッセージを署名します。

有効な送信側アドレスが見つかった場合、送信側アドレスが既存のドメイン プロファイルに対して照合されます。一致しているものが見つかった場合、メッセージは署名されます。見つからない場合、メッセージは署名なしで送信されます。メッセージに既存の DomainKeys（「DomainKey-Signature:」ヘッダー）がある場合、メッセージは、元の署名の後に新しい送信側アドレスが追加されている場合にのみ、署名されます。メッセージに既存の DKIM 署名がある場合、新しい DKIM 署名がメッセージに追加されます。

AsyncOS はドメインに基づいて電子メールに署名するメカニズムに加えて、署名キーを管理する（新しいキーの作成または既存のキーの入力）方法を提供します。

このマニュアルのコンフィギュレーションの説明は、署名と検証の最も一般的な使用方法を示しています。着信電子メールのメール フロー ポリシーで DomainKeys および DKIM 署名をイネーブルにすることも、発信電子メールのメール フロー ポリシーで DKIM 検証をイネーブルにすることもできます。

（注）	クラスタ環境にドメイン プロファイルと署名キーを設定する場合、[ドメイン キー プロファイル（Domain Key Profile）] 設定と [署名キー（Signing Key）] 設定がリンクしていることに注意します。そのため、署名キーをコピー、移動、または削除した場合、同じ操作が関連プロファイルに対して行われます。

署名キーはアプライアンスに格納されている秘密キーです。署名キーの作成時に、キー サイズを指定します。キー サイズが大きいほどセキュリティが向上しますが、パフォーマンスに影響する可能性もあります。アプライアンスでは 512 ～ 2048 ビットのキーをサポートしています。768 ～ 1024 ビットのキー サイズは安全であると見なされ、現在ほとんどの送信側で使われています。大きなキー サイズに基づいたキーはパフォーマンスに影響する可能性があるため、2048 ビットを超えるキーはサポートされていません。署名キーの作成方法については、署名キーの作成または編集を参照してください。

既存のキーを入力する場合、それをフォームに貼り付けるだけです。既存の署名キーの別の使用方法は、キーをテキスト ファイルとしてインポートすることです。既存の署名キーの追加の詳細については、既存の署名キーのインポートまたは入力を参照してください。

キーを入力すると、ドメイン プロファイルで使用できるようになり、ドメイン プロファイルの [署名キー（Signing Key）] ドロップダウン リストに表示されます。

署名キーをドメイン プロファイルに関連付けると、公開キーが含まれる DNS テキスト レコードを作成できます。これは、ドメイン プロファイルのリストの [DNSテキストレコード（DNS Text Record）] 列の [生成（Generate）] リンクから（または CLI の domainkeysconfig -> profiles -> dnstxt から）実行します。

DNS テキスト レコードの生成の詳細については、DNS テキスト レコードの生成を参照してください。

[署名キー（Signing Keys）] ページの [ビュー（View）] リンクから、公開キーを表示することもできます。

ドメイン プロファイルは送信側ドメインを署名に必要なその他の情報と共に署名キーに関連付けます。

• ドメイン プロファイルの名前。
• ドメイン名（「d=」ヘッダーに含まれるドメイン）。
• セレクタ（セレクタは公開キーのクエリを形成するために使用されます。DNS クエリー タイプでは、この値が送信側ドメインの「_domainkey」名前空間の前に付けられます）。
• 正規化方法（署名アルゴリズムに提示するためにヘッダーと内容が準備される方法）。AsyncOS は DomainKeys に対して「simple」と「nofws」、DKIM に対して「relaxed」と「simple」をサポートしています。
• 署名キー（詳細については、署名キーを参照してください）。
• 署名するヘッダーのリストと本文の長さ（DKIM のみ）。
• 署名のヘッダー（DKIM のみ）に含めるタグのリスト。これらのタグは次の情報を保持します。
  • 署名されたメッセージが代理したユーザまたはエージェントの ID（たとえば、メーリング リスト マネージャ）。
  • 公開キーを取得するために使用されるクエリー方法のカンマ区切りリスト。
  • 署名が作成されたときのタイムスタンプ。
  • 秒による署名の有効期限。
  • 垂直バー（|）によって区切られているヘッダー フィールドのリストには、メッセージが署名された時が示されます。
• 署名（DKIM のみ）に含めるタグ。
• プロファイル ユーザのリスト（署名用にドメイン プロファイルの使用を許可されたアドレス）。

（注）	プロファイル ユーザに指定されたアドレスのドメインは [ドメイン（Domain）] フィールドに指定されたドメインに一致している必要があります。

既存のすべてのドメイン プロファイルで、特定の用語を検索できます。詳細については、ドメイン プロファイルの検索を参照してください。

さらに、次のことを行うかどうか選択することができます。

• DKIM 署名を持つシステム生成メッセージへの署名

• DKIM 署名の From ヘッダーの使用

  この説明については、DKIM グローバル設定の編集 を参照してください。

DomainKeys 署名時には、次のような行がメール ログに追加されます。

Tue Aug 28 15:29:30 2007 Info: MID 371 DomainKeys: signing with dk-profile - matches user123@example.com
Tue Aug 28 15:34:15 2007 Info: MID 373 DomainKeys: cannot sign - no profile matches user12@example.com

DKIM 署名時には、次のような行がメール ログに追加されます。

Tue Aug 28 15:29:54 2007 Info: MID 372 DKIM: signing with dkim-profile - matches user@example.com
Tue Aug 28 15:34:15 2007 Info: MID 373 DKIM: cannot sign - no profile matches user2@example.com

DKIM 検証プロファイルは E メール セキュリティ アプライアンスのメール フロー ポリシーが DKIM 署名を保証するために使用されるパラメータのリストです。たとえば、クエリーがタイムアウトする前に 30 秒取る検証プロファイルと、クエリーがタイムアウトする前に 3 秒だけ取る検証プロファイルの、2 つの検証プロファイルを作成できます。THROTTLED メール フロー ポリシーに 2 つ目の検証プロファイルを割り当てて、DDoS の場合の接続スタベーションを防止できます。検証プロファイルは次の情報で構成されます。

• 検証プロファイルの名前。
• 許容できる公開キーの最小、最大サイズ。デフォルトのキーのサイズは 512 および 2048 です。
• メッセージの中で検証できる署名の最大数。メッセージに定義した署名の最大数よりも多くの署名がある場合、アプライアンスは残りの署名の検証をスキップし、メッセージの処理を続行します。デフォルトは、5 つの署名です。
• 送信者のシステム時刻と検証者のシステム時刻との間の時間の最大許容差（秒単位）。たとえば、メッセージ署名が 05:00:00 に期限切れとなり、検証者のシステム時刻が 05:00:30 である場合、時間の許容差が 60 秒であればメッセージ署名は有効なままですが、許容差が 10 秒であれば無効になります。デフォルトは 60 秒です。
• 本文の長さのパラメータを使用するかどうかを指定するオプション。
• 一時的な障害の場合に実行する SMTP アクション。
• 永続的な障害の場合に実行する SMTP アクション。

プロファイル名ですべての既存の検証プロファイルを検索できます。

アプライアンスのコンフィギュレーション ディレクトリに DKIM 検証プロファイルをテキスト ファイルとしてエクスポートできます。検証プロファイルをエクスポートすると、アプライアンスに存在するすべてのプロファイルが 1 つのテキスト ファイルに挿入されます。詳細については、DKIM 検証プロファイルのエクスポートを参照してください。

以前エクスポートした DKIM 検証プロファイルをインポートできます。DKIM 検証プロファイルをインポートすると、マシンの現在のすべての DKIM 検証プロファイルを置き換えることになります。詳細については、DKIM 検証プロファイルのインポートを参照してください。

アプライアンスで SPF および SIDF を使用するには、RFC 4406、4408 および 7208 に従って、SPF レコードをパブリッシュします。PRA ID の決定方法の定義については、RFC 4407 を確認してください。さらに、SPF レコードと SIDF レコードを作成する場合に犯しやすい誤りについては、次の Web サイトを参照してください。

http://www.openspf.org/FAQ/Common_mistakes

spf-status フィルタ ルールを使用する場合、次の構文を使用して、SPF/SIDF 検証結果に対してチェックできます。

if (spf-status == "Pass")

1 つの条件で複数の状態判定に対してチェックする場合、次の構文を使用できます。

if (spf-status == "PermError, TempError")

さらに、次の構文を使用して、HELO、MAIL FROM、PRA ID に対して検証結果をチェックすることもできます。

if (spf-status("pra") == "Fail")

（注）	spf-status メッセージ フィルタ ルールは、HELO、MAIL FROM、PRA ID に対して結果をチェックする場合にのみ使用できます。spf-status コンテンツ フィルタ ルールは、ID に対してチェックする場合に使用できません。spf-status コンテンツ フィルタは、PRA ID のみをチェックします。

次のいずれかの検証結果を受け取る可能性があります。

• None：情報の不足のため、検証を実行できません。
• Pass：クライアントは、指定された ID でメールを送信する権限があります。
• Neutral：ドメイン所有者は、クライアントに指定された ID を使用する権限があるかどうかをアサートしません。
• SoftFail：ドメイン所有者は、指定された ID を使用する権限がホストにないと思うが、断言を避けたいと考えています。
• Fail：クライアントは、指定された ID でメールを送信する権限がありません。
• TempError：検証中に一時的なエラーが発生しました。
• PermError：検証中に永続的なエラーが発生しました。

次の例に、spf-status メッセージ フィルタの使用例を示します。

skip-spam-check-for-verified-senders:


if (sendergroup == "TRUSTED" and spf-status == "Pass"){

skip-spamcheck();

}

quarantine-spf-failed-mail:

if (spf-status("pra") == "Fail") {

if (spf-status("mailfrom") == "Fail"){

# completely malicious mail

quarantine("Policy");

} else {

if(spf-status("mailfrom") == "SoftFail") {

# malicious mail, but tempting

quarantine("Policy");

}

}

} else {

if(spf-status("pra") == "SoftFail"){

if (spf-status("mailfrom") == "Fail"

or spf-status("mailfrom") == "SoftFail"){

# malicious mail, but tempting

quarantine("Policy");

}

}

}

stamp-mail-with-spf-verification-error:

if (spf-status("pra") == "PermError, TempError"

or spf-status("mailfrom") == "PermError, TempError"

or spf-status("helo") == "PermError, TempError"){

# permanent error - stamp message subject

strip-header("Subject");

insert-header("Subject", "[POTENTIAL PHISHING] $Subject"); 

}

.

GUI でコンテンツ フィルタから spf-status ルールをイネーブルにすることもできます。ただし、spf-status コンテンツ フィルタ ルールを使用した場合、HELO、MAIL FROM、PRA ID に対して結果をチェックできません。

GUI から spf-status コンテンツ フィルタ ルールを追加するには、[メール ポリシー（Mail Policies）] > [受信コンテンツ フィルタ（Incoming Content Filters）] をクリックします。次に [条件を追加（Add Condition）] ダイアログボックスから、[SPF検証（SPF Verification）] フィルタ ルールを追加します。条件に、1 つ以上の検証結果を指定します。

SPF 検証条件を追加したら、SPF 状態に基づいて実行するアクションを指定します。たとえば、SPF 状態が SoftFail の場合、メッセージを隔離します。

spf-passed ルールは SPF 検証の結果をブール値として表示します。次の例に、spf-passed とマークされていない電子メールを隔離するための spf-passed ルールを示します。

quarantine-spf-unauthorized-mail:

if (not spf-passed) {


quarantine("Policy");

}

（注）	spf-status ルールと異なり spf-passed ルールは SPF/SIDF 検証値を簡単なブール値に単純化します。次の検証結果は、spf-passed ルールに合格していないものとして扱われます。None、Neutral、Softfail、TempError、PermError、Fail。より詳細な結果に基づいて、メッセージへのアクションを実行するには、spf-status ルールを使用します。

次に、AsyncOS による DMARC 検証の実行方法について説明します。

1. AsyncOS に設定されたリスナーが SMTP 接続を受信します。
2. AsyncOS は、メッセージに対して SPF および DKIM 検証を実行します。
3. AsyncOS は、DNS から送信者のドメインの DMARC レコードを取得します。
   • レコードが見つからない場合、AsyncOS は DMARC 検証をスキップし、処理を続行します。
   • DNS ルックアップが失敗した場合、AsyncOS は指定された DMARC 検証プロファイルに基づいてアクションを実行します。

4. DKIM および SPF 検証の結果に応じて、AsyncOS はメッセージに対して DMARC 検証を実行します。

   （注）	DKIM および SPF 検証がイネーブルの場合は、DKIM および SPF 検証の結果が DMARC 検証で再利用されます。

5. DMARC 検証の結果と指定された DMARC 検証プロファイルに応じて、AsyncOS はメッセージを受け入れるか、隔離するか、または拒否します。DMARC 検証の失敗によってメッセージが拒否されなかった場合、AsyncOS は処理を続行します。
6. AsyncOS は適切な SMTP 応答を送信し、処理を続行します。

7. 集計レポートの送信がイネーブルの場合、AsyncOS は DMARC 検証のデータを収集し、それをドメイン所有者に送信する日次レポートに追加します。DMARC 集計フィードバック レポートの詳細については、DMARC 集計レポートを参照してください。

   （注）	集計レポートのサイズが 10 MB または DMARC レコードの RUA タグで指定されたサイズを超えた場合、AsyncOS はドメイン所有者に配信エラー レポートを送信します。

DMARC を使用した受信メッセージの検証方法

1. メッセージが偽造される可能性がある組織内のユーザ（幹部など）を特定します。新しいコンテンツ ディクショナリを作成し、特定したユーザの名前をそれに追加します。

   コンテンツ ディクショナリの作成時には、

   • ユーザの名前（電子メール アドレスではない）を入力します。たとえば、"olivia.smith@example.com" ではなく "Olivia Smith" を入力します。
   • 高度なマッチングとスマート ID は構成しないでください。
   • 使用する用語の重みは選択しないでください。
   • 正規表現は使用しないでください。

   次の図は、偽造メールの検出用に作成されたサンプル コンテンツ ディクショナリを示しています。

   
   

   

   
   

   コンテンツ ディクショナリを構成する手順については、ディクショナリの追加を参照してください。

2. 偽造メールを検出するための受信コンテンツ フィルタまたはメッセージ フィルタと、そのようなメッセージに対してアプライアンスが取る必要があるアクションを作成します。次のように指定します。
   • [条件/ルール（Condition/Rule）]：偽造メールの検出（コンテンツ フィルタの条件およびメッセージ フィルタ ルールを参照）
   • [アクション（Action）]：偽造メールの検出またはユーザの要求に基づく他のアクション。 （コンテンツ フィルタの条件 およびメッセージ フィルタ ルール を参照）。
3. 新しく作成されたコンテンツ フィルタを受信メール ポリシーに追加します。メール ポリシーをユーザ単位で適用する方法を参照してください。

検出された偽装メッセージについてのデータを表示するには、[偽造メールの一致（Forged Email Matches）] レポートのページ（[モニタ（Monitor）] > [偽造メールの一致（Forged Email Matches）]）を参照してください。このレポート ページに表示されるレポートは、次のとおりです。

• 偽装メール一致の上位（Top Forged Email Matches）受信したメッセージの偽装された From: ヘッダーと一致する、コンテンツ辞書の上位 10 人のユーザを表示します。
• 偽装メールの一致：詳細（Forged Email Matches: Details）受信したメッセージの偽装された From: ヘッダーと一致する、コンテンツ辞書のすべてのユーザの一覧と、指定したユーザの、一致したメッセージ数を表示します。メッセージ トラッキングのメッセージ一覧を表示するには、番号をクリックします。

メッセージ トラッキングでアプライアンスによって検出された偽装メッセージの詳細を表示するには、次のことを確認します。

• メッセージ トラッキングが有効である。メッセージ トラッキングを参照してください。
• 偽装メッセージを検出するためのコンテンツまたはメッセージ フィルタが動作している。