## parsedmarc とは｜OSS で DMARC レポートを解析する選択肢

DMARC（ディーマーク）の rua レポートは、各メール受信事業者から XML 形式で日々送られてきます。これを人間が読むのは現実的ではないため、通常は dmarcian や Valimail などの SaaS で集計します。一方、自社で機密性の高いレポートを外部 SaaS に渡したくない、もしくはランニングコストを抑えたい場合、OSS の [parsedmarc](https://github.com/domainaware/parsedmarc) を自前ホストするという選択肢があります。

parsedmarc は Python で書かれた DMARC / SMTP TLS / MTA-STS レポート解析ツールで、IMAP からレポートメールを自動取得し、Elasticsearch や Splunk、PostgreSQL などへ投入できます。Grafana や Kibana で可視化するダッシュボードのテンプレートも公式に配布されています。

DMARC レポート自体の読み方の基礎は [DMARC レポートの読み方](/blog/dmarc-report-reading) を参照してください。

## 構成図｜parsedmarc + Elasticsearch + Grafana

実運用で多く採用されている構成は以下です。

![parsedmarc + Elasticsearch + Grafana 構成図](/blog/parsedmarc-self-host/architecture.svg)

- **メール受信箱（IMAP）**: DMARC rua の送付先メールアドレス（例: `dmarc-rua@example.com`）に届くレポートメールを保管
- **parsedmarc コンテナ**: IMAP から定期取得 → XML 解析 → Elasticsearch へ書き込み
- **Elasticsearch**: 解析済みレコードを蓄積（Index は `dmarc_aggregate`、`dmarc_forensic` など）
- **Grafana / Kibana**: 蓄積データを可視化（送信元 IP 別、ポリシー結果別、SPF/DKIM 整合性別の集計）

VPS 1 台（4 GB RAM 以上推奨）に Docker Compose で全て同居させる構成が、中小規模では運用負荷とコストのバランスが取りやすいです。

## インストール手順｜pip と Docker の 2 通り

### pip インストール

Python 3.9 以上の環境で、以下のように導入できます。

```bash
pip install parsedmarc[geoip,elasticsearch]
```

設定ファイル `parsedmarc.ini` に IMAP 接続情報と Elasticsearch のエンドポイントを記述し、systemd タイマーで定期実行します。

```ini
[general]
save_aggregate = True
save_forensic = True

[imap]
host = imap.example.com
user = dmarc-rua@example.com
password = <APP_PASSWORD>
watch = True

[elasticsearch]
hosts = http://localhost:9200
```

### Docker Compose

公式が配布する docker-compose.yml をベースに、parsedmarc / Elasticsearch / Kibana の 3 サービスをまとめて立ち上げる方法が最短です。`watch = True` にすれば IMAP IDLE で新着メールを即時取り込みできます。

詳細な設定オプションは公式リポジトリの README を確認してください。Gmail を IMAP 元にする場合はアプリパスワードが必要です。

## SaaS との比較｜どこに線を引くか

自前構築と SaaS（dmarcian、Valimail、URIports 等）には、それぞれ得意領域があります。

![自前構築とSaaSの比較](/blog/parsedmarc-self-host/saas-vs-self.svg)

### 自前構築のメリット

- **ランニングコスト**: VPS 代のみ（月額 1,000円〜3,000円）。送信ボリューム課金がない
- **データ主権**: rua レポートに含まれる送信元 IP やドメイン情報を外部に渡さずに済む
- **柔軟性**: 集計クエリやアラートを自社要件に合わせて自由に実装できる

### 自前構築のデメリット

- **必要スキル**: Python / Docker / Elasticsearch / IMAP の運用知識が前提
- **アラートやレビュー機能は自作**: SaaS のような「DKIM 失敗の急増を Slack に通知」を作るには手間がかかる
- **DNS テンプレートやウィザードがない**: SPF / DKIM の修正提案は自分で考える必要がある

SaaS 各社の特徴比較は [DMARC レポートツール比較](/blog/dmarc-report-tool-comparison) にまとめています。

### 自前構築が向いているケース

- 自社にインフラエンジニアがいて、Docker / Elasticsearch の運用経験がある
- DMARC rua の送信ボリュームが多く（月数十万通以上）、SaaS の従量課金が高くつく
- レポートに含まれる情報を社外に出したくない（金融、医療、公共セクター等）

逆に、上記に当てはまらない中小企業の多くでは、無料枠のある SaaS から始める方が運用負荷が低くて済みます。「DMARC rua が届かない」状態で困っている場合は [DMARC rua レポートが届かない原因](/blog/dmarc-rua-not-receiving) も参照してください。

## 運用上の注意点｜rua の暗号化と保管期間

DMARC rua レポートには、自社ドメインを偽装しているフィッシング送信元の IP アドレスや、ESP（メール送信事業者）が利用している正規の送信 IP が含まれます。これらは攻撃の手がかりになる一方、第三者に渡るとブランドの脆弱性として悪用される可能性もあります。

- **転送中の暗号化**: rua の送信は SMTP の TLS が前提。受信メールサーバの STARTTLS 設定を確認
- **保管時の暗号化**: Elasticsearch を直接インターネットに晒さない。VPN / SSH トンネル経由でのみアクセスを許可
- **保管期間**: 公式推奨は 12 ヶ月。Elasticsearch の ILM（Index Lifecycle Management）で古い Index を自動削除する運用が現実的
- **バックアップ**: 月次のスナップショットを別リージョンの S3 互換ストレージに保管

これらの観点を満たせない場合、無理に自前構築せず SaaS 利用に倒した方が結果的にリスクが低くなります。

## 自社の状況を確認してみませんか

設定状況がわからない方は、無料の[ドメイン診断](/diagnose)で現状をチェックできます。
DMARC・SPF・DKIM・SSL の状態が数十秒でレポートされます。
判断に迷う場合は[お問い合わせ](/contact)からご相談ください。専門家がわかりやすくサポートいたします。