Cisco ESA DMARC 設定ガイド

この記事では、DMARCをCiscoのEメールセキュリティアプライアンス
(ESA)にDMARCを導入するためのガイドを紹介します。

すでにDMARC認証とレポートが正しく設定されているとお考えの場合は、この情報をお読みになり、現在の設定と比較してください。これらの設定は業界のベストプラクティスであり、これらの設定から逸脱しないことをお勧めします。ESAのAsyncOSバージョンは13以上でなければなりません。14未満のバージョンではバグがあるため、14の場合は14.0.2以上にしてください。

注意事項

正しく設定されていない場合は、設定しないでください。正しく設定されていない場合、他の送信元から送信される有効なデータを汚染することになり、DMARCデータはアグリゲータによってブラックリストに登録される可能性があります。
お使いの環境でSPFまたはDKIM検証を実行する方法または実行するかどうかで推奨から設定を変更すると、システムが適切なDMARC分析を実行する能力に影響を与え、システムが送信するレポートデータの品質も（役に立たないほど）低下します。
システムのDMARC実施アクションを、メッセージに対して決定されるポリシーから変更することは、世界中のドメイン所有者がトラフィックを認証するために投資してきた作業を台無しにする。認証をチェックし、修正し、p=rejectまたはp=quarantineポリシーを公開するために必要な長さを費やしてきたのであれば、それを遵守し、ESAがその結果に従うようにしてください。
あなたのドメインがまだp=rejectまたはp=quarantineになっていない場合、ESAの強制設定はFromヘッダにあなたのドメインが含まれるメールには影響しません。そして、これらの設定を自分のDMARCレコードに適用する頃には、すべての環境が自分のポリシーに従うことを望んでいるはずです。グローバルなレポーティング＋エンフォースメント環境に参加することで、メリットを享受できます。

これらの変更を行った結果
検証プロファイル
DMARCの設定
メールフローポリシー
無料相談開催中！

これらの変更を行った結果

ESA は、受信メッセージの SPF および DKIM 認証結果を正しく判断します。これには強制的な要素はありません。つまり、この結果を決定しても配信結果が変わることはありません。
- メールログに追加の関連ログが記録され、受け入れられたメッセージのヘッダーに追加の有用な情報が記録される場合があります。
ESAはDMARC認証結果（SPFとDKIM認証結果の両方に依存）を決定し、ポリシーを実施します。
- これにより、スパムやフィッシングからの保護が強化されます。メールログに関連するログが追加されたり、受信したメッセージのヘッダーに有用な情報が追加されたりする可能性があります。
DMARC認証がチェックされたドメインにp=reject DMARCポリシーがあり、認証に失敗した場合、メッセージはドメイン所有者が期待し要求したようにSMTP会話中に拒否される。
DMARC認証がチェックされたドメインにp=quarantine DMARCポリシーがあり、認証に失敗した場合、メッセージはESAのポリシー隔離に隔離される。
DMARC 認証がチェックされたドメインに p=none DMARC ポリシーがあり、認証に失敗した場合、メッセージには何のアクションも実行されません。
ESA は、DMARC レコードで指定されたアドレスのドメイン所有者に DMARC RUA データを生成して送信します。たとえば、ESAがメッセージのFromヘッダにgmail.comが存在するメッセージを検出した場合、ESAはgmail.comの報告アドレス（現在のアドレスはmailauth-reports@google.com）にRUAレポートを生成します。

このガイドでは、以下の順番でアクセスし、更新していただきます。これらのアクションは、ESAユーザー・インターフェースのMail Policiesメニュー（左の画像を参照）で確認できます。

DKIM検証プロファイル
DMARC
メールフローポリシー

検証プロファイル

厳密には、これは「DKIM検証プロファイル」であるべきで、「DomainKeys」は誰も使っていないはずだからだ。

DEFAULTプロファイルのみを作成、保持、または変更することを推奨する。先に述べたように、DKIM検証それ自体（このように設定されたもの）は、メッセージの配送に何の影響も与えない。

以下のスクリーンショットに示すように、プロファイルを変更、更新、または作成して、設定を正確に一致させてください。

検証プロファイル – 備考

1024未満の鍵は、実運用には弱すぎることが知られている。このサイズ以下のDKIM鍵は使用しない。
2048より大きな鍵が使用されているが、これはCiscoのバグであり、ESAはこのような大きな鍵を作成または検証できない。
ここには、管理者が DKIM の結果または（DNS の結果による）検証の失敗のみに基づいて、メッセージの拒否や遅延を発生させる設定がある。これらを使用しないでください。

DMARCの設定

前のセクションとは異なり、以下のいくつかの設定は、独自の環境に基づいてスクリーンショットから変更する必要があります。以下のような設定にして、以下のセクションのガイダンスを参考に、ご自身の環境に合わせて変更する必要があるものを設定してください。

DMARCの設定 – グローバル設定

スケジュールRFCの標準と勧告にかなり忠実に従うため、レポート作成予定時刻は、UTC時間で終業時刻の約15分前とする必要があります。つまり、米国東海岸にいる場合は、西海岸とは異なる設定になります。Ciscoにはこの設定項目がいかに貧弱であるかというバグがあるので、問い合わせてみてほしい。あなたが思っているよりずっと複雑です。CiscoのバグはCSCun35657です。
エンティティ：あなたの会社または組織。この設定は、すべての ESA で同じにする必要があります。
追加の連絡先：これは、ドメイン所有者に送信されるXMLデータに入力されます。これは、あなたのドメインの実際のアドレスであるべきですが、おそらく厳格なアンチスパム＋ゴミ収集の設定がされているはずです。あなたのシステムのXMLレポートを分析した人々からフィードバックや質問を受け取ることができるはずです。
他の設定はスクリーンショットのままにしておいてください。

DMARCの設定 – 検証プロファイル

以下のスクリーンショットのように、2つのプロファイルを正確に設定する。

メールフローポリシー

ここでの変更により、前の2つのセクションの設定が機能するようになる。以下は3つのステップである：

デフォルトの更新
デフォルトを受け入れるようにインバウンドポリシーを更新する
Outbound/Relay ポリシーをデフォルトを上書きするように修正する。

メールフローポリシー – デフォルトの更新

Default Policy Parametersを開き、下のスクリーンショットのようなセクションを見つけて、すべての設定が一致していることを確認してください。S/MIMEは別として（これについては何もしていません）、もし何か他の設定がある場合は、そのままにしておいてください。

DKIM署名：デフォルトはOffで、システム上のHATポリシーと他のMFPのほとんどがインバウンドトラフィックに関連していると仮定しています。あなたのシステムがこの方法で動作するようにセットアップされていない場合、これらの説明の多くはおそらくあなたのためではなく、おそらく正しく動作するようにこのセットアップを変更する方法をすでに理解しているでしょう。もしそうでなければ、助けを求めてください。
DKIM Verification：プロファイルは先ほど設定したDEFAULTにします。
S/MIME: 無視
SPF検証：オンで、SPF準拠のみ。表示されている設定を使用します。
DMARC検証：Onにする。検証プロファイルDEFAULTを使用する。集約レポートを送信する。認証と実施に関連するすべてのセットアップ手順に従っていない場合は、レポートを送信しないでください。

ここで、メールフローポリシーの全体的なリスト（以下のようなもの）に戻り、以下のことを確認する必要があります。