サブドメインDMARC継承:ポリシーギャップのデバッグ

サブドメイン乗っ取りの試みは、組織がDMARCポリシーの継承が自動的に機能すると想定しているため、現在では一般的にメール認証をバイパスしています。しかし、実際には自動的には機能しません。サブドメインに明示的なDMARCレコードがない場合、サブドメインは組織ドメインのポリシーを継承しますが、それは組織ドメインポリシーが存在し、正しく設定されている場合に限られます。継承が失敗すると、example.comがp=rejectでDMARCを強制していても、攻撃者はmarketing.example.com、support.example.com、または未登録のサブドメインから認証されていないメールを送信できます。

サブドメインDMARC継承は、セキュリティチームが見落としがちな3つの失敗条件を生み出します:(1) 組織ドメインポリシーは存在するが設定が誤っており、サブドメインが意図したよりも弱いポリシーを継承する、(2) サブドメインが組織ドメイン認証と整合しないサードパーティサービス経由でメールを送信するため、継承されたポリシーが整合性チェックに失敗する、または (3) サブドメインがDNSに登録されているが積極的に管理されておらず、攻撃者がホスティングプロバイダーやDNSプロバイダーの脆弱性を通じてサブドメインを主張し、検出前にメールを送信できる悪用可能なギャップが生じる。

AI搭載のフィッシングキャンペーンは、自動化されたDNS列挙とポリシー検証を使用して、これらのギャップをスキャンするようになっています。サブドメインがNXDOMAINまたは空のDMARCレコードを返す場合、攻撃者はそのサブドメインからの偽装メールがDMARCを通過するかどうかをテストします。通過する場合、そのサブドメインは永続的なフィッシングベクターになります。

このガイドでは、サブドメインDMARC継承が実際にどのように機能するか、継承がどこで静かに失敗するか、攻撃者が発見する前に悪用可能なギャップを閉じる強制設定の方法を説明します。

I. DMARCポリシー継承の仕組み(および失敗する場所)

サブドメインから組織ドメインへのDMARCレコードの問い合わせ手順と、レコードが存在しない場合に継承ポリシーが適用されるフォールバックの仕組みを示すフロー図。

受信メールサーバーが[email protected]のDMARCを評価する際、DNSで_dmarc.marketing.example.comのDMARCレコードをクエリします。レコードが存在しない場合、サーバーは_dmarc.example.comをクエリします。組織ドメインにレコードが存在する場合、サブドメインはそのレコードで定義されたポリシーを継承します。

この継承メカニズムは以下の場合に正しく機能します:

組織ドメイン(example.com)がDMARCレコードを公開している
サブドメイン(marketing.example.com)がDMARCレコードを公開していない
サブドメインが組織ドメインのSPFまたはDKIM設定と整合するメールを送信する

継承は以下の場合に失敗します:

組織ドメインDMARCレコードに構文エラーがあり、レコードが無視され、サブドメインが事実上ポリシーを継承しない
サブドメインが独自のエンベロープ送信者ドメインを使用するサードパーティサービス経由でメールを送信し、SPF整合性が破られる
サードパーティサービスが組織ドメイン下のDKIMセレクターで署名せず、DKIM整合性が破られる
サブドメインがDNSに登録されているが積極的に管理されていないため、攻撃者がホスティングプロバイダーのアカウント回復、DNSプロバイダーの脆弱性、またはドメイン登録の期限切れを通じてそれを主張できる

継承が失敗した場合、サブドメインメールはDMARCに静かに失敗する(組織ポリシーがp=noneまたはp=quarantineの場合)か、DMARCに明らかに失敗してもまだ受信ボックスに到達する(受信サーバーが強制を尊重しないか、評判の上書きを適用する場合)。

II. サブドメインDMARC失敗の一般的なシナリオ

シナリオ1:組織ドメインポリシーは存在するがサブドメイン認証が整合しない

設定:

example.comがv=DMARC1; p=reject; aspf=s; adkim=sを公開
marketing.example.comがMailchimp経由でメールを送信
Mailchimpエンベロープ送信者:[email protected]
Mailchimp DKIM署名:d=mcdlv.net

何が起こるか:

DMARCが_dmarc.marketing.example.comをクエリ → レコードなし
DMARCが_dmarc.example.comをクエリ → p=reject; aspf=s; adkim=sを発見
SPFが[email protected]を評価 → mcdlv.netのSPFは通過、marketing.example.comでは通過しない
DKIMがd=mcdlv.netの署名を評価 → mcdlv.netのDKIMは通過、marketing.example.comでは通過しない
厳密モードではSPFもDKIMもmarketing.example.comと整合しないため、DMARC整合性チェックが失敗
結果:継承されたポリシーは受信者にメッセージを拒否するよう指示するが、ポリシーが継承されサブドメインに明示的に設定されていないため、一部の受信者はより緩い強制を適用する可能性がある

