認証の範囲をメールボックスと両方の配信パスに設定
Helprace のドキュメントでは、独自の送信サービスとオプションのカスタムSMTPルートのメールボックス固有の設定について説明しています。重要な運用上の詳細はフォールバックです。カスタムSMTP送信できない場合、Helprace は独自のメール サーバーにフォールバックすると述べています。したがって、優先SMTPサーバーのみを対象とする受け入れ計画は、文書化された取り決めとしては不完全です。どのDNS認証が必要かを決定する前に、メールボックス ドメイン、通常の送信者、およびフォールバックの責任を特定します。
の カスタムSMTPガイド 「設定」、「チケット」、「メールボックス」の構成について説明します。この記事では、 SMTP統合の作成、資格情報の入力、アカウント セキュリティの変更は行いません。保持されているページには、このガイドの実装範囲外である従来のGmail認証手順が含まれています。外部SMTPプロバイダーの現在の認証サポートには独自のレビューが必要です。 DNSチェックが成功しても、サードパーティのSMTPログイン方法が引き続き利用可能であるかどうかを確認することはできません。
両方のDKIM CNAMEレコードを公開します
の Helprace DKIMガイド 関連するメールボックスを開いて展開するように管理者に指示します。 DKIM セクション。 2 つ提供されます CNAME レコードを記録し、適切なローテーションのために両方を明示的に要求します。その例では helprace1 を使用します。 _domainkeyと helprace2。メールボックス ドメインの下の_domainkey 、対応するプロバイダーがホストするターゲットを指します。現在のメールボックスの表示された構成を使用し、どちらか一方のみを公開するのではなく、両方の依存関係を保持します。 セレクタ 観測された 1 つのメッセージに偶然現れました。
現在の署名者が最初のセレクターを使用しているという理由だけで、2 番目のセレクターは冗長ではありません。文書化されたローテーション要件はプロバイダーの前提条件であり、引き続き厳格に受け入れられる項目である必要があります。いずれかのレコードを追加する前に、提案された所有者の既存のデータを確認し、それに依存する他のサービスを特定します。承認された移行計画なしにアクティブなキーまたはエイリアスを上書きしないでください。公開所有者とターゲットを変更記録に保存します。私的な署名資料は必要ありません。
このガイドでは、一部のDNSパネルは相対ラベルのみを受け入れますが、他のパネルでは完全な名前が必要であることが記載されています。結果の完全修飾所有者を目的のメールボックス ドメインと比較して、サフィックスの重複を回避します。オプションの TTL の例として 3600 秒が示されています。これは、すべてのリゾルバーがちょうど 1 時間後に変更をすぐに観察するという証拠ではありません。承認された変更が行われたときに、既存の TTL と実際に公開された値を確認します。
メールボックスのテスト結果を 1 つのチェックポイントとして使用する
ガイドには、公開後、メールボックスに戻って [テスト] を選択するように記載されています。緑色のチェックマークは、プロバイダーの構成チェックが成功したことを示します。要求されたDNS変更、公開された記録、およびプロバイダーの観察を明確な証拠として保管してください。チェックの成功は役に立ちますが、すべての通常メッセージまたはフォールバック メッセージが受信者に有効な調整された署名を伝えていることを証明するものではありません。
チェックが失敗した場合は、発行された両方の CNAME を権限のあるゾーンと比較し、選択したメールボックス ドメインを確認します。ターゲットが間違っているか、2 番目のレコードが欠落している場合は、公表されている最長の伝播推定値をただ待つだけではなく、修正が必要です。すべての障害を一般的な DNS 遅延診断にまとめるのではなく、正確な状態と時間を記録します。この原稿では、テスト制御、 DNSクエリ、メールボックス設定は実行されていません。
RFC 6376 、セクション 3.5 実際の署名に含まれる署名ドメインとセレクターを定義します。これらのフィールドを個別に承認された受け入れ手順で使用して、どのキーが使用されているかを判断します。公開キーの場所の存在だけからアクティブな署名を推測しないでください。 DNS検証を準備します。送信側システムは、実際のルートから離れるメッセージに対して適切な署名を生成する必要があります。
文書化されたフォールバックのためにSPF認証を保持する
の SPF設定ガイド 管理者をカスタム メールボックスに誘導します。 SPF セクションに、提案されるポリシーが表示されます。これはinclude:spf.helprace.comを文書化し、既存のポリシーの更新と新しいポリシーの追加を区別します。ページの例示的なポリシーに置き換えるのではなく、既存の送信者インベントリ全体を確認してください。このページには、 SPFが非推奨の専用SPFリソース レコード タイプではなくTXTとして公開されていることが正確に記載されています。
ソースにはSMTP障害時の Helprace へのフォールバックが記載されているため、カスタムSMTPが構成されているという理由だけで Helprace 認証を削除しないでください。文書化された動作が現在のアカウントに適用されるかどうか、およびフォールバック ルートが使用する ID を記録します。排他的なメール ルートを必要とする組織は、設定が排他性を保証すると仮定するのではなく、展開前にプロバイダーおよび独自のポリシー所有者とフォールバック要件を解決する必要があります。
RFC 7208 、セクション 2.4、3.2、および 4.6.4 特定する メール送信元 ID、複数の SPF レコードの動作、および評価された DNS に依存する期間制限。正しいポリシーは、自動的に表示されるメールボックス アドレスではなく、実際のエンベロープ ID に対するポリシーです。ネストされた依存関係を確認し、関連する所有者で 1 つの一貫したポリシーを保持します。 SPF認証は、 SMTP資格情報の有効性を確立したり、ネットワーク ルートを作成したりしません。
プロバイダーの推奨事項をDMARCセマンティクスから分離する
Helprace はDKIMとSPFを推奨しており、そのフォールバックの議論では、許可された送信者として Helprace を維持することが強調されています。これらの運用に関する推奨事項は、次のような普遍的な主張に変換されるべきではありません。 DMARC 常に両方のメカニズムが通過する必要があります。 RFC 9989 、セクション 4.4 は、passing aligned 認証メカニズムが認証条件を満たすことができると説明しています。目に見える著者ドメインとの関係は不可欠です。無関係な受け渡しアイデンティティは確立されない アライメント.
プロバイダーのページには、広範な配信保証も含まれており、「経由」表示ラベルについても説明されています。ラベルの有無は、完全な認証判定ではありません。受信者のプレゼンテーション、フィルタリング、およびローカル ポリシーは異なる場合があります。 SPFを発行することで実質的にスパム フィルターの回避が保証されることや、グリーン プロバイダー チェックによって受信トレイの配置が確立されることを約束しないでください。認証、メッセージの受け入れ、ユーザーに表示される配信を個別に評価します。
通常パスとフォールバックパスを安全に確認する
提案された受け入れマトリックスには、目的のSMTPパスの行と、文書化された Helprace フォールバックの別の行が必要です。承認された監視ごとに、メールボックス ドメイン、ルート、作成者ドメイン、エンベロープ ID、署名ドメイン、セレクター、および信頼できる受信者の結果を保持します。フォールバック テストを強制するためだけに、本番SMTP意図的に中断しないでください。制御された障害の実行には、独自の制限された計画、承認、および非実稼働またはその他の安全な範囲が必要です。
無害なテスト コンテンツを使用し、診断データを最小限に抑えます。サポート チケットには、パブリック チェッカーに属さない個人情報、資格情報、または機密の添付ファイルが含まれる場合があります。会話全体をコピーするのではなく、承認された証拠への参照を記録します。フォールバックが安全に観察されなかった場合は、優先ルートのサンプルからその動作を推測するのではなく、その行に未検証のラベルを付けます。ここでは実際のチケット、外部アップロード、テスト メッセージは作成されませんでした。
架空の診断と白紙の合格ワークシート
架空のサービス チームである North Quay Support は、通常のメッセージが独自のサーバーから送信されているように見えるため、カスタムSMTPを構成し、Helprace のSPF認証を削除します。その後のレビュー中に、チームはプロバイダーの文書化されたフォールバック動作に気づき、その受け入れマトリックスが優先パスのみをカバーしていることに気付きました。提案されている対応策は、機能停止を引き起こしたり、ドメイン ポリシーをやみくもに緩めたりするのではなく、フォールバック承認と ID 評価を再開することです。これは架空のシナリオであり、実際のアカウント結果やメッセージの証拠はありません。
- メールボックス ドメインと通常のトランスポート: ______
- 文書化されたフォールバックの適用性とポリシー所有者の決定: ______
- 発行されたDKIM CNAME と依存関係のレビューの両方: ______
- 該当するフォールバック認証を含む完全なSPFポリシー: ______
- 権威DNSとプロバイダー テスト証拠: ______
- 現在のカスタム SMTP 認証サポート (シークレットなし): ______
- 通常ルートおよびフォールバックルートの受け入れ行: ______
- 未テストの条件、ロールバック所有者およびリリースの決定: ______
元の実装証拠、人間による対象のレビュー、現在の適用性、生産ルート、視覚的なアクセシビリティ、および所有者の公開は未解決のままです。 DNSレコード、資格情報、メールボックス制御、セキュリティ設定は変更されませんでした。カタログのより広範な実装要件は、実際にサポートされている配信パスに関する承認された証拠に依存しています。