email-audit

メール監査サブスキル

目的

ドメインのメール到達性を包括的に監査します。DNS 認証レコード（SPF、DKIM、DMARC）、インフラストラクチャ（MX、PTR、TLS）、レピュテーション（ブラックリスト）、一斉送信者のコンプライアンスを確認します。優先順位付きの修正項目とともに、健全性スコア（0～100）を生成します。

入力

• ドメイン名：例：rankenstein.cloud、example.com
• 任意：メールの送信量（1 日あたり 5,000 通以上の場合、一斉送信者のコンプライアンスチェックを実行します）

監査カテゴリ

1. SPF レコード（重み：10%）

確認項目：

• TXT <domain> に SPF レコードが存在する
• 構文が正しい：v=spf1 で始まる
• DNS ルックアップ数（最大 10、8 以上で警告）
• 適用レベル：-all（合格）、~all（ソフトフェイル）、?all（中立）、+all（不合格）
• SPF レコードが複数存在しない（検証エラーの原因になります）
• include が効率的かつ必要である

コマンド：

dig txt <domain> +short | grep "v=spf1"
# or
python scripts/check_deliverability.py <domain> --spf

スコアリング：

• 有効 + ハードフェイル（-all）：100 点
• 有効 + ソフトフェイル（~all）：70 点
• 有効 + 中立／すべて許可：40 点
• 構文が無効、またはルックアップが 10 回以上：20 点
• 存在しない：0 点

2. DKIM レコード（重み：15%）

確認項目：

• 有効な DKIM レコードが 1 つ以上存在する
• 鍵の長さ：2048 ビット（NIST が定める最低要件）、1024 ビット（旧式。アップグレードを推奨）
• 一般的なセレクター：google、default、selector1、selector2、k1、mandrill、dkim

コマンド：

dig txt google._domainkey.<domain> +short
dig txt default._domainkey.<domain> +short
dig txt selector1._domainkey.<domain> +short
# Check common selectors

注： DKIM セレクターは、事前に把握していなければ特定できません。一般的なセレクターを確認し、メールプロバイダーで特定のセレクターを使用しているか、ユーザーに尋ねてください。

スコアリング：

• 2048 ビットの鍵が見つかった：100 点
• 1024 ビットの鍵が見つかった：70 点
• 無効／脆弱な鍵：30 点
• 存在しない：0 点

3. DMARC ポリシー（重み：15%）

確認項目：

• TXT _dmarc.<domain> に DMARC レコードが存在する
• ポリシーレベル：p=reject（非常に優れている）、p=quarantine（良好）、p=none（監視）
• 集約レポート（rua=）タグが存在する
• フォレンジックレポート（ruf=）タグが存在する（任意）
• アライメントモード：aspf=（SPF）と adkim=（DKIM）— 緩和または厳格
• 割合（pct=）は、完全適用する場合は 100 にする

コマンド：

dig txt _dmarc.<domain> +short

スコアリング：

• p=reject + rua + pct=100：100 点
• p=quarantine + rua：80 点
• p=none + rua：40 点
• レポート設定なしの p=none：20 点
• 存在しない：0 点

4. MX レコード（重み：10%）

確認項目：

• 有効な MX レコードが存在する
• MX ホストが IP アドレスに解決される
• 優先順位が適切である
• メールプロバイダーを特定する（Google Workspace、Microsoft 365、カスタム）

コマンド：

dig mx <domain> +short
dig a <mx-hostname> +short

スコアリング：

• 有効 + すべてのホストが解決される + プロバイダーが判明している：100 点
• 有効 + すべてのホストが解決される：80 点
• 有効だが、一部のホストが解決されない：40 点
• 存在しない、または無効：0 点

5. 逆引き DNS／PTR（重み：5%）

確認項目：

• MX サーバーの IP に PTR レコードが存在する
• PTR レコードが正引き DNS と一致する（ホスト名が一致する）

コマンド：

dig -x <mx-ip> +short

スコアリング：

• すべての MX IP に一致する PTR がある：100 点
• PTR の一部のみ設定されている：50 点
• PTR が存在しない：0 点

6. TLS／STARTTLS（重み：10%）

確認項目：

• MX サーバーで STARTTLS がサポートされている（ポート 25）
• TLS バージョン（1.2 以降を推奨）

コマンド：

openssl s_client -starttls smtp -connect <mx-hostname>:25 -brief

注： ネットワークアクセスが必要な場合があります。利用できない場合は「確認できません」と記載してください。

スコアリング：

• STARTTLS で TLS 1.2 以降：100 点
• STARTTLS で TLS 1.0／1.1：60 点
• STARTTLS なし：0 点

7. ブラックリストチェック（重み：20%）

