PowerDMARC と Splunk の連携ガイド
PowerDMARC → ソリューションホーム → 連携機能 → SIEM
PowerDMARCのSplunk連携機能を利用すれば、Splunk環境内で直接、メール認証およびドメインセキュリティのデータを取り込み、監視することができます。PowerDMARC APIを活用することで、組織は複雑な設定を必要とせずに、効率的なSIEM連携を構築できます。接続して実行するだけで、すべてのドメインにわたるメールセキュリティの状況を一元的に把握できるようになります。
このガイドでは、セットアップとデータ取り込みに焦点を当てています。Splunkのダッシュボードや高度な可視化機能については、本ガイドの対象外です。
APIドキュメント
Swagger ドキュメント: https://app.powerdmarc.com/swagger-ui/index.html
代替ドキュメント: https://api.powerdmarc.com/
注： 命名規則（インデックス名、ソースタイプ、ファイルパス）はあくまで推奨事項であり、必須要件ではありません。ご利用の環境の基準に合わせて調整してください。
スクリプトが収集する情報
この統合スクリプトは、PowerDMARC API から 2 つのデータセットを取得します：
アカウント内のすべてのドメインについて、 準拠している、 失敗した、および 転送済み ステータス。ドメインは /api/v1/domainsを介して自動的に列挙されます。を介して自動的に列挙されます。
アーキテクチャ概要
PowerDMARC API
↓
Pythonスクリプト（cron／systemdタイマー／タスクスケジューラによるスケジュール実行）
↓
Splunk HTTP イベントコレクター (HEC)
↓
Splunk（検索、ダッシュボード、アラート、相関分析）
SplunkはHTTPイベントコレクター（HEC）エンドポイントを通じてデータを受信し、外部ソースからの安全なデータ取り込みを可能にします。
また、このスクリプトでは、Splunk HEC ポートへの HTTPS アウトバウンド通信が許可されていない環境において、HEC の代わりに、あるいは HEC に加えて、改行区切りの JSON ファイルへの書き込みもサポートしています。詳しくは 代替手段：ファイルモニターによる取り込みを参照してください。
前提条件
管理権限を持つ Splunk Enterprise または Splunk Cloud
HECトークンの作成、インデックスの作成、およびデータ入力の設定を行う権限
スクリプトを実行するシステム上で、Python 3.7 以降がインストールされていること
監査ログおよび集計レポートへのアクセス権限を持つPowerDMARC APIベアラートークン
スクリプトホストから以下の宛先へのネットワーク接続：
PowerDMARC API — https://app.powerdmarc.com (TCP 443)
Splunk HEC エンドポイント（Splunk Enterprise の場合は TCP 8088、Splunk Cloud の場合は TCP 443）
Splunk設定
ステップ1: 専用インデックスを作成する
設定に移動 設定 → インデックス
クリック 新しいインデックス
設定:
インデックス名: powerdmarc
インデックスデータ型: イベント
アプリ： 検索 （またはお好みのアプリ）
その他の設定はデフォルトのままにするか、データ保持要件に合わせて調整してください
クリック 保存
ステップ2: HTTPイベントコレクター(HEC)を有効にする
設定に移動 設定 → データ入力
クリック HTTPイベントコレクター
クリック グローバル設定
設定:
すべてのトークン: 有効
SSLを有効にする: 有効 (推奨)
HTTPポート番号： 8088 (デフォルト)
クリック 保存
Splunk Cloud のお客様へ：HEC はデフォルトで有効になっており、ポート 443 でリスニングしています。グローバル設定を変更する必要はありませんが、一部のスタックタイプでは、HEC を有効にするためにサポートリクエストを提出する必要がある場合があります。
ステップ3：HECトークンの作成
まだ 「設定」→「データ入力」→「HTTPイベントコレクター」で、 「新しいトークン」をクリックします
トークン設定を構成する：
名前: PowerDMARC_Integration
ソース名の上書き: powerdmarc:api
説明： PowerDMARCの監査ログおよび集計レポートの取り込み用トークン
クリック 次へ
入力設定：
ソースタイプ: 選択 自動
許可されているインデックス： include powerdmarc
デフォルトインデックス: powerdmarc
クリック 「レビュー」をクリックし、次に 「送信」
重要： トークンの値を直ちにコピーして保存してください。後で取得することはできません。
「自動」が重要な理由： このスクリプトは、イベントごとにソースタイプ（dmarc:audit または dmarc:aggregate）を設定します。トークンで固定のソースタイプを選択すると、これらの値が上書きされ、両方のデータセットが1つのソースタイプに統合されます。）を設定します。トークンで固定のソースタイプを選択すると、これらの値が上書きされ、両方のデータセットが1つのソースタイプに統合されてしまいます。
統合スクリプト設定
ステップ4: Python環境の準備
このスクリプトには、サードパーティ製の依存関係が1つあります： requests。
オプション A — オンラインインストール（推奨）
pip3 install requests
オプション B — オフラインインストール
インターネットに接続できるマシンで：
pip3 download requests -d ./packages
以下の パッケージ フォルダをターゲットシステムに転送し、次に：
pip3 install --no-index --find-links=./packages requests
インストールを確認してください：
python3 -c "import requests; print(requests.__version__)"
比較的新しいバージョン（2.25以降）であればどれでも構いません。
ステップ 5: スクリプトのデプロイ
root 権限で統合を実行するのではなく、専用のサービスアカウントとディレクトリ構造を作成してください：
sudo useradd -r -s /usr/sbin/nologin dmarc
sudo mkdir -p /opt/dmarc /etc/dmarc /var/lib/dmarc /var/log/dmarc
sudo chown dmarc:dmarc /var/lib/dmarc /var/log/dmarc
sudo chmod 750 /var/lib/dmarc /var/log/dmarc
コピー dmarc_to_splunk.py を以下の場所にコピーします：
sudo install -o dmarc -g dmarc -m 750 dmarc_to_splunk.py /opt/dmarc/
ステップ6: スクリプトの設定
各設定は、 config main() main()内で編集するか、環境変数を設定することで指定できます。 内のconfig辞書を編集するか、環境変数を設定することで指定できます。 環境変数を使用することを強く推奨します 。これにより、認証情報がスクリプトファイル内に保存されることがなくなります。
HECエンドポイントURLの形式：
Splunk Enterprise / オンプレミス版： https://your-splunk-instance:8088/services/collector/event
Splunk Cloud: https://http-inputs-<your-stack>.splunkcloud.com/services/collector/event
Splunk Cloud hostnames vary by stack age and type — some use http-inputs-<stack>.splunkcloud.com on port 443, others use a .splunkcloud.com:8088 form. Confirm yours under Settings → Data inputs → HTTP Event Collector in your Splunk Cloud console rather than assuming.
認証情報ファイルを作成します：
sudo tee /etc/dmarc/splunk.env >/dev/null <<'EOF'
DMARC_API_KEY=your_powerdmarc_bearer_token
SPLUNK_HEC_URL=https://your-splunk-instance:8088/services/collector/event
SPLUNK_HEC_TOKEN=your_hec_token
SPLUNK_INDEX=powerdmarc
DMARC_DAYS_TO_FETCH=7
EOF
sudo chown root:dmarc /etc/dmarc/splunk.env
sudo chmod 640 /etc/dmarc/splunk.env
手順 7：接続の確認
このスクリプトは --test フラグを受け付け、HECに1つのプローブイベントを送信して終了します。これにより、完全な収集実行を待たずに、トークン、URL、TLSチェーン、およびファイアウォールパスの検証を行うことができます：
sudo -u dmarc bash -c 'set -a; . /etc/dmarc/splunk.env; set +a; python3 /opt/dmarc/dmarc_to_splunk.py --test'
期待される出力：
============================================================
PowerDMARCとSplunkの連携
出力モード：hec
============================================================
Splunk HEC への接続テスト中...
1件の dmarc:audit イベントのバッチを送信しました (1/1)
dmarc:audit に関する HEC の概要 — 送信済み: 1、失敗: 0、合計: 1
プローブが到着したことを確認してください：
index=powerdmarc action="integration_connectivity_test"
ステップ 8: 完全収集を実行する
sudo -u dmarc bash -c 'set -a; . /etc/dmarc/splunk.env; set +a; python3 /opt/dmarc/dmarc_to_splunk.py'
期待される出力（要約）：
============================================================
PowerDMARCとSplunkの連携
出力モード：hec
============================================================
DMARCの集計レポートを処理中...
2026年1月30日から2026年2月6日までの集計レポートを取得中
すべてのドメインを取得中...
1ページ目を取得：24ドメイン（これまでの合計：24）
合計24件のドメインを取得しました
進捗：1.4% (1/72) | ドメイン 1/24：example.com | 残り時間：4.7分
...
318件の固有の集計レポートイベントを処理しました
318件のdmarc:aggregateイベントを送信しました（318/318）
dmarc:aggregate の HEC サマリー — 送信数: 318、失敗数: 0、合計: 318
監査ログを処理中...
2026年1月30日から2026年2月6日までの監査ログを取得する
監査ログのエントリを合計15件取得しました
過去7日間の監査ログイベントのうち、15件の異なるイベントを処理しました
dmarc:audit の HEC サマリー — 送信済み: 15、失敗: 0、合計: 15
============================================================
統合が正常に完了しました
============================================================
最初の実行は、ルックバックウィンドウ全体を収集するため、最も時間がかかります。それ以降の実行では、すでに取り込まれたデータはスキップされます（参照： 重複排除を参照）
自動実行のスケジュール設定
Linux/Unix (cron)
sudo crontab -u dmarc -e
1時間ごと：
0 * * * * set -a; . /etc/dmarc/splunk.env; set +a; /usr/bin/python3 /opt/dmarc/dmarc_to_splunk.py >> /var/log/dmarc/run.log 2>&1
このスクリプトは標準出力にログを出力するため、上記のリダイレクトによって実行ログが取得されます。 logrotate ルールを /var/log/dmarc/run.log に対してlogrotateルールを追加してください。
間隔の設定。 このスクリプトは、PowerDMARCのレート制限内に収まるよう、API呼び出し間隔を約2秒に設定しており、ドメインごとに合計3回のリクエストを実行します。データ収集にかかる合計時間の概算は、 ドメイン数 × 3 × 4秒 となります。25ドメインの場合は約5分ですが、500ドメインの場合は2時間近くかかります。アカウントに100ドメイン以上がある場合、1時間ごとのスケジュールでは処理が重複してしまいます。以下のいずれかの方法を選択してください：
スケジュールを分割する――監査ログの収集は1時間ごとに実行し、集計は1日1回行う、あるいは
ロックファイル（flock) を追加し、実行が重複した場合でも正常に終了するようにします：
0 * * * * /usr/bin/flock -n /tmp/dmarc-splunk.lock -c 'set -a; . /etc/dmarc/splunk.env; set +a; /usr/bin/python3 /opt/dmarc/dmarc_to_splunk.py' >> /var/log/dmarc/run.log 2>&1
Linux（systemd タイマー）
このワークロードでは、一般的にcronよりもsystemdのタイマーの方が適しています。systemdのタイマーは環境設定ファイルをネイティブに処理し、実行の重複を防ぎ、出力をジャーナルに記録するからです。
/etc/systemd/system/dmarc-splunk.service:
[単位]
説明=PowerDMARCからSplunkへのデータ取り込み
After=network-online.target
[サービス]
Type=oneshot
ユーザー=dmarc
グループ=dmarc
EnvironmentFile=/etc/dmarc/splunk.env
ExecStart=/usr/bin/python3 /opt/dmarc/dmarc_to_splunk.py
/etc/systemd/system/dmarc-splunk.timer:
[単位]
説明=PowerDMARCからSplunkへのデータ取り込みを1時間ごとに実行する
[タイマー]
OnCalendar=hourly
Persistent=true
[インストール]
WantedBy=timers.target
有効にするには：
sudo systemctl daemon-reload
sudo systemctl 有効化 --now dmarc-splunk.timer
sudo systemctl list-timers dmarc-splunk.timer
journalctl -u dmarc-splunk.service -f
Windows（タスク スケジューラ）
開く 「タスク スケジューラ」を開き を開き、 「タスクの作成」をクリックします
[全般] タブ：
名前: PowerDMARC Splunk 統合
セキュリティオプション: ユーザーがログオンしているかどうかにかかわらず実行する
[トリガー] タブ： 新規 → 開始：スケジュールに従って → 毎日、1時間ごとに繰り返し
[アクション] タブ： 新規 → プログラムの起動
プログラム： python.exe
引数： C:\dmarc\dmarc_to_splunk.py
クリック OK
Windows では、 config ディクショナリに直接設定するか、マシンレベルで環境変数を定義し、 output_dir / state_fileを、Windows 形式のパスに変更してください。 を、次のような Windows パスに変更してください。 C:\dmarc\logs や C:\dmarc\state\state.jsonといったWindowsパスに変換します。
Splunkにおけるデータ取り込みの検証
監査ログ
index=powerdmarc sourcetype=dmarc:audit
| sort - _time
| ヘッダー 20
| テーブル _time, user_name, action, ip_address, admin_username
表示されるはずのフィールド：
ユーザー名 — 操作を実行したユーザー
アクション — 実行されたアクションの説明
ip_address — ユーザーのIPアドレス
admin_username — 該当する場合の管理者アカウント
タイムスタンプ — PowerDMARCのイベント発生時刻（オリジナル）
集計レポート
index=powerdmarc sourcetype=dmarc:aggregate
| stats sum(email_volume) as volume, avg(dmarc_pass_percentage) as avg_pass by domain_name
| 並べ替え - 音量
集計イベントには、DMARC、SPF、DKIMについて、ドメインごと、送信元ごとの件数と割合に加え、実際に適用されたポリシーが含まれます。
イベント構造の例
dmarc:audit
{
「sourcetype」: "dmarc:audit",
「タイムスタンプ」: "2026-02-04 14:29:24",
"user_name": "John Doe",
「アクション」: "添付ドメインを更新しました",
"ip_address": "12.111.67.123",
"admin_username": "N/A",
"other_info": "該当なし"
}
dmarc:aggregate （略称）
{
「sourcetype」: "dmarc:aggregate",
「タイムスタンプ」: "2026-02-06",
"report_date_from": "2026-01-30",
"report_date_to": "2026-02-06",
"domain_id": 1234,
"domain_name": "example.com",
"sending_source": "Google",
「ステータス」: "準拠",
"email_volume": 4821,
"dmarc_pass_count": 4810,
"dmarc_pass_percentage": 99.77,
"spf_align_percentage": 99.77,
"dkim_align_percentage": 100.0
}
イベントのタイムスタンプ
このスクリプトはHECを設定します time フィールドを、解析可能な場合は各イベント自身のタイムスタンプから設定するため、 _time は、イベントが取り込まれた時刻ではなく、発生した時刻を反映します。これは初回実行時に重要です。これを行わないと、7日分のバックフィルがすべて現在の分内に収まってしまい、すべての時系列パネルで不自然な表示になってしまいます。
重複排除
このスクリプトは状態ファイルを管理します（デフォルトは /var/lib/dmarc/state.json）を管理し、そこにすでに配信済みのすべてのイベントの SHA-256 フィンガープリントを格納します。スクリプトの実行ごとに、保存されているフィンガープリントと一致するイベントはスキップされます。ファイルが無限に肥大化しないよう、14 日以上経過したフィンガープリントは自動的に削除されます。
フィンガープリントは、 配信が 成功した後にのみコミットされるため、HEC POSTが失敗した場合、それらのイベントは黙って破棄されるのではなく、次回の実行時に再試行の対象となります。
これによる2つの運用上の影響：
状態ファイルは、実行や再起動を経ても保持される必要があります。 /tmp や、破棄されるコンテナレイヤー内には配置しないでください。
ステートファイルを削除すると、次回の実行時にルックバックウィンドウ全体が再取り込みされます。これはバックフィルを強制する正しい方法ですが、データがすでにSplunkに存在している場合は、重複が発生する可能性があります。
別名：ファイルモニターの取り込み
HECポートへの送信アクセスが利用できない場合は、次のように設定してください。 DMARC_OUTPUT_MODE=file （または 両方）に設定してください。スクリプトは、改行区切りのJSONを output_dirに改行区切りのJSONを書き込みます。データセットごとに1回の実行につき1ファイルとなります：
/var/log/dmarc/dmarc_aggregate_20260206_140312.json
/var/log/dmarc/audit_logs_20260206_140312.json
そのディレクトリを監視するように、Splunk フォワーダーを設定します。 $SPLUNK_HOME/etc/system/local/inputs.conf:
[monitor:///var/log/dmarc/dmarc_aggregate_*.json]
disabled = false
index = powerdmarc
sourcetype = dmarc:aggregate
[monitor:///var/log/dmarc/audit_logs_*.json]
disabled = false
index = powerdmarc
sourcetype = dmarc:audit
また、 props.confに、イベントが1行ごとに分割され、タイムスタンプが正しく付くように設定します：
[dmarc:aggregate]
INDEXED_EXTRACTIONS = json
KV_MODE = none
SHOULD_LINEMERGE = false
TIME_PREFIX = "report_date_to":\s*"
TIME_FORMAT = %Y-%m-%d
[dmarc:audit]
INDEXED_EXTRACTIONS = json
KV_MODE = none
SHOULD_LINEMERGE = false
TIME_PREFIX = "timestamp":\s*"
TIME_FORMAT = %Y-%m-%d %H:%M:%S
Splunk ユーザーには、そのディレクトリへの読み取りアクセス権が必要です。これを dmarc グループに追加するか、ディレクトリのモードを 0755に変更してください。に変更してください。クリーンアップジョブ（find /var/log/dmarc -name '*.json' -mtime +7 -delete）を追加し、古い出力ファイルが蓄積しないようにします。
トラブルシューティング
Splunkにデータが表示されない
以下を実行してください --test オプションを付けて実行し、問題がHEC側にあるのか、それともPowerDMARC側にあるのかを特定してください
HECトークンが正しいことを確認し、 有効になっていることを確認してください （設定 → データ入力 → HTTPイベントコレクター）
トークンで許可されているインデックスに以下が含まれていることを確認してください powerdmarc
インデックスが存在すること、および自分のロールがそのインデックスを検索する権限を持っていることを確認してください
スクリプトホストからHECエンドポイントへのHTTPSによるアウトバウンド通信が、ファイアウォールルールで許可されていることを確認してください
以下の実行ログを確認してください HECがHTTPを返した… 行 — Splunkのエラー本文に具体的な問題名が記載されています
HECからHTTP 403「無効なトークン」というエラーが発生しました
The token value is wrong, disabled, or belongs to a different Splunk stack. Note that the header format is Authorization: Splunk <token> — not Bearer.
HTTP 400「インデックスが不正です」
このトークンでは、スクリプトが対象としているインデックスが許可されていません。次のいずれかを追加してください。 powerdmarc をトークンの許可インデックスリストに追加するか、 SPLUNK_INDEX を、トークンがすでに許可しているインデックスに変更してください。
SSL証明書のエラー
スクリプトのホストで信頼される証明書をインストールしてください。これが正しい解決策です。本番環境以外での一時的な対策としてのみ、次のように設定してください。 SPLUNK_VERIFY_SSL=falseに設定してください。本番環境では絶対にこの設定を行わないでください。これにより、TLS 経由の HEC の意義を支える保護機能が無効になってしまいます。
PowerDMARC API の認証エラー
APIトークンが有効であり、有効期限が切れていないことを確認してください
トークンが監査ログと集計レポートの両方に対する権限を持っていることを確認してください
ホストからAPIのベースURLにアクセスできることを確認してください
スクリプトは実行されたが、ログが取得されなかった
対象期間について、監査ログが実際に存在するかどうかを確認する
増加 DMARC_DAYS_TO_FETCH を一時的に増やす
重複排除処理により、以前に取り込まれたイベント（実行レポートなど）が除外されることにご留意ください。 「0件のユニークな監査ログイベントが処理されました」 というメッセージが表示されるのは正常な動作であり、障害ではありません
起動時にアクセスが拒否されました
サービスアカウントは、以下のパスへの作成や書き込みを行うことができません /var/lib/dmarc または /var/log/dmarcを作成または書き込みできません。両方のディレクトリを事前に作成し、 chown スクリプトが実行されるアカウントに所有権を設定してください（手順5を参照）。
実行に、スケジュールされた間隔よりも長い時間がかかっている
以下の「サイズに関する注意事項」をご覧ください 自動実行のスケジュール設定の下にあるサイズに関する注意事項をご確認ください。 flock を使用するか、収集スケジュールを分割してください。
次のステップ
データが流れれば、次のようなことが可能になります：
ドメインおよび送信元ごとのDMARCコンプライアンスの傾向を把握するためのカスタムダッシュボードを作成する
ポリシーの変更や予期しないIP範囲からのログインなど、監査イベントに関するアラート
コンプライアンスの悪化に関するアラート — 以下の送信元について dmarc_pass_percentage が前週比で急激に低下している送信元
PowerDMARCのデータを、他のセキュリティログ（メールゲートウェイ、ID管理、EDR）と関連付ける
集計データセットからコンプライアンスおよび経営層向け報告を作成する
推奨される機能強化
追加のAPIエンドポイント： スクリプトを拡張して、フォレンジックレポートやドメインごとの設定データを取得できるようにする
ログのローテーション： 以下の logrotate ルールを追加する
障害通知： スクリプトを、終了ステータスが0以外の場合にアラートを発する呼び出しで囲むか、予想される1時間あたりのイベント数が確認できない場合にSplunkでアラートを発するように設定してください
Splunk TA としてパッケージ化： インプット、プロパティ、およびインデックス時の設定をテクノロジー・アドオンとしてバンドルし、配布を容易にする
シークレット管理： 利用可能な場合は、環境設定ファイルをシークレット管理ツール（Vault、AWS Secrets Manager、systemd credentials）に置き換えてください
セキュリティ上の考慮事項
認証情報をスクリプトの外に保存してください。 環境ファイルを使用してください（モード 640、所有者 root:dmarc）またはシークレットマネージャーを使用してください。トークンをバージョン管理システムにコミットしてはいけません。）またはシークレットマネージャーを使用してください。トークンをバージョン管理システムにコミットしてはいけません。
TLS 検証を有効にしたままにしてください。 SPLUNK_VERIFY_SSL のデフォルト値は true に設定されているのには理由があります。
特権のない専用アカウントとして実行します。 この統合にはroot権限は必要ありません。
HECトークンを制限する。 これを powerdmarc インデックスのみに制限します。
両方のトークンをスケジュールに従ってローテーションする — PowerDMARCのベアラー・トークンとSplunk HECトークンです。
実行状況を監視する。 実行の失敗や、データ取り込みにおける予期せぬ中断が発生した際にアラートを発行する。
Splunkのアクセス制御を確認してください。 監査ログデータにはユーザーと送信元IPアドレスが記録されています。インデックスへのアクセス権限を、それを必要とするロールに限定してください。
サポートとリソース
PowerDMARC API ドキュメント：https://api.powerdmarc.com/
Splunk HEC のドキュメント：https://docs.splunk.com/Documentation/Splunk/latest/Data/UsetheHTTPEventCollector
Splunk Answers：https://community.splunk.com/