Salesforce - Fix SPF
Cloudflare DNSAI DMARC Agentでできること
修正案を代わりに作成
エージェントがDMARCレポートのデータを分析し、優先度付きの対応チケットを作成します：送信元の確認、SPF・DKIMのアライメントの問題、ポリシーの不備、ポリシー強化の節目。
最終判断は自社で
すべての変更は反映前に確認されます。レコードの正確な差分を見て承認し、Hosted DNSならDNSプロバイダーはそのままでPalisadeから反映できます。
ドメインに合ったポリシー強化
より強いDMARCポリシーを承認する前に、正規の送信元と実際の送信経路を確認します。適切なポリシーはドメインの使い方次第で、すべてのドメインがp=rejectを目指すべきとは限りません。
世界の主要ブランドが導入
生のレポートから修正の反映まで
エージェントが全工程を担い、各ステップを承認するだけ。
レポート受信
PalisadeがドメインのDMARC集計レポートを収集し、すべての送信元を特定します。XMLの解読もスプレッドシートも不要です。
チケット作成
エージェントが問題ごとに、タイトル、重要度、スコアへの影響、推奨の対応を含むチケットを作成。優先順位も付いています。
修正案を確認
各チケットで、何が変わるかをレコードの差分まで正確に表示。正規の送信元を確認し、変更を承認します。
反映と検証
Hosted DNSなら、承認した変更をCNAME委任でPalisadeから反映します。外部DNSなら、64社のプロバイダーで承認したレコードを自社ゾーンへ公開するか、追加すべき正確なレコードを渡します。
エージェントの対応チケットの仕組み
送信元の検出
エージェントは実際のレポートから送信元を検出します。保留中の送信元を確認し、正規のものを承認して、残りは破棄します。
重要度とスコアへの影響
すべてのチケットに重要度と、完了で上がるスコアを表示。キューは最初から重要な順に並びます。
問題別のチケット
送信元の承認、SPFやDKIMの失敗、DNSの不具合、SPFのルックアップ上限、レコード設定、ポリシーの準備状況。それぞれに専用の対応手順があります。
プロバイダー別の手順
送信サービスを認識すると、汎用の認証チェックリストではなく、そのプロバイダーに合った設定手順をチケットに含めます。
公式ドキュメントの読み解き
エージェントはプロバイダーの公式ドキュメントを読み、該当するSPFやDKIMの設定手順を抽出し、各ステップを原文と照合します。生成した手順は、顧客に表示する前に人が確認します。
根拠と正確な変更内容
対象の送信元やホスト名、指摘の根拠、Palisadeがその対応を推奨する理由を表示します。DNSを変える修正なら、承認前にレコードの正確な変更をプレビューできます。
段階的な強化
ポリシーの準備状況を確認し、変更を1つずつ承認します。p=rejectを全ドメイン共通の目標とせず、転送やメーリングリストの利用を含め、ドメインの送信状況に合わせてポリシーを選びます。
検証待ち
変更後、チケットにはPalisadeが結果を監視中であることが表示されます。解決すれば自動で完了し、問題が残っていれば監視がチケットを再オープンします。
スヌーズ・却下・完了
修正に時間が必要ならスヌーズし、該当しない指摘は却下できます。完了・却下したチケットはステータスで絞り込んで確認できます。
DNSの可視化と履歴
Palisadeが現在見ている認証レコードと、何がいつ変わったかの定期スナップショットを確認できます。
新規チケットの通知
エージェントがチケットを作成するとチームに通知。レポートを見張らなくても、次の問題を見逃しません。
未使用の送信元の確認
確認済みの送信元が丸1年送信していない場合、エージェントは根拠と、まだその送信元を許可しているレコードを添えて、優先度の低いチケットを作成します。送信元を残すか、DNSプロバイダーでレコードを削除するかを選びます。
一元管理
チケット、スコア、ポリシー、送信量をドメインごとに集計。管理する全ドメインを横断して優先順位を付けられます。
AIアシスタントからも操作
Claude、CopilotなどのMCPクライアントをPalisadeのMCPサーバーに接続できます。アシスタントからエージェントのチケットを一覧し、根拠と推奨の修正を開き、変更が有効になったら完了にできます。ChatGPTは読み取り専用で、監視・診断用です。
AI DMARC AgentのFAQ
Palisade DMARC Agentとは
DMARC Agentは、ドメインのDMARC集計レポートのデータを分析し、優先度付きの検出・対応チケットを作成します。各チケットにはタイトル、説明、重要度、スコアへの影響、推奨の修正が含まれます。レポートが生のXMLではなく、ToDoリストとして届きます。
エージェントはDNSレコードを自動で変更しますか？
いいえ。エージェントが修正案を作成し、反映前にお客様が確認します。Hosted DNSなら、承認した変更をCNAME委任でPalisadeから反映し、DNSプロバイダーはそのままです。外部DNSなら、承認後にPalisadeが自社ゾーンへレコードを公開するか、追加すべき正確なレコードを渡します。
どんな問題でチケットを作成しますか？
確認が必要な新規・不明の送信元、SPFとDKIMの認証やアライメントの失敗、メール関連DNSレコードの欠落・ずれ・競合、SPFの整理とルックアップ上限の問題、DMARCポリシーの不備、パークドメインの保護、ポリシー強化の節目です。各チケットは、汎用のチェックリストではなく、問題に合った対応手順を使います。
推奨の変更をした後はどうなりますか？
チケットは検証待ちになり、Palisadeが結果を監視します。SPF、DKIM、DNSの問題が解決すれば、チケットは自動で完了します。問題が残っていれば監視がチケットを再オープンするので、変更を送っただけで未解決の作業が隠れることはありません。
プロバイダーの公式ドキュメントを使いますか？
はい。対応する送信サービスについては、エージェントがプロバイダーの公式ドキュメントを読み、該当するSPFやDKIMの設定手順を抽出し、生成した手順を原文と照合します。手順は、対応チケットに表示される前に人が確認します。
無料のDMARCチェックとの違いは？
チェックツールは公開レコードを一度確認するだけです。エージェントは実際のDMARCレポートを継続的に監視し、誰がドメインで送信しているかを特定して、修正案付きの優先度付き作業に変えます。
全ドメインをp=rejectにすべき？
いいえ。DMARCポリシーは、ドメインの用途と正規の送信経路次第です。RFC 9989の7.4節は、メーリングリストなどの間接配信で認証が壊れることがあるため、汎用のメールドメインにp=rejectを推奨していません。ポリシー強化を承認する前に、それらの経路を確認してください。Palisadeは承認された設定を準備・適用し、メッセージの扱いは受信側のメールシステムが決めます。
社内IT部門はエージェントをどう評価すべき？
まず、自社で管理するドメインと、文書化された送信元の一覧から始めます。各チケットが対象の送信元を特定し、根拠を説明し、確認者が実行できる変更を示すかを評価します。承認の担当者、使うDNS反映の方法、検証で問題が解決するか再オープンされるかを記録します。技術者の工数は自社の観察で比較してください。レポートの量だけでは、削減した時間は証明できません。
DNSホスティングをPalisadeに移す必要は？
いいえ。ホスト型DMARCは、DNSプロバイダーをそのままに、認証レコードをCNAMEで委任します。外部DNSにレコードを置く場合は、対応する反映用の接続を使うか、用意したレコードを自分で公開します。反映の方法を選ぶ前に、DNSの権限と変更の担当者を確認してください。
ClaudeなどのAIアシスタントからチケットを処理できますか？
はい。PalisadeのMCPサーバーで、MCPクライアントは42のツールを使えます。エージェントのチケットの一覧、根拠と推奨の修正の確認、変更が有効になった後の完了ができます。ChatGPTは読み取り専用で、監視・診断用です。外部DNSプロバイダーにレコードを書き込むMCPツールはなく、承認後の公開はPalisadeのアプリで行います。
多数のドメインに対応できますか？
はい。ドメインを個別またはCSVで一括追加し、グループに整理して、チケット数、スコア、ポリシー、報告された送信量でポートフォリオ全体の優先順位を付けられます。