確認項目：

• ドメインと MX の IP アドレスについて、主要なブラックリストを確認します：
  • Spamhaus（SBL、XBL、PBL）
  • Barracuda
  • SORBS
  • SpamCop
  • URIBL
  • Invaluement

コマンド：

# Use checkdmarc library if available
python -c "import checkdmarc; print(checkdmarc.check_domains(['<domain>']))"

# Or manual checks
dig <ip>.zen.spamhaus.org +short
dig <ip>.b.barracudacentral.org +short

スコアリング：

• すべてのリストで登録なし：100 点
• マイナーなリスト 1 件に登録：50 点
• 主要なリスト（Spamhaus、Barracuda）1 件に登録：30 点
• 主要なリスト 2 件以上に登録：0 点

重要： 主要なブラックリストに登録されると、メール到達性に深刻な影響を及ぼします。

8. 一括送信者のコンプライアンス（重み：10%）

対象： Gmail、Yahoo、Microsoft の受信者に 1 日 5,000 件以上のメールを送信するドメイン。

要件（Google／Yahoo／Microsoft の 2024～2026 年のルール）：

1. SPF と DKIM の両方がパスすること（一方だけでは不可）
2. DMARC ポリシーが最低でも p=none であり、アライメントが取れていること
3. ワンクリック登録解除ヘッダー（RFC 8058：List-Unsubscribe-Post: One-Click）
4. スパム苦情率が 0.3% 未満（目標は 0.1% 未満）
5. 正引きおよび逆引き DNS（PTR レコード）が有効であること
6. 登録解除を 2 営業日以内に反映すること
7. ヘッダーで Gmail／Yahoo／Microsoft になりすまさないこと
8. メッセージ送信に TLS 接続を使用すること

スコア：

• 8 項目すべてを満たす：100 点
• 6～7 項目を満たす：70 点
• 4～5 項目を満たす：50 点
• 4 項目未満：0 点

9. 追加チェック（重み：5%）

ボーナスポイントの対象：

• TXT default._bimi.<domain> に BIMI レコード（Brand Indicators for Message Identification）がある
• https://mta-sts.<domain>/.well-known/mta-sts.txt に MTA-STS ポリシーがある
• TXT _smtp._tls.<domain> に TLSRPT レコード（TLS レポート）がある
• Mail-from ドメインのアライメント（DKIM／SPF が From: ドメインと一致する）

コマンド：

dig txt default._bimi.<domain> +short
curl https://mta-sts.<domain>/.well-known/mta-sts.txt
dig txt _smtp._tls.<domain> +short

スコア：

• ボーナス機能 1 項目につき：+25 点（最大 100 点）

ヘルススコアの計算

計算式：

Total Score = (SPF × 0.10) + (DKIM × 0.15) + (DMARC × 0.15) + (MX × 0.10) +
              (PTR × 0.05) + (TLS × 0.10) + (Blacklists × 0.20) +
              (Bulk Compliance × 0.10) + (Extras × 0.05)

スコアの解釈：

スコア	評価	状態	対応
90-100	優秀	重要なチェック項目をすべてパスし、完全に準拠しています	定期的に監視します
75-89	良好	軽微な問題はありますが、概ね配信可能です	優先度が中程度の項目を修正します
60-74	普通	受信トレイへの振り分けに影響する可能性のある問題があります	優先度の高い項目を 1 週間以内に修正します
40-59	不良	メール配信に重大なリスクがあります	重要項目を直ちに修正します
0-39	危険	重大な問題があり、メールがスパムに振り分けられる可能性が高いです	緊急の修正が必要です

ワークフロー

ステップ 1：ドメイン情報を収集する

ユーザーに次の情報を尋ねます：

• 監査対象のドメイン名
• おおよそのメール送信量（一括送信者向けチェックの適用判定に使用）
• 既知の DKIM セレクター（一般的なものを使用していない場合）

ステップ 2：並列で処理を委任する

監査を迅速化するため、次のエージェントを並列で起動します：

エージェント 1：email-deliverability

Check DNS authentication records for <domain>:
- SPF record validation
- DKIM record discovery (selectors: google, default, selector1, selector2, k1)
- DMARC policy analysis
- MX record validation
- PTR/reverse DNS check

Return JSON with pass/fail status and raw records.

エージェント 2：email-compliance

Check bulk sender compliance for <domain>:
- Verify both SPF and DKIM pass
- Check DMARC alignment
- Note TLS support
- Check for List-Unsubscribe headers (if sample email provided)

Return compliance checklist with met/not met status.

エージェント 3：email-reputation（ツールが利用可能な場合）

