カスタムメール配信ヘルスルールの作り方:高度なモニタリング設定

標準ルールからカスタムメール配信ヘルスルールへ

標準的なメール配信ヘルスチェックは、基本的なレコードを確認します。「MXレコードはありますか?SPFはありますか?DKIMはありますか?」

しかし、実際のメールインフラはもっと複雑です。

• 5つの異なるメールサービス(SendGrid、Google Workspace、Mailgun、Zoho、Amazon SES)を利用している
• それぞれにSPF includeが必要
• 複数のDKIMセレクター(サービスごとに1つ)を持っている
• メールプロバイダーを移行中(古いDKIMセレクターがまだ残っており、新しいものをセットアップ中)
• 厳格なDMARCポリシー(p=reject)を適用しているが、正規のメールを壊さないよう注意が必要

標準チェックは合格・不合格を返すだけです。カスタムルールはこの複雑さに対応します。

このガイドでは、高度なメールインフラ向けにメール配信ヘルスルールをセットアップする方法を解説します。

カスタムルール#1:複数セレクターのDKIM設定#

複数のメールサービスを利用していると、複数のDKIMセレクターが存在します。

課題

シナリオ: トランザクションメールにSendGrid、マーケティングメールにMailgunを使用。

DNS設定:

s1._domainkey.yourdomain.com → SendGridのDKIMキー
s2._domainkey.yourdomain.com → MailgunのDKIMキー

標準モニタリングは「DKIM設定済み」(合格)と表示しますが、以下は確認できません。

• 両方のセレクターが有効か
• 両方のセレクターが正しいキーを持っているか
• 両方が適切にローテーションされているか

解決策:カスタムルール

ルールを作成: 「DKIMセレクターが欠けている場合にアラート」

ルール名: DKIM冗長性チェック
条件: s1._domainkey が存在し、かつ s2._domainkey が存在すること
アラート条件: いずれかのセレクターが欠けている
重要度: 警告(クリティカルではない)
通知: 「DKIM冗長性が損なわれています。SendGridセレクターが見つかりません。」

実装例(Nova Uptimeでサポートされている場合):

curl -X POST https://api.novauptime.com/api/v1/domains/yourdomain.com/rules \
  -H "X-API-Key: your-key" \
  -d '{
    "name": "DKIM Redundancy",
    "type": "dkim_selector_count",
    "condition": {
      "minSelectors": 2,
      "requiredSelectors": ["s1", "s2"]
    },
    "alert": {
      "threshold": "below",
      "severity": "warning"
    }
  }'

カスタムルール#2:SPFルックアップ上限のモニタリング#

SPFには10回のDNSルックアップ上限があります(RFC 7208)。10回を超えると、SPF認証は静かに失敗します。

課題

あなたのSPFレコード:

v=spf1 \
  include:sendgrid.net \
  include:mailgun.org \
  include:_spf.google.com \
  include:amazonses.com \
  include:mailchimp.org \
  include:zoho.com \
  include:github.com \
  include:discourse.org \
  ip4:192.0.2.1 \
  -all

各 include: ディレクティブは1回のDNSルックアップを使用します。

• sendgrid.net:1ルックアップ
• mailgun.org:1ルックアップ
• _spf.google.com:1ルックアップ
• amazonses.com:1ルックアップ
• mailchimp.org:1ルックアップ
• zoho.com:1ルックアップ
• github.com:1ルックアップ
• discourse.org:1ルックアップ
• ip4:0ルックアップ(直接IP、DNS不要)

合計:8ルックアップ(上限内、安全圏)

しかし、もう1つサービスを追加したらどうなるでしょうか?

解決策:カスタムルール

ルールを作成: 「SPFルックアップが上限に近づいたらアラート」

ルール名: SPFルックアップ上限
条件: SPFレコード内のDNSルックアップ数をカウント
アラート条件: ルックアップ > 8(2回分の余裕を残す)
重要度: 警告
推奨: SPF includeを統合するか、SPFフラット化サービスを使用

この対応が重要な理由:

• 標準モニタリング:SPF設定済み ✅
• カスタムルール:SPF設定済み、しかしルックアップ上限に接近 ⚠️

カスタムルールは、標準モニタリングが見逃す問題を捉えます。

カスタムルール#3:DMARCレポートのモニタリング#

DMARCは、認証に失敗したメール件数を示すレポートを提供します。これらのレポートはモニタリングすべきです。

課題

あなたのDMARCポリシー:

_dmarc.yourdomain.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com"

DMARCは毎日 dmarc@yourdomain.com にレポートを送信します。レポートには次の内容が含まれます。

• SPFを通過したメールの割合
• DKIMを通過したメールの割合
• 両方とも失敗したメールの割合(なりすまし試行)

これらのレポートを確認しなければ、セキュリティ上の重要な気づきを逃すことになります。

解決策:カスタムルール

ルールを作成: 「DMARCレポートで異常な失敗率が出たらアラート」

