[ DMARCとポリシー ]

DMARC組織ドメイン: ID を比較する前に境界を追跡する

現在のDMARC検出ルールを使用して、ポリシー レコード、組織ドメイン、およびマルチパート サフィックスの下にあるドメインを含む ID 比較を分離します。

EmailAuth研究チームによる · 6 分で読めます

このページでは

アン 組織ドメイン で使用される境界です DMARC 処理。これは、表示されている From ドメインに独自のレコードがない場合に受信者がポリシーを見つけるのに役立ち、認証された ID をリラックスした状態で比較するのに役立ちます。 アライメント。これらは関連する操作ですが、同じ質問ではありません。

「最後の 2 つのラベルを取得する」というショートカットは信頼できません。 co.ukなど、複数の部分からなるパブリック サフィックスの下にある名前は、2 つのラベルを数えることで組織ではなくサフィックスを選択できる理由をすでに示しています。現在の仕様では、ショートカットを避ける理由がさらに追加されています。 RFC 9989 に依存するのではなく、 DNSツリー ウォーキングを定義します。 パブリックサフィックスリスト 一人で。

3 つの質問を別々に書き留めます

まず、メッセージの差出人アドレスの実際のドメイン (作成者ドメインと呼ばれます) から始めます。次に次のように尋ねます。

  • この作成者ドメインに適用されるDMARCポリシー レコードはどれですか?
  • 適用可能な検出プロセスは、比較される各 ID に対してどの組織ドメインを確立しますか?
  • 通過しますか SPF または DKIM ID は選択した位置合わせモードを満たしていますか?

作成者ドメインに直接ある有効なレコードがポリシーの選択に勝ちます。これは、作成者ドメインが緩和された調整に使用される組織ドメインであることを自動的に証明するものではありません。 「ドメイン」フィールドを 1 つだけ表示するDNSチェッカーを開始ビューとして扱い、その結論を説明するために必要な実際の名前と応答を収集します。

の アイデンティティチェーンガイド 検出を開始する前に、From、エンベロープ、およびDKIMドメインを識別するのに役立ちます。

ラベル付きの例に従ってください

以下は合成DNSスナップショットです。これは、予約された .example 名前空間の下にある架空のレジストリを示しています。これは、ライブ クエリ結果や実際のパブリック サフィックスに関するアサーションではありません。

既存の作成者ドメインがinvoice.harbour.registry.exampleであると仮定します。そのメッセージには受け継がれていくものがある DKIM署名 d=sign.harbour.registry.example. SPF 、調整されていない別のサービス ドメインに合格します。

クエリ対象応答例結果
_dmarc.invoice.harbour.registry.exampleDMARCポリシーレコードがありません発見を続ける
_dmarc.harbour.registry.examplev=DMARC1; p=none; sp=quarantine; psd=nこの明確な組織境界を確立し、歩みを止めてください
_dmarc.registry.example停止後は問い合わせられないこのウォークではこれ以上の応答は必要ありません

選択したポリシーは、 harbour.registry.exampleのレコードです。 invoice.harbour.registry.exampleは存在し、サブドメインであるため、適用される評価ポリシーは sp による隔離です。レコードがpsd=n.を明示的に通知しているため、組織ドメインはharbour.registry.exampleです。

DKIM ID の場合、 _dmarc.sign.harbour.registry.exampleでの例示的な検索ではレコードが返されず、その後に同じpsd=n境界レコードが返されます。したがって、認証された署名 ID と作成者ドメインは組織ドメインを共有します。緩和されたDKIMアライメントでは、 DKIM署名を渡すことで、アライメントされたパスが提供されます。厳密な位置合わせには、正確な同一性が必要ですが、これら 2 つの異なる名前にはありません。

この例では、ポリシーの選択、境界検出、認証、および調整を意図的に個別の結果として表示できるようにしています。ポリシー値を変更しても、等しくないドメイン文字列は完全一致にはなりません。

何が歩みを止めるのかを理解する

RFC 9989セクション 4.10 では、クエリ、レコード フィルタリング、および制限について規定しています。 psd=nが指定された有効なレコードは、組織の境界を識別します。 psd=yを持つ有効なレコードは、パブリック サフィックス境界を識別し、必要に応じて、組織ドメイン選択ルールによってそのラベルの 1 つ下のドメインが考慮されます。

