「いいえ」 DMARCレコード 「見つかりました」という警告は診断の開始点です。これは、本当に欠落しているポリシー、間違った名前のクエリ、非アクティブなDNSアカウントの編集、キャッシュされた古い回答、または解決の失敗を反映している可能性があります。
別のレコードを公開する前に、ツールが何をクエリしたか、およびその回答をどの権威サーバーが制御しているかを確認してください。 DNS応答コードと返されたTXTデータを保存します。これにより、不在レコードと 記録 存在しますが、特定の検索パスからは取得できません。
失敗したルックアップを正確にキャプチャする
可能な場合は、ツール、クエリされたドメイン、タイムスタンプ、リゾルバー、および完全なDNS応答を記録します。編集する前に、現在のポリシー レコードとDNS構成を保存します。
これらの BIND dig コマンドの例は、ここでは実行されません。ドキュメント名を承認されたターゲットと実際の委任サーバーに置き換えます。の BINDディグマニュアル サーバー、名前、タイプ、およびクエリのオプションを定義します。権限セクションは、否定的な回答のコンテキストを保持するのに役立ちます。コメントはヘッダーのステータスとフラグを保持します。表示されている From ドメインに対する簡単なクエリ example.com ここから始まります:
_dmarc.example.comを掘ります。 TXT +noall +回答 +権限 +コメント回答セクションだけでなく回答ステータスも保持します。短い表示のみでは、関連するTXTデータを持たない名前と解像度エラーとの区別が隠される可能性があります。
パブリックDNS応答を誰が管理しているかを特定する
この問題は多くの場合、所有権の問題になります。企業は、あるプロバイダーからドメインを購入し、Web サイトを別の場所に移動し、 DNS 3 番目のアカウントに委任した可能性があります。間違ったパネルにレコードを追加すると、完全に見えても、パブリック電子メールのチェックには影響を及ぼさない可能性があります。
オペレーターに、現在の権限のあるDNSホストを特定し、目的の名前に対する答えを示すように依頼します。公開パスが明示されていない場合は、繰り返しの修正に対して料金を支払うことを避けてください。また、警告がメイン ドメイン、送信サブドメイン、またはアプリケーションで使用される別の ID に関するものであるかどうかも確認してください。
名前と公開アカウントを確認してください
ゾーンの権限のある委任 (存在する場合は個別に委任された子ゾーンを含む) を確認します。実際の名前を使用して、関連する権威サーバーを直接クエリします。
@ ns1.example.net _dmarc.example.comを参照してください。 TXT +norecurse +noall +回答 +権限 +コメントDNSエディターがゾーンを自動的に追加する場合は、次のように入力します。 _dmarc.example.com 誤って公開してしまう可能性がある _dmarc.example.com.example.com。別のエディタでは、のみを入力します _dmarc 間違っているかもしれない。すべてのプロバイダーに同じ入力形式を規定するのではなく、最終的に公開された所有者名を確認してください。
他によくある間違いとしては、次のようなものがあります。 TXTレコード ドメイン ルート、非アクティブなDNSアカウントの編集、保存されていない変更、または間違った送信ドメインの検索。
欠席と検索失敗を区別する
- 観察: NXDOMAIN ;調査内容: クエリされた名前は存在しないと報告されます。
- 観察: 関連するTXTデータがない NOERROR。調査内容: クエリされた名前の応答には該当するTXT回答がありません。
- 観察: SERVFAIL ;調査内容: 解決に失敗しました。権限、委任、検証、依存関係を検査する
- 観察: 権威ある答えは存在しますが、再帰的な答えは異なります。調査対象: キャッシュの状態、リゾルバーのビュー、委任パスとタイミング
- 観察: いくつかの候補者の政策記録。調査対象: 単純なレコード欠落状態ではなく、レコードセットの問題
DNSステータスと否定応答の区別については、「 RFC 1035 §4.1.1, RFC 2308 §2.1 そして RFC 2308 §2.2。 SERVFAIL別のレコードを公開する許可として扱わないでください。レコードは存在する可能性がありますが、失敗した解決パスでは使用できません。同様に、子名のレコードが欠落していても、受信者が適用可能なポリシーを他の場所で見つけられるかどうかは決まりません。 RFC 9989 §4.10.1.
実際の例: レコードは非アクティブなゾーンにあります
この調査例を考えてみましょう。管理者が追加 _dmarc レジストラのDNSパネルに送信します。ただし、パブリック委任は、以前の Web サイトの移行中に使用された別のDNSホストを指します。
レジストラのパネルには、意図した値が表示されます。現在委任されている権限に直接クエリを実行しても、その権限は返されません。それ以上待っても、非アクティブなゾーンを権限のあるゾーンにすることはできません。
修正は、適切な承認を得て、実際の当局を通じて公開することになります。その後、信頼できる回答を保持し、再帰的な観察を比較します。以前のパネルを有効にするためだけにネーム サーバーを変更すると、無関係な Web およびメールの記録が中断される可能性があるため、これは別個の、より広範な変更となります。
信頼できる回答とキャッシュされた回答を比較する
下 RFC 2308 §5、リゾルバは以前の否定的な応答をキャッシュできます。したがって、新しい信頼できるレコードは、再帰的な欠損観察と一時的に共存する可能性があります。ラップトップのキャッシュをフラッシュしても、外部受信機のリゾルバー状態はクリアされません。
権威と関連する再帰的観察をタイムスタンプと比較します。権限のあるサーバーが一致しない場合は、その公開状態を調査してください。内部DNSとパブリック DNS が異なる場合は、外部メール受信者がどのビューを使用するかを確立します。
すべての答えが一定の分数後に収束すると約束することは避けてください。実際のパスを診断し、証拠をキャッシュします。
公開プロセスを修正する
不明瞭なDNS責任、放棄されたアカウント、または管理されていない委任が明らかになった場合は、その結果を制御所有権の問題として扱います。誰が変更できるか、どのゾーンがアクティブになっているか、2 番目のレビュー担当者が結果をどのように検証したかを記録します。
ポリシーの欠落の観察は、構成の検出結果です。ということは確立されていません。 フィッシング キャンペーンは成功しました。すべてのサブドメインにポリシーがないか、すべての受信メッセージが失敗しました。 DMARC。これらの結論を分けて保管し、それぞれに必要な証拠を収集してください。
ポリシーと実際のメッセージを確認する
意図した修正を行った後、該当するポリシーの検索を確認し、関連するサービスを通じて実際の正当なメッセージをテストします。信頼できる認証結果を検証し、 アライメント.
使用 レコード作成ワークフロー 新しいポリシーが実際に必要なとき。ポリシーが表示されていてもメールが失敗する場合は、次の手順に進みます。 アライメント診断。古いガイドと新しいレシーバーが検出時に異なる場合は、次の内容を含めます。 DMARCbis準備状況 捜査中。
実践的なポイント
修正された公開パスとその結果として得られる信頼できる回答を使用して、結果を閉じます。次に、該当するポリシーと実際の正当なメッセージを確認します。これにより、説明のつかないチェッカー結果ではなく、再現可能な診断が得られます。
決定と証拠を分けて保管する
非アクティブ・ゾーン・フィクスチャの場合は、提案された公開ターゲットとしてアクティブな権限を選択します。単に廃止されたパネルを関連付ける目的で委任を変更しないでください。返されたテキストだけでなく、権威ある回答フラグと完全な応答コンテキストを検査します。 RFC 8767 §4 TTL の有効期限を超えて古い回答を限定的に使用することを許可するため、TTL は普遍的な収束期限ではありません。ルックアップや構成変更は実行されませんでした。