ルール名: DMARC失敗率モニタリング
チェック: 毎日受信するDMARCレポート
アラート条件: 正規メールの失敗率 > 1%(SPF/DKIMの問題を示唆)
アラート条件: なりすまし試行率 > 5%(ドメインが標的にされている可能性)
重要度: 失敗は警告、高いなりすまし試行はクリティカル

アラート例:

⚠️ DMARCアラート:異常な活動を検出
ドメイン: yourdomain.com
レポート日: 2026年2月20日

正規メールの失敗: 12%(通常: <1%)
推定原因: 新しいメールサービスがSPF/DKIMなしで追加された
対応: SendGridのDKIMが正しくローテーションされているか確認

なりすまし試行: 2%(通常: <0.1%)
推定原因: フィッシングキャンペーンでドメインが悪用されている
対応: DMARCポリシーを確認(現在 p=reject、良好)

カスタムルール#4:メールサービス移行ワークフロー#

あるメールサービスから別のサービスへ移行する際、両サービスのDKIMセレクターが共存する一時的な期間が必要になります。

課題

シナリオ: SendGridからMailgunへ移行中。

移行前の状態:

s1._domainkey (SendGrid DKIM)

移行中の状態:

s1._domainkey (SendGrid DKIM) ← 旧サービス、段階的に廃止中
s2._domainkey (Mailgun DKIM) ← 新サービス

この期間中:

• SPFは両サービスを include
• 両DKIMセレクターが存在
• 両サービスからのメールが認証される

切り替え後の状態:

s1._domainkey (SendGrid DKIM) ← 削除する
s2._domainkey (Mailgun DKIM)

切り替え後に古いDKIMセレクターを削除し忘れると、設定のドリフトが発生します。

解決策:カスタムルール

ルールを作成: 「移行期限後にアラート」

ルール名: SendGrid DKIM削除期限
タイプ: 移行トラッキング
セットアップ日: 2026年2月15日(移行開始)
予定切替日: 2026年2月22日
アラート条件: 2026年2月25日以降もSendGrid DKIMが残っている
重要度: 警告
メッセージ: 「SendGrid DKIMセレクター(s1)は3日前に削除されているはずです」

カスタムルール#5:DMARCポリシー進化ワークフロー#

企業はDMARCポリシーを段階的に進化させることが多いです。

1. 初日: p=none(強制せず、モニタリングのみ)
2. 2週目: p=quarantine(失敗を拒否ではなく迷惑メールへ)
3. 2ヶ月目: p=reject(失敗を拒否、厳格な強制)

この段階的な進化により、厳格化前に影響をモニタリングできます。

課題

p=quarantine から p=reject への移行を計画しています。厳格化する前に、すべてが正しく機能していることを検証する必要があります。

解決策:カスタムルール

ルールを作成: 「DMARCポリシー変更時にアラート」

ルール名: DMARCポリシー進化トラッキング
フェーズ1(2月1日): p=quarantine をデプロイ
  マイルストーン: 2週間モニタリング
  アラート条件: 正規メールの失敗率 > 1%(SPF/DKIMの問題を示唆)

フェーズ2(2月15日): p=reject へ移行
  前提条件: フェーズ1で正規メールの失敗がないことを確認
  アラート条件: 前提チェックがすべて通過していない

フェーズ3(3月1日): 採用状況を検証
  アラート条件: なりすまし試行を検出(rejectが機能している示唆)

カスタムルール#6:サードパーティメールサービスの検証#

メール送信をTwilio、SendGrid、Mailgunなどのサービスにアウトソースしている場合、それらが正しく設定されていることを検証する必要があります。

課題

SendGridは「あなたのドメインから適切なSPF/DKIM付きでメールを送信します」と約束します。

しかし、彼らが自分たちの側で誤った設定をしたら?あるいはDNSを更新してあなたに伝え忘れたら?

解決策:カスタムルール

ルールを作成: 「サードパーティメールサービスが正しく認証されているか検証」

ルール名: SendGrid設定検証
チェック: SendGridのDKIMキーがあなたのDNSレコードと一致
チェック: SendGridのSPF includeがあなたのSPFレコードに含まれている
チェック: SendGridのドメイン認証が「verified」(pendingではない)
アラート条件: いずれかのチェックが失敗
重要度: クリティカル
対応: 「SendGridサポートに連絡。ドメイン認証が期限切れの可能性。」

カスタムルール#7:メール配信ヘルスのベースライン比較#

メール配信ヘルスは変動します。ベースラインと比較して何かが変わったときに気づきたいものです。

課題

先月のメール配信ヘルススコアは92でした。今月は88です。何か壊れたのでしょうか?

標準モニタリングは絶対値のスコアでアラートを出します。カスタムルールは「変化」でアラートを出します。

解決策:カスタムルール

ルールを作成: 「ベースラインから大きく変化したらアラート」

ルール名: メール配信ヘルス劣化検出
ベースライン: 2月1日のスコア(92/100)
しきい値: スコアが5ポイント以上低下したらアラート
アラート条件: 現在のスコア < 87
重要度: 警告
メッセージ: 「メール配信ヘルスが92から88に低下(原因の可能性: DKIMキーローテーション)」

カスタムルール#8:コンプライアンス監査ルール#

規制対象(HIPAA、SOC2、PCI-DSS)である場合、特定の設定が必要になります。

例:医療業界のコンプライアンス

要件:

• DMARC p=reject(厳格な強制)
• SPF -all(ソフトフェイルなし)
• プライマリおよびバックアップドメインの両方にDKIM
• すべての送信メールにTLS
• 機密データのメール暗号化

カスタムルール:

ルール名: HIPAAメールコンプライアンスチェック
要件1: DMARCポリシーは p=reject であること
  アラート条件: ポリシーが p=quarantine または p=none

要件2: SPFは -all で終わること
  アラート条件: SPFが ~all (ソフトフェイル)で終わる

要件3: バックアップドメインにもDKIMが必要
  アラート条件: バックアップドメインにDKIMがない

要件4: すべてのメールにTLSが必要
  アラート条件: システムから非TLSメールが送信される

要件5: 機密メールは暗号化が必要
  アラート条件: PIIを含むメールが S/MIME または PGP を使用していない

カスタムルールの実践的な実装方法

オプション1:モニタリングツールの組み込みルールを使う#

Nova Uptimeのようにカスタムルールをサポートしているモニタリングツールを使う場合、ダッシュボードを利用します。

1. ドメイン設定へ移動
2. 「カスタムルール」をクリック
3. ルールタイプを選択(SPFルックアップ数、DKIMセレクターなど)
4. しきい値を設定
5. アラートを設定
6. 保存

オプション2:Webhookでカスタムシステムへ連携#

モニタリングツールがカスタムルールをサポートしていない場合、Webhookを使用します。

# モニタリングツールがWebhookを送信:
POST /your-system/webhooks/email-health
{
  "domain": "yourdomain.com",
  "email_health": {
    "score": 88,
    "spf_lookups": 9,
    "dkim_selectors": 2,
    "dmarc_policy": "reject",
    "blacklist_status": "clean"
  }
}

# あなたのシステムでルールを評価:
if (email_health.spf_lookups > 9) {
  alert("SPFルックアップ上限に接近");
}
if (email_health.dmarc_policy !== "reject") {
  alert("DMARCポリシーが厳格でない");
}

オプション3:月次の手動監査#

上記のいずれも利用できない場合:

1. モニタリングツールからメール配信ヘルスデータをエクスポート
2. カスタム列付きのスプレッドシートを作成
3. 月次で要件と照合
4. 何かが変わっていたらチームにアラート

カスタムルールでよくある失敗

失敗1:カスタムルールを作りすぎる#

問題: 50個のカスタムルールを作り、アラートに圧倒され、結果としてすべてを無視する。

解決策: クリティカルな3〜5個のルールから始めましょう。必要に応じて追加します。

失敗2:アクションのないルール#

問題: 「SPFルックアップ > 8 でアラート」が発火しても、チームが何をすべきか分からない。

解決策: すべてのルールにアクション項目を含めます。

条件: SPFルックアップ > 8
アラートメッセージ: 「SPFルックアップ上限に接近。
対応: SPFフラット化サービスでincludeを統合してください。
詳細: https://knowledge.spf-flattening.com」

失敗3:ルールをテストしない#

問題: 半年前にカスタムルールをセットアップ。条件が満たされたときに本当に発火するか検証していない。

解決策: 四半期ごとにルールをテストします。

1. 意図的に条件をトリガー(例:SPF includeを手動で追加)
2. アラートを待つ
3. アラートが正しいことを確認
4. テストトリガーを取り除く

失敗4:ルールが現実から乖離する#

問題: 2月にDMARC進化ルールを設定。更新を忘れた。今は6月でルールが古くなっている。

解決策: 四半期ごとにカスタムルールを見直します。ビジネス要件が変わっていたら更新しましょう。

まとめ:カスタムメール配信ヘルスルール チェックリスト

• ✅ メールインフラを把握する(サービス数は?セレクター数は?)
• ✅ DKIM冗長性ルールを設定(複数セレクター)
• ✅ SPFルックアップ上限ルールを設定(8ルックアップで警告)
• ✅ DMARCレポートモニタリングルールを設定(異常な失敗率)
• ✅ メールサービス移行ルールを設定(プロバイダー移行時)
• ✅ DMARCポリシー進化ルールを設定(段階的に厳格化する場合)
• ✅ コンプライアンスルールを設定(規制業界の場合)
• ✅ 各ルールが機能することをテスト
• ✅ チーム向けにルールをドキュメント化
• ✅ 四半期ごとに監査と刷新

今日から始めましょう

標準的なメール配信ヘルスモニタリングは良いものです。カスタムメール配信ヘルスルールはそれを優れたものにします。

Nova Uptimeをお使いの場合は、ドメイン設定にアクセスして、独自のインフラに合わせたカスタムルールを作成してください。お使いのツールがまだカスタムルールをサポートしていない場合は、Webhookか手動監査を活用しましょう。

メールインフラはあまりに重要で、標準チェックだけに任せておくわけにはいきません。カスタムルールがあれば、お客様に影響が及ぶ前に、あなたのセットアップ固有の問題を捉えられます。