修正:
_dmarc.marketing.example.comに明示的なDMARCレコードを公開:

v=DMARC1; p=none; rua=mailto:[email protected]; sp=reject

次に、Mailchimpをd=marketing.example.comまたはd=example.comでDKIM署名するように設定し、緩和モードでDKIM整合性が通過するようにします。

または、組織ドメインでaspf=r; adkim=rを使用して、サブドメインの緩和整合性を許可します。

シナリオ2:DNSに登録されているが積極的に管理されていないサブドメイン

設定:

example.comがv=DMARC1; p=rejectを公開
dev.example.comはDNSに存在するが、もはやメールを送信せず、サービスもホストしていない
攻撃者がDNS列挙を通じてdev.example.comを発見
攻撃者がホスティングプロバイダーのアカウント回復、DNSプロバイダーの脆弱性、またはドメイン期限切れを通じてdev.example.comを主張

何が起こるか:

攻撃者がdev.example.comでメールインフラストラクチャを設定
攻撃者が[email protected]からフィッシングメールを送信
DMARCが_dmarc.dev.example.comをクエリ → レコードなし
DMARCが_dmarc.example.comをクエリ → p=rejectを発見
攻撃者が制御するメールインフラストラクチャは攻撃者が制御するSPFとDKIMを使用し、どちらも緩和整合性モードでdev.example.comと整合する
攻撃者がサブドメインを制御し、準拠した認証を設定できるため、DMARCは通過
組織ドメインの強制にもかかわらず、メールは受信ボックスに到達

修正:
_dmarc.dev.example.comにp=rejectを明示的に公開:

v=DMARC1; p=reject; rua=mailto:[email protected]

非アクティブなサブドメインのDNSレコードを削除します。サブドメインを登録したままにする必要がある場合は、サブドメインがメールを送受信しないことを示すためにヌルMXレコードを公開します:

dev.example.com. IN MX 0 .

サブドメインからの予期しない認証についてDMARCレポートを監視します。

シナリオ3:組織ドメインポリシーの構文エラーが継承を破壊

設定:

example.comが以下を公開:

v=DMARC1; p=reject; rua=mailto:[email protected]; pct=50

newsletter.example.comがメールを送信
newsletter.example.comの明示的なDMARCレコードは存在しない

何が起こるか:

DMARCが_dmarc.newsletter.example.comをクエリ → レコードなし
DMARCが_dmarc.example.comをクエリ → pct=50のレコードを発見
多くの最新のDMARC実装はpct=を無視するか、パーセンテージベースの強制を一貫性なく扱う
サブドメインは予測可能に強制されない可能性のあるポリシーを継承
攻撃者がnewsletter.example.comから偽装メールを送信し、強制が適用されるかどうかを観察

修正:
組織ドメインポリシーからpct=を削除:

v=DMARC1; p=reject; rua=mailto:[email protected]

パーセンテージではなく、サブドメインまたは送信者グループごとに強制をステージングします。

III. 明示的なサブドメインポリシー設定パターン

サブドメイン乗っ取り攻撃の進行過程を、発見から侵害、悪用までの3つの段階で示す階層型アーキテクチャ図。

パターン1:組織ドメインポリシーを継承(デフォルト動作)

組織ドメインレコード:

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

サブドメインの動作:

marketing.example.comがp=rejectを継承
support.example.comがp=rejectを継承
明示的なレコードが存在しない限り、すべてのサブドメインがp=rejectを継承

使用するタイミング:

すべてのサブドメインを制御している
すべてのサブドメインが組織ドメインSPFまたはDKIMと整合するインフラストラクチャ経由でメールを送信

パターン2:特定のサブドメインの継承ポリシーを上書き

組織ドメインレコード:

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

サブドメインの上書き:

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

結果:

marketing.example.comはp=noneを使用
他のすべてのサブドメインはp=rejectを継承

使用するタイミング:

特定のサブドメインが組織ドメイン認証とまだ整合できないサードパーティサービス経由でメールを送信
サブドメインでポリシーを強制する前に認証結果の可視性が必要

パターン3:組織ドメインレベルでサブドメインポリシーを設定

組織ドメインレコード:

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

結果:

example.comはp=rejectを使用
すべてのサブドメインはp=quarantineを継承(sp=で定義)

使用するタイミング:

組織ドメイン対サブドメインで異なる強制が必要
サブドメインが低ボリュームまたは低リスクのメールを送信

パターン4:すべてのサブドメインに明示的な強制

組織ドメインレコード:

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

明示的なサブドメインレコード:

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

使用するタイミング:

最大限の可視性と制御が必要
どのポリシーが適用されるかについての曖昧さを排除したい
レポート異常を通じてサブドメイン乗っ取りの試みを検出したい

IV. 整合性モードとサブドメイン継承の相互作用

DMARC整合性モード(SPFのaspf=、DKIMのadkim=)は、整合性が正確なドメイン一致(厳密モード)を必要とするか、組織ドメイン一致(緩和モード)を許可するかを制御します。

緩和モード(aspf=r; adkim=r):

エンベロープ送信者ドメインがmail.example.comでヘッダーFromが[email protected]の場合、SPFは通過
DKIM署名ドメインがmail.example.comでヘッダーFromが[email protected]の場合、DKIMは通過

厳密モード(aspf=s; adkim=s):

エンベロープ送信者ドメインがヘッダーFromドメインと正確に一致する場合にのみSPFは通過
DKIM署名ドメインがヘッダーFromドメインと正確に一致する場合にのみDKIMは通過

サブドメイン継承の相互作用:
サブドメインが厳密整合性モードのポリシーを継承する場合、そのサブドメインからのメールは正確に整合する必要があります。サブドメインがSPFまたはDKIMに独自のドメインを使用するサードパーティサービス経由で送信する場合、厳密整合性は失敗します。

例:

組織ドメイン:v=DMARC1; p=reject; aspf=s; adkim=s
サブドメイン:marketing.example.comがMailchimp経由で送信
Mailchimpはエンベロープ送信者に[email protected]を使用
MailchimpはDKIM署名にd=mcdlv.netを使用
DMARCが厳密整合性を評価:SPFとDKIMの両方が整合性に失敗
結果:DMARCが失敗、ポリシーは拒否を指示

修正オプション:

組織ドメインポリシーを緩和モードに変更:aspf=r; adkim=r
緩和モードで明示的なサブドメインポリシーを公開:v=DMARC1; p=reject; aspf=r; adkim=r
Mailchimpを組織ドメインまたはサブドメインセレクターでDKIM署名するように設定

V. サブドメイン乗っ取り攻撃パターンとDMARCギャップ

サブドメイン乗っ取りは、組織が登録したが積極的に管理していないサブドメインの制御を攻撃者が主張したときに発生します。一般的な攻撃ベクターには以下が含まれます:

期限切れDNSホスティング: サブドメインCNAMEが期限切れになったホスティングプロバイダーアカウントを指している。攻撃者が同じプロバイダーで新しいアカウントを登録し、サブドメインを主張。
ダングリングCNAME: サブドメインCNAMEがもう存在しないサービス(GitHub Pages、AWS S3、Herokuなど)を指している。攻撃者がサービス名を登録し、サブドメインからコンテンツを提供。
DNSプロバイダーアカウント侵害: 攻撃者が認証情報の再利用、フィッシング、またはプロバイダーの脆弱性を通じてDNSプロバイダーアカウントにアクセス。攻撃者がサブドメインレコードを変更して攻撃者が制御するインフラストラクチャを指すようにする。

DMARC継承はサブドメイン乗っ取りを防ぎません。 攻撃者がサブドメインインフラストラクチャを制御している場合、攻撃者はSPFとDKIMをサブドメインと整合するように設定でき、組織ドメインがp=rejectを強制している場合でもDMARCを通過します。

検出と防止:

明示的なサブドメインポリシー: すべてのサブドメインでDMARCレコードを公開して、認証アクティビティの可視性を得る。
DNS監視: サブドメインのA、AAAA、CNAME、MX、またはTXTレコードへの予期しない変更についてDNSレコードを監視。
DMARCレポート分析: メールを送信すべきでないサブドメインからの認証についてDMARCレポートを確認。
ヌルMXレコード: メールを送受信しないサブドメインにヌルMXを公開:

inactive.example.com. IN MX 0 .

未使用のDNSレコードを削除: コンテンツを提供しなくなったまたはメールを送信しなくなったサブドメインのA、AAAA、CNAMEレコードを削除。

VI. 継承されたDMARCポリシー失敗のデバッグ

サブドメインがDMARCポリシーを継承しているがメールが予期せず強制に失敗する場合、この診断プロセスに従ってください:

