受信者が確認する ID から始めます
電子メール認証の変更は名前から始まります。 記録 タイプと責任のあるオペレーター。 「ドメインに認証を追加する」という内容は範囲が広すぎて、正しいDNSエディターや受信者が必要とする答えを特定できません。マーケティング サービスは、1 つのドメインで署名し、 SMTPエンベロープに別のドメインを使用し、[差出人] フィールドに 3 番目のドメインを表示する場合があります。インベントリでは、ゾーンを編集する前にこれらの差異を保存する必要があります。
のために SPF、 SMTPで使用されるドメインを取得します。 メール送信元 身元;の HELOアイデンティティ null 逆パスの場合を含む独自のチェックがあります。該当するドメインのTXTをクエリします。表示されている From アドレスを読み取るだけでSPF所有者を選択しないでください。 RFC 7208 、セクション 2.3 ～ 2.4 および 3.1.
のために DKIM、取ってください セレクタ から s= および署名ドメイン d= 署名の中で。キー検索名が selector の場合、 _domainkey、次に署名ドメイン。のために DMARC、ポリシー検出は以下のTXTクエリから始まります。 _dmarc 作成者ドメインで、指定されたドメインを引き続き使用できます。 DNSツリーウォーク。初期レコードが存在しないこと自体は、ポリシーが適用されないことを証明するものではありません。 RFC 6376 、セクション 3.6.2; RFC 9989 、セクション 4.5 および 4.10.
所有者名を変更の所有者から分離する
DNSでは、レコードの所有者はドメイン名です。変更チケットでは、多くの場合、その所有者は個人またはチームです。両方を記録します。ドメイン レジストラ、権限のあるDNSホスト、送信プラットフォーム管理者、および承認するドメイン所有者は、別の当事者であってもかまいません。登録アクセスは、特定のDNSコンソールが今日の公開回答を制御しているという証拠にはなりません。
要求された名前を含むゾーンの委任された権限サーバーを特定します。サブドメインには独自の委任がある場合があるため、正しいエディターが親ドメインのエディターとは異なる場合があります。ゾーン、完全な所有者名、要求されたタイプ、提案されたデータ、および責任のあるオペレーターをまとめて保管します。 DNS委任は、権限が変更される場所を定義します。組織のサポート チームの境界に従いません。 RFC 1034 、セクション 4.2 および 4.2.1.
送信者の管理者に、アカウント発行の値を提供し、エイリアスについて説明するよう依頼してください。プロバイダーの CNAME 命令は名前を別の名前に向けます。これは、NS レコードを使用して子ゾーンを委任するのと同じ操作ではありません。エイリアス ターゲットを誰が管理しているか、また顧客側のレコードを変更できるのは誰かを把握します。
編集者の外観ではなく、公開されたレコードセットを読む
DNSコンソールは多くの場合、相対ホスト ラベルを受け入れ、ゾーン名を追加します。したがって、コピーされた完全修飾名が間違ったモードで入力されると、意図しない所有者に渡される可能性があります。すべてのサブドメインとアンダースコア ラベルを含む、最終的な絶対名を確認します。編集者が保存した値は準備の証拠です。権威あるDNS回答は出版物の証拠となります。
TXTプレゼンテーションにも注意が必要です。 1 つのTXTリソース レコードには複数の文字列が含まれる場合があります。 SPFの場合、これらの文字列はスペースを挿入せずに連結されます。それは2つを別々に出版するのとは異なります SPFレコード 同じ所有者での使用は禁止されています。エクスポートまたはスクリーンショットを確認するときに、引用符を数えるのではなく、レコードの境界を保持します。 RFC 1035 、セクション 3.3.14; RFC 7208 、セクション 3.2 ～ 3.3.
MXレコード メールを受信するためのメール交換者を識別します。これらは、どの送信サービスが許可されているか、またはどのキーがメッセージに署名しているかを独立して証明するものではありません。 SPFポリシーはメカニズムを通じてMXを参照できますが、その関係はすべてのメール関連のDNSレコードが送信を認証するという仮定からではなく、実際のポリシーから得られる必要があります。 RFC 1035 、セクション 3.3.9; RFC 7208 、セクション 5.4.
架空の所有権の目録を調べる
架空のサービスが From でメールを送信するとします。 news@example.com、からのメール bounce@mail.example.com、そして DKIM署名 含む d=example.com; s=nov26。最初のインベントリには 3 つの個別のTXT質問があります。 mail.example.com, nov26._domainkey.example.com、 そして _dmarc.example.com。これらは例示的な名前と ID であり、観察されたメッセージや推奨される実稼働値ではありません。
電子メール管理者は、目的のルートとセレクターを確認します。 DNS管理者は、各名前がどのゾーンに含まれているか、およびプロバイダーに必要なエイリアスによってルックアップ パスが変更されているかどうかを確認します。ドメイン所有者がスコープを承認します。セレクターがベンダーによって発行された場合、ベンダーは対応する秘密キーを保持する必要があります。 DNSには公開鍵マテリアルのみが属します。秘密キーをチケットや公開TXTレコードにコピーしてはなりません。
インベントリー行では、「サービスによって提供される」、「権威DNSに存在する」、および「受信メールで観察される」を区別する必要があります。これらの列の 1 つを不明なままにしておくほうが、単一の「認証済み」ボックスを途中でチェックするよりも便利です。
変更を閉じる前に証拠を収集する
提案されているチェック項目は、 @AUTH_IP nov26._domainkey.example.comを掘ります。 TXT +norecurse そして @RESOLVER_IP nov26._domainkey.example.comを掘ります。 TXT。大文字のプレースホルダーを承認されたエンドポイントに置き換えます。実際の所有者と関連する権威サーバーごとに繰り返します。 UTC 時間、サーバー アドレス、質問、応答コード、フラグ、回答および権限セクション、TTL、およびエイリアス チェーンを保持します。この記事ではこれらのコマンドは実行されていません。
権限と再帰が一致しない場合は、重複レコードを追加する前に、パブリケーションの一貫性、キャッシュ、およびリゾルバー パスを調査してください。 DNS応答は依然として、署名の検証、 SPF実際の送信 IP の承認、またはDMARC調整を証明できません。これらの質問は、制御された受信メッセージと信頼できる受信者の結果で解決します。タイムスタンプの付いた信頼できる再帰的な転写物は、この文書草案の原本証拠の扉として開かれたままです。