一般的なDNSレシピではなく、自動タスクのドメイン状態から開始します。
Autotask のドメイン設定ドキュメントでは、バージョン 2026.6 が表示されており、送信ドメインの使用許可とオプションの使用許可が分離されています。 DKIM 認証。このページには、リリース 2023.3 以降、送信元アドレスには検証済みのドメインを使用する必要があると記載されています。その製品要件は、一般的な電子メール プロトコルとは異なります。有効に見えるアドレスは、必ずしもアプリケーションが許可するアドレスであるとは限りません。また、許可されたアドレス自体は、受信者における整合性のある認証の証明にはなりません。 自動タスクのドメイン設定
サポートされる範囲には、文書化された Autotask 送信電子メール ドメイン ワークフローが含まれます。無関係なメール サービス、個別に構成されたアプリケーション、または顧客テナント内のすべての通知パスの準備が整っていることは保証されません。何かを変更する前に、実際の環境、影響を受ける送信元アドレス、および責任のある管理者を特定してください。このドラフトでは、アカウント アクセス、 DNS変更、メッセージ テストは実行されていません。
検証の影響を受けるアドレスのインベントリを作成する
プロバイダーは、サポート アドレス、リソース電子メールから送信として使用されるプライマリ ユーザー アドレス、代替送信アドレス、およびテンプレート、ワークフロー ルール、調査、請求書電子メール、連絡先グループに手動で入力されたアドレスを識別します。単一のテスト通知をすべてのビジネス メールの代表として扱うのではなく、これらのカテゴリを確認してください。カタログの受信メッセージ証拠要件は、最終的に承認された正確なルートに引き続き適用されます。 自動タスクのドメイン設定
実際のドメインごとに 1 つのインベントリ行を作成し、使用を送信します。アプリケーションがドメインを自動的に検出したか、管理者がドメインの追加を提案したかを記録します。そのドメインが使用可能なままである必要がある理由を説明できる所有者を割り当てます。廃止された代替アドレスにより、ビジネス プロセスが他の場所に移動した後もドメインを保持するという誤解を招く要件が作成される可能性があります。
プロバイダーは、アクティブ、ドメイン検証済み、 DKIM認証済みのステータスを区別します。そのシステム ドメインautotask.comおよびdatto.comは Kaseya によって構成されており、このワークフローを通じて編集または非アクティブ化することはできません。顧客ドメインの決定は、それらのシステム ドメインのステータスに基づいて行うべきではありません。文書化された顧客のDKIM許容量は 5 つの追加ドメインです。この制限は、他のアドレス カテゴリの存在とは別のものです。 自動タスクのドメイン設定
値を取得する前に管理権限を確認する
文書化された権限は、電子メール通知とアンケートを構成できる管理セキュリティ レベルと、会社のDNSエントリを編集する権限です。ナビゲーションは、「管理者」、「管理者カテゴリ」、「自動化」、「電子メール通知とアンケート」、「ドメイン設定」の順です。固有のドメインを追加するには、「新規」を使用してから「ドメインの追加」を使用し、認証ダイアログを開きます。これらの手順は、提案された承認されたワークフローを説明するものであり、アクセスの許可やドメインが追加されたという主張ではありません。 自動タスクのドメイン設定
アプリケーション管理者とDNS変更承認者の責任が別のチームに属している場合は、これらの責任者を分離します。提供されたすべてのレコードでドメイン コンテキストを保持します。選択したドメインのない値を示すスクリーンショットは、変更の証拠としては弱いです。オペレーターは、提案された所有者名、レコード タイプ、およびコンテンツを、推測することなく、目的のアプリケーション ドメインと照合できる必要があります。
2 つの検証レコードを異なるコントロールとして扱います。
自動タスクの必須検証では、 SPF TXTポリシーとドメイン検証 TXTレコード。後者には、._autotask の前にアカウントが提供するドメイン コードがあります。ドキュメントには、その検証レコードに対するプロバイダー依存のコンテンツの選択肢 (必要に応じて、空白、ピリオド、または単語「名前」) がリストされています。ドメイン コードを発明したり、値が独立して何かを証明していると仮定したり、この所有者名をドメインのSPF所有者と混同したりしないでください。公開する前に、実際のダイアログと DNS エディタの要件を解決してください。 自動タスクのドメイン設定
SPF例にはinclude:autotask.net.プロバイダーは、既存のコンテンツを保持し、このインクルードを長いポリシーの最初の 3 つのエントリに配置し、 -all機能することを認識しながら~allの検証設定を指定するように指示します。これらは製品固有の手順と互換性に関する問題であり、新しいSPFプロトコル ルールではありません。チェッカーを満足させるために既存の失敗ポリシーを黙って弱体化しないでください。競合がある場合は、責任のあるポリシー所有者にエスカレーションし、承認前にサポートされる構成を確立します。 自動タスクのドメイン設定
該当する 1 つのSPFポリシーをその所有者名で保持します。まだ承認されている送信者を保持し、評価パス全体を確認します。 DNS クエリ条件に対するSPFの制限は、すべてのプロバイダーを最初に配置することを推奨するものでも、ネットワーク パケットの単純なカウントを示すものでもありません。並べ替えメカニズムは動作を変更する可能性があるため、表面的な編集としてではなく、完全なポリシーを使用して評価する必要があります。 RFC 7208 、複数のレコードとDNSルックアップの制限
オプションのDKIMと完了した署名を混同しないでください
プロバイダーは、このアプリケーション ワークフローではDKIM認証をオプションとして呼び出します。だからといって、それが組織の認証目標と無関係になるわけではありません。 SPF ID が表示されている From ドメインと一致していないルートには、適切な一致したDKIM結果が必要になる場合があります。 DMARC 通過する。レビュー担当者は、緑色の検証アイコンから識別子を推測するのではなく、実際の識別子を確立する必要があります。 RFC 9989 、識別子のアライメント
保持されている現在のページには、 DKIMステータス、ドメイン制限、認証アクションが説明されていますが、完全な情報は公開されていません。 セレクタ 読みやすい説明書にレシピを記録してください。提案する前に、サポートされているアカウント固有のDKIM詳細を取得してください 記録。古いサードパーティ製品をコピーしないでください CNAME レシピをこのワークフローに組み込み、現在のプロバイダー証拠のラベルを付けます。実際のメッセージ内のセレクターと署名ドメインによってキーの検索が決まります。パブリックDNS値は、その署名構成に対応している必要があります。 RFC 6376 、 DKIM-Signatureとキーの保管
適切な証拠を使用して各レイヤーを検証する
承認されたプロセスを通じて目的のレコードが公開された後、プロバイダーはオペレーターにダイアログを再度開き、「ドメインの認証」を選択するように指示します。そのドキュメントでは、5 分から 48 時間の間隔が考えられることが説明されており、検証エラーとDKIMエラーが区別されます。これらのタイミング ステートメントは、トラブルシューティングのガイダンスとして扱い、待機するだけで不正なレコードやドメイン許容量の超過が修正されることを保証するものではありません。 自動タスクのドメイン設定
パブリックDNS観察をアプリケーションのステータスとは別に記録します。次に、表示される作成者、エンベロープ ID、署名ドメイン、セレクター、および受信者の認証結果を含む、関連するルートごとに承認された受信メッセージの証拠を取得します。アプリケーションの検証結果は、そのメッセージ レベルのテーブルの代わりにはなりません。また、認証は受信トレイへの配置を保証したり、メッセージのビジネス リクエストが安全であることを証明したりするものではありません。 RFC 9989 、スコープと受信者のアクション
架空の診断: 検証は成功しますが、受け入れは失敗します
架空のサービス会社 Fernbridge Support は、2 つのドメインからの請求書とチケット通知を作成します。管理者は、最初のドメインの [ドメインが検証済み] を確認し、両方のルートが完全に認証されていることを報告します。レビュー担当者は、2 番目のドメインのステータスが文書化されておらず、受信メッセージ ID が収集されていないことに気づきました。これは考え出されたレビュー シナリオであり、観察された顧客インシデントではありません。
レビュー担当者は、ドメイン検証、 DKIMステータス、およびルート証拠を個別の行に分割します。最初のドメインの検証は、破棄されたり誇張されたりするのではなく、狭い事実として保存されます。 2 番目のドメインは未解決のままです。どちらのルートでも、リリース前に承認されたメッセージ評価が必要です。この修正は証拠境界の修正です。つまり、あるステータスでは、別のドメインまたは認証の異なる層に対する結果を確立できません。
空白の承認ワークシート
- 製品バージョンとテナントの適用性の確認: ______
- 送信ドメインと影響を受けるアドレス カテゴリ: ______
- アプリケーション管理者およびDNS承認者: ______
- アクティブおよびドメイン検証済みの状態とタイムスタンプ: ______
- アカウント生成の検証所有者と正確な内容: ______
- 既存のSPFポリシーとレビューされた変更案: ______
- 製品検証の制約と組織のポリシー決定: ______
- DKIM許容量、生成された詳細および現在のステータス: ______
- パブリックDNS証拠と信頼できるソース: ______
- 各ルートの受信メッセージ ID テーブル: ______
- ロールバック、主題のレビュー、およびリリースの決定: ______
残りの解放条件
ワークシートは未記入であり、架空の診断は運用上の証拠ではありません。アカウントの適用性、元の実装証拠、人間による対象事項のレビュー、生産ルート、視覚的なアクセシビリティ、および所有者の解放は未解決のままです。ドメイン構文のソース記述と配信の改善は、インターネットの普遍的なルールや保証として採用されていません。最終的な承認の決定には、現在サポートされているテナントのワークフローと、意図されたルートからの実際の証拠を使用する必要があります。