どちらの信号も境界を解決できない場合、仕様では選択ルールとフォールバック ルールが提供されます。また、攻撃者が無制限の検索を強制することを避けるために、長い名前の検出を制限します。運用環境の実装には、無効なレコードや複数のレコード、 DNSエラーを含む完全なアルゴリズムが必要です。馴染みのある名前が表示されるまでラベルを削除することは代替策ではありません。

psd=yを通常の組織のレコードにコピーしないでください。接尾辞の役割について説明します。 psd=n 、委任されたサブツリーを含む意図的な組織境界をサポートできますが、普遍的なチェックリストではなく、文書化された名前空間の決定に従う必要があります。

ツールと受信機の違いを調査する

古い実装では、次のようなパブリック サフィックス アプローチが使用される場合があります。 RFC 7489。新しい実装はRFC 9989ツリー ウォーキングに従う可能性があります。したがって、結果が一致しない場合には、 DNS応答、キャッシュ、実装サポートが重要になる可能性があります。

有用な比較のために、完全な ID 名、タイムスタンプ付きのクエリ応答、検出されたポリシー レコード、アライメント設定、および受信者の結果を保持します。どの検出モデルを実装しているかは、ツール ベンダーに問い合わせてください。発行日から一般的な採用を推測したり、2 つのダッシュボード ラベルを一致させるためだけにDNSを変更したりしないでください。

真の境界の不一致を未加工の認証問題から分離します。 DKIM署名の欠落、署名の失敗、または未承認の送信ルートは、組織ドメインの計算が修正されるため有効になりません。

境界を運用記録にする

複数のビジネス ユニットまたは委任されたDNSチームを持つドメインの場合は、各境界の下で誰が公開できるか、およびどのサービスがそこでメールを認証できるかを記録します。アプリケーションがサブドメインを取得した場合、事業部門がDNS管理を変更した場合、またはサプライヤーが退職した場合には、そのレコードを再確認してください。

使用 サブドメインポリシーの検証 どのポリシーが適用されるかを確認するため、および アライメント比較 どのドメイン関係が許容されるかを決定するとき。

有益な結果は、再現可能なチェーンです。これらはメッセージ ID であり、これらのDNS応答は関連する境界を確立し、このポリシーが適用され、この受け渡し ID は調整されたか調整されませんでした。推測されたドメイン ラベルではその証拠は得られません。

境界決定カードを使用する

このカードは、ポリシー検出の代わりとしてではなく、組織ドメインの選択に使用します。まず、作成者ドメインに独自のポリシーがあるかどうかを確認します。直接ポリシーは、位置合わせに別の境界計算が必要な場合でも適用できます。

指定された散歩中の観察境界決定
有効なレコードにはpsd=nが含まれています停止;そのレコードのドメインは組織ドメインです。
有効なレコードには、開始ドメインから離れたpsd=yが含まれています停止;そのパブリックサフィックスの 1 ラベル下のドメインを選択します。
psd=y is at the starting domainウォークは停止しますが、「ラベルが 1 つ下」ルールは開始レコードには適用されません。子ドメインを作成するのではなく、選択ルールを適用します。
有効な記録は決定的な境界信号がなくても存在するラベルが最も少ない名前の有効なレコードを選択します。最初の祖先レコードを自動的に選択しないでください。
組織ドメインが決まっていない最初のターゲット ドメインを組織ドメインとして使用します。このフォールバックでは、ポリシー レコードは作成されません。
件名には多くのラベルが付いています8 クエリ境界を適用します。最初のクエリを保持し、指定されたとおりに短縮します。任意に長い名前のすべての祖先をクエリしないでください。

これらの行は要約します RFC 9989セクション 4.10–4.10.2;レコード フィルタリングと DNS エラー処理は引き続き適用されます。ポリシー検出中にポリシーが見つからないということは、調整アルゴリズムに境界フォールバックがあるにもかかわらず、 DMARC適用されないことを意味します。

2 番目の架空のトレースとして、 a.mail.example.comの探索で、 mail.example.comとexample.comで有効なレコードが見つかり、 psd=nもpsd=y,他の場所には何も見つからないとします。選択された組織ドメインはexample.comです。代わりにmail.example.com psd=n,ウォークはそこで停止し、より具体的な境界が優先されます。別のオペレーターが比較を再現できるように、結果を含むDNSスナップショットを保存します。

【役割別】

これがあなたにとって何を意味するか

実際の次のステップに向けて、自分の役割を選択してください。

IT / メール管理者

ポリシーと調整を個別に記録します。

検出された 1 つのレコードがポリシーの選択に答えることができますが、緩和された調整にはさらなる ID 分析が必要です。

次のステップ

  1. クエリされた正確な名前と応答を保持します。
  2. 受信機またはツール検出モデルを確認します。
  3. 境界変更後に実際のメッセージをテストします。

CISO / SecOps

委任によってもたらされる信頼を確認します。

サブツリーを誰が制御するかは、どの認証済み ID がDMARC境界を共有するかに影響を与える可能性があります。

次のステップ

  1. DNS委任を責任ある所有者にマッピングします。
  2. 意図的なpsd=n境界を確認します。
  3. サプライヤーの許可とともに調整に関する決定を評価します。

創業者 / 非技術系

ドメイン構造を説明できるようにします。

複雑な名前空間では、買収、サプライヤー、または事業部門が原因不明のメール障害を引き起こさないように、文書化された運用境界が必要です。

次のステップ

  1. 委任されたドメインに所有権を割り当てます。
  2. 動作した ID とポリシーのトレースを要求します。
  3. サービスのオンボーディングに名前空間の変更を含めます。

[ よくある質問 ]

よくある質問

組織ドメインは常に最後の 2 つのラベルですか?

いいえ。マルチパート サフィックスにより、そのショートカットはすでに信頼性が低くなり、現在のRFC 9989検出でもDNSレコードと定義された境界ルールが使用されます。

From ドメインのレコードによって、そのドメインが組織ドメインになりますか?

その直接ポリシー レコードを選択します。緩和された調整のための組織ドメインの決定は、セクション 4.10.2 によって管理される別の問題です。

実際の例ではpsd=nは何を意味しますか?

これは、 harbour.registry.example組織の境界として明示的に識別し、図示されたウォークを停止します。

一般の企業はpsd=y?

その値を通常の会社の記録にコピーしないでください。これはパブリック サフィックス ドメインの役割を通知し、境界の決定を変更する可能性があります。

緩和された配置とは、任意の 2 つのサブドメインが一致できることを意味しますか?

いいえ。実際の組織ドメイン検出ルールを ID に適用し、結果のドメインを比較します。委任された境界または明示的な境界が重要になる場合があります。

古いチェッカーが現在のレシーバーと一致しないのはなぜですか?

異なる検出モデルを実装したり、異なるDNSデータを参照したりする場合があります。修正を選択する前に、クエリ応答、タイムスタンプ、および受信者の信頼できる結果を保持します。

厳密な調整には組織ドメインの一致が必要ですか?

厳密な調整により、関連する ID と作成者ドメインが正確に比較されます。両方が同じ組織ドメインの下にあるというだけの理由で、異なる名前を使用することは許可されません。

境界調査ではどのような証拠を保持する必要がありますか?

From、 SPF 、 DKIMドメイン、関連するDNS応答、選択したポリシー、検出モデル、調整結果を、タイムスタンプと影響を受けるサービス所有者とともに保存します。

[ 情報源 ]

情報源

  1. RFC 9989 : DMARCコア プロトコル

[ 用語集 ]

用語集

組織ドメイン
適用可能なDMARC検出および緩和された調整ルールによって使用されるドメイン境界。最後の 2 つのラベルを取得しても、常に見つかるとは限りません。
著者のドメイン
DMARC評価する、メッセージに表示される From アドレスのドメイン。
DMARCアラインメント
表示される From ドメインと、渡されるSPFまたはDKIM ID との間に必要な関係。厳密な調整には、ドメインの正確な一致が必要です。緩和された調整では、該当する組織ドメインの関係が使用されます。
権威DNS
関連するパブリック ゾーンを担当する委任サーバー。別のプロバイダーの非アクティブなパネルを編集しても、回答は変わりません。

企業の来歴

一流の金融機関と政府が選ばれる理由 電子メール セキュリティ ダッシュボードを廃止しました。

従来の電子メール認証プラットフォームはダッシュボードを販売し、エンジニアに作業を依頼します。一か八かの環境では、手動による監視は適用の遅れ、構成のドリフト、および監視されていないシャドウ ドメインを意味します。

EmailAuthは、エージェントの電子メール来歴プラットフォームです。 当社のエージェントが執行します p=reject、サードパーティの送信者を調整し、ドメインを完全に移動します。 RFC 9989 新しいDMARC標準に準拠し、人間による監査機能を備えています。

政府 大企業 ティア1金融機関

SaaS · 専用テナント · エアギャップオンプレミス · BYOK 暗号化

ナレッジベース