ステップ1:組織ドメインポリシーの構文を検証

組織ドメインDMARCレコードをクエリ:

dig TXT _dmarc.example.com +short

期待される出力:

"v=DMARC1; p=reject; rua=mailto:[email protected]"

継承を破壊する一般的な構文エラー:

v=DMARC1の欠落
無効なp=値(必須:none、quarantine、またはreject)
不正な形式のrua=アドレス
非推奨のpct=タグの含有

構文エラーが存在する場合、レコードが無視され、サブドメインが事実上ポリシーを継承しない可能性があります。

ステップ2:サブドメインレコードの不在または存在を検証

サブドメインDMARCレコードをクエリ:

dig TXT _dmarc.marketing.example.com +short

期待される出力(継承している場合):

(出力なし)

期待される出力(明示的な上書きの場合):

"v=DMARC1; p=none; rua=mailto:[email protected]"

サブドメインにレコードが存在する場合、継承は発生しません。サブドメインは独自のポリシーを使用します。

ステップ3:SPF整合性を検証

DMARCレポートまたはメールヘッダーでSPF結果と整合性を確認します。

一般的なSPF整合性失敗:

エンベロープ送信者ドメイン:[email protected]
ヘッダーFromドメイン:[email protected]
mail.thirdpartyservice.comのSPFは通過
エンベロープ送信者ドメインがヘッダーFromドメインと一致しないため、SPF整合性は失敗

修正:

サードパーティサービスを組織ドメインまたはサブドメインをエンベロープ送信者として使用するように設定
組織ドメインまたはサブドメインレベルで緩和整合性モードを使用

ステップ4:DKIM整合性を検証

メールヘッダーでDKIM署名ドメインを確認:

DKIM-Signature: v=1; a=rsa-sha256; d=thirdpartyservice.com; s=selector; ...

d=thirdpartyservice.comでヘッダーFromが[email protected]の場合、厳密モードでDKIM整合性は失敗します。

修正:

サードパーティサービスをd=marketing.example.comまたはd=example.comでDKIM署名するように設定
組織ドメインまたはサブドメインレベルで緩和整合性モードを使用

ステップ5:サブドメインアクティビティのDMARCレポートを確認

DMARC集約レポートにはサブドメイン認証結果が含まれます。以下を探します:

認識していないサブドメイン
既知のサブドメインからの高い失敗率
制御していないIPアドレスからの認証

サブドメインがレポートに表示されるが、サブドメインインフラストラクチャを制御していない場合は、サブドメイン乗っ取りを調査してください。

管理されたSkysnagデプロイメントでは、Skysnagによって生成されたレポート先を使用してください。以下は手動の例のみです:

v=DMARC1; p=none; rua=mailto:[email protected]

従来の静的レコードは機能しますが、レポートが積極的に受信、解析、分析、対処される場合に限られます。

VII. 推奨されるサブドメインDMARC設定戦略

組織ドメインポリシーを公開:

v=DMARC1; p=reject; rua=mailto:[email protected]; sp=quarantine

これにより、組織ドメインにはp=rejectが強制され、デフォルトですべてのサブドメインにはp=quarantineが強制されます。

アクティブなサブドメインに明示的なポリシーを公開:

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

これにより、認証アクティビティの可視性が提供され、サブドメインごとに段階的な強制が可能になります。

非アクティブなサブドメインのDNSレコードを削除。
メールを送受信しないサブドメインにヌルMXを公開:

inactive.example.com. IN MX 0 .

予期しないサブドメインアクティビティについてDMARCレポートを監視。

Skysnag Protectを使用して、正当な送信者を識別し、不正なソースを検出し、強制に向けて移行してください:

VIII. 重要なポイント

サブドメインのDMARC継承は、組織ドメインが有効なDMARCレコードを公開しており、かつサブドメインが独自のレコードを公開していない場合にのみ機能します。組織ドメインポリシーに構文エラーが含まれている場合、サブドメインが整合性のない第三者サービス経由でメールを送信している場合、またはサブドメインが登録されているが積極的に管理されておらずサブドメイン乗っ取りの機会を生み出している場合、継承は失敗します。

すべてのアクティブなサブドメインに対して明示的なDMARCポリシーを公開し、可視性と制御を獲得してください。非アクティブなサブドメインのDNSレコードを削除してください。メールを送受信しないサブドメインにはnull MXレコードを使用してください。予期しないサブドメイン認証アクティビティについてDMARCレポートを監視してください。

SkysnagでDMARC監視を開始し、無料のDMARCレコードを取得してください: