TransIP が権限があることを確認する
これはDNS公開ガイドであり、TransIP メールサービスのオンボーディング ガイドではありません。ドメインは、権限のある状態で TransIP に登録できます。 ネームサーバー 他の場所にあります。編集する前に、ドメインのパブリック委任を確認し、権限のあるゾーンを特定してください。 DNSフォームにアクセスできるようにするためだけにネームサーバーを切り替えないでください。既存のゾーンのエクスポートと承認された変更範囲とともに、送信者の正確なレコード名、タイプ、および値を取得します。
名前と値を正しく入力してください
コントロール パネルでドメインを選択し、 DNS設定を開きます。カスタム編集では、自動 TransIP 設定をオフにする必要があります。これらの設定を再度有効にすると、カスタム レコードとネームサーバーが上書きされる可能性があります。 [名前] フィールドでは、ゾーンの頂点には @ を使用し、サブドメインには相対名を使用します。外部 CNAME target にはフルネームと末尾のドットが必要です。これらのインターフェイス ルールは、以下の TransIP コントロール パネルのソースに文書化されています。
TXTの場合 DKIM キーを使用すると、 DKIMソースは、周囲の引用符と不要なバックスラッシュを省略するようにユーザーに指示します。生成されたサンプルではなく、送信者の公開キーを使用してください。あ セレクタ 送信サブドメインでは、相対所有者名にそのサブドメインが必要です。 CNAME 、送信者が実際にCNAME委任を発行した場合にのみ使用してください。キーを公開しても、送信サービスの署名は開始されません。
オリジナルのレコードマッピングワークシート
以下は、実稼働構成ではなく、 example.orgゾーンの架空のマッピング演習です。 DKIM所有者の完全なreview._domainkey.news.example.orgがレビューにマップされます。 [名前] フィールドに_domainkey.news 。あ DMARC 所有者_dmarc.news.example.orgは_dmarc.news.の SPF 所有者news.example.orgはニュースにマップされます。レビュー担当者が偶発的なexample.org.example.orgサフィックスを検出できるように、変更チケットに予想されるフルネームをマークします。
SPFとDMARC TXTポリシーとして正しい所有者名で保持します。クラスとタイプを含む完全なゾーンファイル行を「値」フィールドに入力しないでください。複数 TXTレコード 無関係な目的で共存できますが、1 つの評価名に対する 2 つのSPFポリシーは無効です。長いDKIM値は慎重に処理する必要があります。取得された TransIP ページは、普遍的な長い文字列の分割手順を確立していません。パネルがプロバイダーの完全な値を拒否した場合は、それを切り捨てるのではなく、停止して現在の TransIP ガイダンスを取得します。
メールをテストする前にパブリケーションを確認する
各権威サーバーに完全なSPF 、 DMARC 、およびセレクター名を問い合わせます。返された場合、連結されたTXT文字列を含む完全な値を比較します。委任されたキーの場合は、 CNAMEターゲットと最終的なTXT応答を確認します。再帰リゾルバを介して繰り返し、TTL 観察を保持します。コントロール パネルが正しく表示され、公開された回答が存在しない場合は、単に伝播が遅いだけでなく、間違った権限やデータが保存されていないことを示している可能性があります。
その場合にのみ、送信サービスを通じて制御されたメッセージをトリガーします。 DNS 側のロールバックでは、自動設定を再度有効にしたり、無関係な変更を比較せずに古いゾーン全体を復元したりするのではなく、変更されたレコードを復元する必要があります。
受信側で身元を証明する
制御された外部メールボックスを使用し、無害なコンテンツと顧客データを含まない運用ワークフローを通じて送信します。生のメッセージ、タイムスタンプ、受信システムのデータを保存します。 Authentication-Results。信頼できない送信者によって挿入された認証アサーションを無視します。表示されている From ドメインを記録します。 Return-Path または認証されたエンベロープ ID、およびすべてのDKIM d= および s= ペア。表示名または返信先アドレスはDMARC ID ではありません。
SPFパスは、評価されたエンベロープ ID に対して接続サーバーを承認します。 DKIMパスは、その署名ドメインの署名を検証します。 DMARCは、ドメインが表示されている From: strict と一致する受け渡しメソッドが必要です。 アライメント 同じドメインが必要です。緩和された調整により、適切な組織とドメインの関係が可能になります。プロバイダーが所有する署名は、表示されている From を認証せずに渡すことができます。 1つのパスが揃った DKIM署名 別の署名が失敗した場合でもDMARC満たすことができます。これらのプロトコル ルールは、 RFC 7208 、 RFC 6376 、および RFC 9989、以下にリストされています。
キャッシュを診断する前に、権威DNSを確認してください。権威サーバーに正確な名前とタイプを問い合わせて、キャッシュされた有効期間の経過後に再帰的リゾルバーを比較します。 DKIMの場合は、任意のCNAMEをたどって公開鍵TXT応答を取得します。秘密キーは決して公開しないでください。評価された名前ごとに 1 つのSPFポリシーを保持し、ネストされたインクルード全体で 10 個の DNS ルックアップの原因となる用語の制限を確認します。共有SPFポリシーをプロバイダーの例に置き換えないでください。
回復と受け入れ
テストで新たな後退が示された場合は、影響を受けるワークフローを一時停止します。変更されたレコードを保存されたバージョンと比較し、他の送信者を確認した後、その変更のみを元に戻します。 DNSを再チェックし、回復後に再送信します。値を元に戻しても、すべてのリゾルバーがすぐにフラッシュされるわけではありません。セキュリティインシデントによって取り消しが必要になる場合を除き、以前に署名されたメッセージがまだ転送されている可能性がある間は、古いDKIM検証レコードを利用可能な状態に保ちます。
DNS 、アプリケーションの状態、および実際に受信したメッセージが一致する場合にのみ、変更を受け入れます。フローの所有者、証拠のタイムスタンプ、および次のレビューのトリガーを記録します。受信箱の配置だけでは認証の証明にはならず、認証が成功しても受信箱の配置が保証されるわけではありません。 1 つのプロバイダーのテストの強度に基づいて、共有ドメインのDMARCポリシーを強化しないでください。最初に他の正当なソースのインベントリを作成します。
正しく見えるエントリが間違ったゾーンにあると診断する
文書化されたケース TI-01 では、ドメインが TransIP に登録されていると想定していますが、そのパブリック委任は別のDNSオペレーターを指しています。レビュー用に保存された TransIP パネルのエントリ。 _domainkey.news review._domainkey.news.example.orgでの公開を確立しません。ドメイン所有者は、権限のある運営者を確認し、そこで承認された記録を手配する必要があります。ネームサーバーを変更したり、自動設定を有効にしたりすることは、修正の近道ではありません。公開された回答、送信されたd=/s=および受信者の結果は、個別に収集されるまで不明です。このシナリオは規定されており、実際のDNSルックアップやパネル アクションではありません。
施行境界を維持する
RFC 9989セクション 7.4 ではp=reject,公開するドメインに対してSPFのみではなく有効なDKIM要求し、間接メールとメーリング リストの相互運用性について警告しています。ダイレクト メッセージ テストが 1 回成功しただけでは、すべての正当なルートがより強力なポリシーに対応できるようになっているという証拠にはなりません。実際のギャップを診断しながら、既存の承認された保護を維持します。政策変更には独自の決定が必要です。