Higher Logic Vanilla の場合、送信者認証を調整されたコミュニティ、サポート、およびDNS変更として扱います。これは、独立してインストールされたオープンソース フォーラムや、別の Higher Logic 電子メール製品に関するガイドではありません。まず、コミュニティとその承認されたパブリック送信者 ID を特定します。通知アドレスは、管理者のプライベート アドレスを誤って公開してはなりません。
サポートされているセットアップを調整する
[ダッシュボード] > [設定] > [通信] > [電子メール設定]、および送信送信者の名前とアドレスを確認します。 Vanilla サポートにこれらの設定を確認し、運用チームを通じてDNSレコードを提供するよう依頼してください。 DNS所有者が提供されたレコードを実装し、サポートがアクティブ化を確認します。公開ガイドでは、 SendGrid送信サービスとして指定されています。また、サポートが次のことを確認する必要があるとも書かれています。 リターンパス ドメイン、およびinclude:vanilla.emailまたはinclude:sendgrid.netが適用されるかどうか。思い込みで両方を承認しないでください。 バニラの送信者認証リファレンス
サポートが提供する、承認された変更を含む所有者名、タイプ、および値のコピーを保管してください。別のコミュニティのセレクターを再利用しないでください。提案された所有者名にすでに CNAME、そこにTXTデータを追加する前に、名前の競合を解決してください。別のメール ID を選択するほうが、コミュニティ Web サイトで使用されるレコードを変更するよりも安全です。
コミュニティ固有の結果をテストする
制御されたテスト アカウントと受信者を使用して、メンバーが実際に購読した通知を実行します。表示される送信者、返信動作、認証を個別に確認します。 Web サイトの読み込みが成功しても電子メールはテストされず、テンプレートのプレビューは通知の実際の送信パスを証明しません。 1 つのヘッダー サンプルを取得するためだけに広範なアナウンスを送信することは避けてください。 1 つの通知クラスが異なる場合は、単一の通過サンプルをすべてのコミュニティ メッセージの証拠として扱うのではなく、そのルートを調査します。
カスタム ドメインCNAMEに関する公開ガイドの警告は、同じDNS所有者名に関するものであり、すべてのカスタム From ドメインに対して禁止されているわけではありません。 Web サイトの記録を保存し、サポートに適切なメール名を特定してもらいます。 DNSがいつ保存されたかだけでなく、誰がいつアクティベーションを確認したかを記録します。
DNSと実際の受信結果を検証する
コミュニティ通知送信者の設定を変更する前に、既存のDNS値をエクスポートし、承認された差分を記録し、ロールバック所有者に名前を付けます。 DNSエディターが相対ラベルまたは完全修飾名を予期しているかどうかを確認します。ドメインサフィックスを2倍にすると、 記録 意図した検証者がそれを見つけることはできません。保存後に、エディターの成功バナーに依存するのではなく、 CNAMEターゲットを含む実際の所有者名を照会します。
SPF 関連するドメインで 1 つのポリシーを維持し、DNS クエリ期間の制限内にとどまる必要があります。 RFC 7208。インクルードを追加するだけでは確立されません アライメント。下 RFC 9989, DMARC 少なくとも 1 つのSPFが成功した場合、または DKIM 結果は、該当するモードで表示される From ドメインと一致します。標準によって課せられる条件として両方のメカニズムを調整する必要はありません。また、プロバイダー ドメイン パスを調整されたカスタマー ドメイン パスと取り違えないようにしてください。
ライブ コミュニティ ワークフローを通じて送信される購読済みコミュニティ通知を、制御するメールボックスに送信します。受信側システムの信頼できる認証結果、表示される From、エンベロープ ID、 DKIM d= および s= 値、タイムスタンプ、プロバイダーのステータスを保存します。 DNSルックアップでは、使用可能なキーのみが表示されます。 RFC 6376 検証では、受信したメッセージの署名も評価します。機密性の低いコンテンツを使用し、顧客メッセージ全体が公開チェッカーに公開されることを避けてください。
制限付きの受け入れとロールバックの決定を使用する
架空の書面による診断ケースのみ: VA-01 は、 community.exampleが Web サイトのCNAMEであり、オペレーターが同じ所有者名にSPF TXTを配置することを提案していると想定しています。意図された通知 From はcommunity@example.orgですが、エンベロープとDKIM ID/結果は不明のままです。コミュニティ所有者はサポートから正確なメール所有者名を取得し、無関係な Web サイトのルーティングを変更せずに Web サイト名の衝突を解決する必要があります。テンプレートのプレビューでは、アクティベーションまたは調整を閉じることができません。この例では、アカウント、 DNS 、リレー、またはメッセージはテストされませんでした。
テストが失敗した場合は、不足しているDNSを分離します。間違っています セレクタ、非アクティブなプロバイダー構成、別の変更を行う前の予期しないルーティングとメッセージの変更。修正が承認されるたびに、同じワークフローを再テストします。単一の送信者の問題を隠すためにドメイン全体のDMARCポリシーを弱めないでください。ロールバックが必要な場合は、承認された以前のルーティングまたは送信者の構成を復元し、キューに入れられた署名付きメッセージがまだ必要な間、キーのレコードを保持します。テストの証拠と未解決の例外をドメイン インベントリに保管します。このガイドを作成する際に、テナント アクセス、 DNS変更、または実際の送信は行われませんでした。
責任ある受け入れ記録を保管する
アカウント、ドメイン、および実質的に異なるルートごとに 1 行を作成します。ビジネス所有者、 DNS所有者、変更参照、意図した From、観察された From、エンベロープ ドメインとSPF結果、各DKIM d= および s= とその結果、適用可能なアライメント モード、信頼できる受信者とタイムスタンプ、プロバイダーのアクティベーション状態、配置の観察、未解決の質問、および次のアクションを記録します。欠損値を合格または不合格として扱うのではなく、不明な値としてマークします。所有者は、記録された証拠によってサポートされる意図されたルートと ID のみを受け入れます。それ以外の場合は、そのルートを保持し、承認された復旧計画に従います。
通過メッセージを施行の準備から切り離す
RFC 9989 セクション 7.4 では、ドメイン公開に有効なDKIMが必要です p=reject 間接メールの相互運用性に関する注意事項。単一の調整されたSPF結果だけでは、拒否ポリシーのロールアウトが正当化されるわけではありません。このプロバイダーの設定とは別に、すべての正当なルートとポリシーの所有権を確認します。