DMARC保護はルートドメインで止まることはありません。多くの組織は主要なドメインの保護に焦点を当てていますが、サイバー犯罪者はメール認証制御を迂回するためにサブドメインをターゲットにすることが増えています。DMARCサブドメインポリシーとspタグ設定を理解することで、ドメインインフラ全体にわたる包括的な保護を確保できます。

I. DMARCサブドメイン継承の理解

フィッシング攻撃の67％がルートドメインの保護を回避するためにサブドメインを標的としていることを示す統計。

DMARCは継承モデルで動作し、サブドメインは明示的にオーバーライドされない限り、親ドメインのポリシーを自動的に継承します。example.comにDMARCポリシーを発行すると、mail.example.comやmarketing.example.comなどのサブドメインは、デフォルトで同じポリシーを継承します。

ただし、この継承はサブドメインに特定のDMARCレコードが存在しない場合にのみ適用されます。marketing.example.comに独自のDMARCレコードがある場合、ルートドメインから継承するのではなく、そのポリシーを使用します。

デフォルト継承動作

このルートドメインDMARCレコードを考えてみましょう：

_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]"

明示的なサブドメインポリシーがない場合、すべてのサブドメインがquarantineポリシーを継承します。これは以下を意味します：

  • mail.example.comはp=quarantineを継承
  • shop.example.comはp=quarantineを継承
  • api.example.comはp=quarantineを継承

この継承はベースライン保護を提供しますが、すべての組織ニーズに適合するわけではありません。

II. DMARCspタグ：サブドメインポリシー制御

ルートドメインとサブドメインに対する影響を比較した、さまざまなDMARCポリシー設定を示す比較表。

sp（サブドメインポリシー）タグにより、組織は別々のルートドメインポリシーを維持しながら、サブドメインに異なるポリシーを指定できます。この細かな制御は、サブドメインが主要ドメインとは異なる取り扱いを必要とするシナリオに対応します。

spタグの構文と値

spタグはメインポリシータグと同じ値を受け入れます：

  • sp=none – 強制なしでサブドメイン認証を監視
  • sp=quarantine – 失敗したサブドメインメッセージを疑わしいものとして扱う
  • sp=reject – 認証に失敗したサブドメインメッセージをブロック

戦略的spタグ実装

一般的な設定では、厳格なルートドメイン保護と段階的なサブドメイン強制を組み合わせます：

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; sp=quarantine; rua=mailto:[email protected]"

このポリシーは：

  • ルートドメインからの非認証メッセージを拒否
  • サブドメインからの非認証メッセージを隔離
  • セキュリティを維持しながら段階的強制を提供

III. 高度なサブドメイン設定シナリオ

シナリオ1：高セキュリティルートと監視サブドメイン

重要なルートドメイン通信を持つ組織は、サブドメイン活動を監視しながら厳格なルートポリシーを実装することがよくあります：

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; sp=none; rua=mailto:[email protected]; pct=100"

この設定は主要ドメインを保護しながら、サブドメイン使用パターンに関する情報を収集します。

シナリオ2：ドメイン階層での段階的強制

一部の組織は段階的強制レベルを好みます：

_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; sp=none; rua=mailto:[email protected]"

このアプローチにより、適度なルートドメイン保護を維持しながらサブドメイン認証を監視できます。

シナリオ3：サブドメイン固有のオーバーライドレコード

精密な制御のため、組織は個別のサブドメインに特定のDMARCレコードを発行できます：

_dmarc.marketing.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"
_dmarc.api.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"

これらのレコードは、それぞれのサブドメインについてルートドメインとspタグポリシーの両方をオーバーライドします。

IV. サブドメイン発見と監視

効果的なサブドメインDMARC実装には、包括的なサブドメイン発見が必要です。組織はしばしば自身のサブドメインフットプリントを過小評価し、重要な攻撃ベクターを見落とします。

よく見落とされるサブドメイン

セキュリティチームは頻繁にこれらのサブドメインカテゴリを見落とします：

  • 開発・ステージング環境（dev.example.com、staging.example.com）
  • サードパーティ統合（webhook.example.com、api.example.com）
  • レガシーアプリケーション（old.example.com、archive.example.com）
  • 地域別・部門別サブドメイン（us.example.com、hr.example.com）

サブドメイン可視性のためのDMARCレポート

DMARC集約レポートはサブドメインメール活動の可視性を提供します。ルートドメインポリシーのruaタグは、異なるレポートアドレスを持つ特定のDMARCレコードがない限り、すべてのサブドメインのレポートを受信します。

Skysnag Protectは、DMARCレポート分析を通じてサブドメイン活動を自動的に発見・監視し、組織が以前に知らなかったメール送信サブドメインを特定するのに役立ちます。

V. 実装のベストプラクティス

