DNSを変更せずに Windows DNSツールを使用する
Windows nslookup は、サポート オペレーターがDNSコントロール パネルを開かずに認証の依存関係を検査するのに役立ちます。有用な出力は、特定の名前とレコード タイプに対する帰属可能な回答です。見慣れたドメイン名が含まれるスクリーンショットだけでは十分ではありません。サーバー、質問、時間を記録し、その観察結果が調査中のメール ID とどのように関連しているかを説明します。
このガイドは、2026 年 11 月 8 日にレビューされた、Windows 11 および Windows Server 2025 用の Microsoft の nslookup ドキュメントを対象としています。同じコマンド名を使用した Unix 実装の動作をカバーしているとは主張しません。すべての例は、提案された読み取り専用DNSクエリです。この記事では何も実行されませんでした。ドキュメントのアドレスとexample.com名は、承認された調査内でのみ置き換える必要があります。
コマンドの前に所有者名を選択してください
依存関係を特定する正確なメッセージまたは送信者の構成を尋ねます。 SPF 通常は、表示される From アドレスとは異なる可能性があるSMTP ID に関係します。 DKIM を使用します セレクタ 署名内の署名ドメインを使用してキーを見つけます。 example.com TXTを検索すると、その下にある考えられるセレクターがすべて検査されるわけではありません。 RFC 7208 RFC 6376
ポリシーチェックについては、 _dmarc.example.com. は調査対象の明示的な所有者であり、検証者が必要とする可能性のある唯一のポリシー検出クエリであることを証明するものではありません。認証の検出を維持し、 アライメント メール所有者との結論。サポート チケットは、早まって宣言することなく、 DNS回答を正確に報告できます。 DMARC 合格。 RFC 9989
提案された名前はピリオドで終わります。 Microsoft のドキュメントでは、ターミネータのない名前はドメインと検索設定の影響を受ける可能性があると説明しています。これは、サフィックス構成によって意図しない質問がもっともらしいものに見える可能性がある企業 Windows システムに特に関係します。記憶から再入力するのではなく、正確なスペルを保持してください。 Microsoft nslookup
チケットに対して単一の明示的なクエリを優先する
提案されたワンショット クエリは次のとおりです。 nslookup - type=TXT _dmarc.example.com 。 192.0.2.53。最後の引数はDNSサーバーの名前を指定します。省略するとデフォルトのサーバーが使用されます。ここのアドレスはドキュメントのプレースホルダーであり、使用可能な推奨事項ではありません。一致するDKIM質問は次のとおりです。 nslookup - type=TXT selector1._domainkey.example.com 。 192.0.2.53、認可された証拠から実際のセレクターを取得した後。 Microsoft nslookup
UTC タイムスタンプ、Windows のエディションとビルド、アクティブなネットワーク コンテキストを個別に記録します。テキスト値だけでなく、結果全体を含めます。観察の間に VPN またはアダプターの変更が発生した場合は、それを記録します。これらのクエリは別のパスをたどった可能性があります。広範なサポート バンドルでは無関係な内部名とアドレスが明らかになる可能性があるため、ネットワーク構成の関連部分のみを共有してください。
使用 nslookup - type=NS example.com 。 192.0.2.53 についての質問案として ネームサーバー 記録。結果は、選択された再帰サーバーが権限があることを証明するものではなく、権限を識別するための 1 つの入力として扱われます。未検証のスクリーンショットから取得したアドレスは、ドメインと送信元を確認せずに次のクエリの宛先として使用しないでください。
追加の詳細が必要な場合は対話モードを使用してください
いくつかの関連質問が必要な承認済みの調査の場合、提案されるエントリは次のとおりです。 nslookup - 192.0.2.53。対話型プロンプトで次のように入力します。 type=TXTを設定します、 それから デバッグを設定する、 それから _dmarc.example.com.、そして最後に 出口。それぞれは個別の入力です。これらの命令は出力されず、実行されたセッションも示しません。 Microsoft では、タイプ設定とデバッグ モードを個別に文書化しています。 Microsoft セットタイプ Microsoft がデバッグを設定
デバッグ モードでは、パケットと応答の詳細を解釈できるようになります。ゾーンを変更したり、答えを証明したりするものではありません。実際の出力が提供する応答ステータス、フラグ、TTL、および権限情報をすべて保持します。証拠が不十分な場合には、 DNSSEC または委任の結論では、期待とのギャップを埋めるのではなく、より適切な診断キャプチャを求めます。
レコードタイプを変更するときは、意図的に質問をリセットしてください。よくあるサポート エラーは、以前の設定が適用されなくなったと想定して対話型セッションを続行することです。セッション履歴を再構築せずに他のオペレータが理解できる再現可能な例がチケットに必要な場合は、新しいワンショット コマンドを使用してください。
ラベルと失敗をコンテキスト内で解釈する
権威のない答えが自動的に間違っているわけではありません。これは、キャッシュされたデータを含む通常の再帰応答である可能性があります。権威ある応答は、エンドツーエンドの認証結果ではなく、別の有利な立場を確立します。 DNSヘッダーの権限フィールドとステータス フィールドには応答が記述されており、その意味は返されるTXTテキストとは区別しておく必要があります。 RFC 1035
Microsoft は、タイムアウト、選択したタイプのレコードなし、存在しないドメインおよびサーバー障害を識別します。インシデント内ではこれらのカテゴリを分離してください。タイムアウトにより、即時作成ではなく、到達可能性とサーバー応答の調査が保証されます。 TXTレコード。結果がレコードなしの場合は、変更を検討する前に正確な所有者とタイプを確認する必要があります。 Microsoft nslookup
セレクターが CNAME、エイリアスを保持し、適切な所有者のスコープでそのターゲットを調査します。 TXTテキストが引用符で囲まれた文字列に分割されている場合は、元のレコードの境界を保持します。個別のリソース レコードをサイレントに結合する貼り付けられた文字列は、構成エラーを隠したり、構成エラーを作り出したりする可能性があります。 RFC 1035
比較と誠実な引き継ぎで終了
架空のサポート結果では、企業の再帰サーバーと検証された機関が、記録された時点で同じTXT所有者に対して異なる値を返したという可能性があります。これにより、キャッシュまたはビューのさらなる調査がサポートされます。リモート メールボックスがどの値を使用したかを確立するものではなく、 DNS所有者のレビューなしにゾーン編集を正当化するものでもありません。
nslookup をキャッシュのメンテナンスとは別にしてください。ルックアップはローカル キャッシュのフラッシュではありません。 Microsoft の別の ipconfig ユーティリティにその操作が記載されています。結果が不都合であるという理由だけで、読み取り専用調査に変更コマンドを追加しないでください。 Microsoft ipconfig
完成したチケットには、正確なクエリ、実際の応答、タイムスタンプ、ID、および残りの質問が含まれている必要があります。ここではそれらの運用上の観察が存在しないため、出版物の証拠は不完全なままです。ドキュメントと照合して構文をチェックすることは準備として役立ちますが、オリジナルのクエリ ゲートを満たすことができるのは、承認された実際のキャプチャだけです。