Check reputation for <domain>:
- Blacklist status (Spamhaus, Barracuda, SORBS, SpamCop)
- Historical deliverability issues
- Spam complaint rate (if available)

Return list of blacklist hits and reputation score.

ステップ 3：結果を集約する

すべてのエージェントから結果を収集し、重み付けしたヘルススコアを計算します。

ステップ 4：優先順位を付けた修正リストを作成する

問題を優先度別に分類します：

重要（直ちに修正）：

• ブラックリストへの掲載
• SPF／DKIM／DMARC の未設定
• DNS レコードが無効
• MX レコードが名前解決できない

高（1 週間以内に修正）：

• SPF の適用が弱い（-all ではなく ~all）
• 1024 ビットの DKIM キー（2048 ビットにアップグレード）
• DMARC ポリシーが p=none（p=quarantine または p=reject にアップグレード）
• PTR レコードの未設定

中（1 か月以内に修正）：

• 集計レポート用の rua タグがない
• TLS／STARTTLS に未対応
• SPF が DNS ルックアップ 10 回の上限に近づいている
• ボーナス機能（BIMI、MTA-STS、TLSRPT）がない

ステップ 5：DNS レコードの推奨事項を作成する

追加または更新する正確な DNS レコードを、コピーして貼り付けられる値とともに提示します。

出力形式

監査レポートは次の構成にします：

1. ヘッダー：日付、ヘルススコア、評価を含む ## Email Deliverability Audit: [domain]
2. 認証テーブル：SPF／DKIM／DMARC のステータス、スコア、生のレコード
3. インフラストラクチャテーブル：MX／PTR／TLS のステータス、スコア、プロバイダーの検出結果
4. レピュテーション：Spamhaus、Barracuda、SORBS、SpamCop でのブラックリスト登録状況
5. 一括送信者のコンプライアンス：8 項目のチェックリスト（Google／Yahoo／Microsoft のルール）
6. ボーナス機能：BIMI、MTA-STS、TLSRPT、Mail-from のアライメント
7. 優先順位を付けた修正リスト：影響、修正手順、DNS レコードを含む重要／高／中の項目
8. 追加する DNS レコード：コピーして貼り付けられる TXT／MX レコード
9. 次のステップ：直ちに、今週中、今月中、監視、再監査

ヘルススコアの計算セクションに記載されたスコアの重みを使用します。ステータスバッジには次を使用します：✅ PASS、⚠️ WARN、❌ FAIL。

ツール

自動 DNS チェックを実行するには、python scripts/check_deliverability.py <domain> --json を実行します。

手動で DNS を確認するコマンド（上記の監査カテゴリで使用）：

• SPF：dig txt <domain> +short
• DKIM：dig txt <selector>._domainkey.<domain> +short
• DMARC：dig txt _dmarc.<domain> +short
• MX：dig mx <domain> +short
• PTR：dig -x <ip> +short
• TLS：openssl s_client -starttls smtp -connect <mx-hostname>:25 -brief

品質ゲート

監査結果を提出する前に、次の項目を確認します。

1. すべての重要なチェックが完了していること（SPF、DKIM、DMARC、MX、ブラックリスト）
2. カテゴリ別の内訳を含む健全性スコアを算出していること
3. 具体的な対応手順を含む、優先順位付きの修正リストを作成していること
4. コピーしてすぐ使える形式で DNS レコードを提示していること
5. スコアの解釈と次の手順を説明していること

エラー処理

DNS クエリに失敗した場合：

• 監査レポートに「確認できません」と記載します
• 手動での確認手順を提示します
• 代替の DNS サーバー（8.8.8.8、1.1.1.1）を提案します

DKIM セレクターが不明な場合：

• 一般的なセレクター（google、default、selector1、selector2）を確認します
• 利用しているメールプロバイダーの DKIM セレクターをユーザーに確認します
• 「DKIM セレクターが見つかりません。手動での確認が必要です」と記載します

MX レコードが見つからない場合：

• 重大なエラーです。ドメインでメールを受信できません
• ドメインがメール転送（Cloudflare など）を使用しているか確認します
• メールホスティングの設定手順を提示します

参考資料

必要に応じて読み込みます。

• references/deliverability-rules.md - スコアのしきい値とコンプライアンスルール
• references/mcp-integration.md - プロバイダー固有の設定と DNS 構成
• references/compliance.md - コンプライアンスルールと規制要件

成功基準

次の条件を満たすと、監査は成功です。

• 健全性スコアがメール到達性の状態を正確に反映している
• すべての重要な問題が、明確な重大度とともに特定されている
• ユーザーが実装可能な DNS レコードを受け取っている
• 修正の優先順位がビジネスへの影響に沿っている
• スコアに基づく再監査の時期が提示されている