段階的サブドメインポリシー展開

強制を実装する前に、すべてのサブドメインで監視から開始します：

  1. フェーズ1：p=none; sp=noneを展開してベースラインレポートを確立
  2. フェーズ2：ルートドメイン保護のためp=quarantine; sp=noneに移行
  3. フェーズ3：包括的カバレッジのためp=quarantine; sp=quarantineを実装
  4. フェーズ4：検証後p=reject; sp=rejectに進行

アライメント要件とサブドメイン

DMARCアライメント要件はサブドメインにも等しく適用されます。サブドメインメッセージがDMARCを通過するには：

  • SPFはサブドメインとアライメント（緩和）または完全一致（厳格）する必要
  • DKIM署名は親ドメイン（緩和）またはサブドメイン（厳格）とアライメントする必要

マーケティングオートメーションやトランザクションメールサービスについて、特にサブドメインポリシーを設定する際のアライメントの影響を考慮してください。

サブドメイン設定のテスト

強制ポリシーを実装する前に、サブドメイン設定を十分にテストしてください：

  • SPFレコードがすべてのサブドメイン送信ソースを含むことを確認
  • DKIM署名がドメインポリシーと適切にアライメントすることを保証
  • 予期しないサブドメイン認証失敗についてDMARCレポートを監視
  • すべてのアクティブサブドメインからのメール配信をテスト

VI. コンプライアンスとサブドメインカバレッジ

規制要件の対象となる組織は、包括的なサブドメインカバレッジがコンプライアンス目標をサポートすることを確保すべきです。特定の規制でDMARCサブドメインポリシーが明示的に義務付けられていない場合でも、包括的なメール認証はフィッシングやスプーフィング攻撃に対する保護において適正な注意を示します。

機密データを取り扱う業界では、より広範なサイバーセキュリティフレームワークの一部として、しばしば厳格なサブドメインポリシーを実装します。spタグは、異なるサブドメイン機能間でセキュリティ要件と運用ニーズのバランスを取る柔軟性を提供します。

VII. よくあるサブドメインポリシーの間違い

過度に寛容なサブドメインポリシー

sp=noneを無期限に設定することで、メールセキュリティカバレッジに永続的な盲点を作り出します。監視フェーズは重要ですが、組織はレポートデータに基づいて強制ポリシーに向けて進歩すべきです。

一貫性のないポリシーロジック

寛容なサブドメインポリシーを維持しながら厳格なルートドメインポリシーを実装することで、セキュリティギャップを作り出す可能性があります。攻撃者は弱く保護されたサブドメインをターゲットにしてルートドメイン制御を迂回する可能性があります。

サブドメイン発見の欠如

包括的なサブドメイン発見なしにDMARCポリシーを展開すると、未知の攻撃ベクターが保護されないままになります。定期的なサブドメイン列挙と監視により、包括的なカバレッジを確保します。

VIII. 高度なspタグ考慮事項

ワイルドカードサブドメインの含意

spタグはルートドメイン下のすべての現在および将来のサブドメインに適用されます。これには動的に作成されるサブドメインやワイルドカードDNS設定が含まれます。動的サブドメイン作成を使用する組織は、自動化システムへのspタグの影響を慎重に考慮すべきです。

マルチレベルサブドメイン継承

マルチレベルサブドメイン（mail.marketing.example.comなど）については、DMARC継承は組織ドメイン構造に従います。直近の親、組織ドメイン、またはルートドメインから、最も具体的で利用可能なポリシーが適用されます。

IX. メールセキュリティプラットフォームとの統合

Skysnag Protectなどの現代的なメールセキュリティプラットフォームは、サブドメインDMARCポリシーの集中管理を提供し、ポリシー継承を自動的に追跡し、設定ギャップを特定します。この可視性は、複雑なドメインインフラを管理する組織にとって不可欠であることが証明されています。

自動化されたポリシー管理により、ビジネス要件が異なるアプローチを要求する場合に細かな制御を実装する柔軟性を提供しながら、ルートドメインとサブドメイン間で一貫した保護レベルを確保できます。

X. 重要なポイント

DMARCサブドメインポリシーは、ルートドメインカバレッジを超えた不可欠な保護を提供します。spタグは柔軟なポリシー制御を提供し、組織が異なるサブドメイン機能間でセキュリティ要件と運用ニーズのバランスを取ることを可能にします。

成功するサブドメインDMARC実装には、包括的なサブドメイン発見、段階的ポリシー展開、および集約レポートを通じた継続的監視が必要です。組織は、過度に寛容なポリシーや一貫性のない強制ロジックなどのよくある落とし穴を避けるべきです。

Skysnag Protectは、ドメインインフラ全体にわたる自動発見、集中ポリシー制御、および包括的レポートを通じて、サブドメインDMARC管理を簡素化します。