セットアップを選択する前にトランスポートを特定する
Freshdeskのドメイン検証手順は、デフォルトの送信サーバーに適用されます。カスタム電子メール サーバーは、別のトランスポートです。 DKIM セットアップはそのサービスで処理する必要があります。まず、各サポート アドレス、実際のサーバーの選択、表示される差出人、返信先、および責任のあるサポート チームの所有者を記録します。住所だけから交通手段を推測しないでください。
インバウンドサポート転送をアウトバウンド認証から分離します。ヘルプデスクに届いてチケットになったメッセージは、ヘルプデスクの返信に有効な整合署名があることを証明するものではありません。逆に、正しい送信DKIM 、受信箱の転送やチケットのスレッド化の問題を解決できません。制御されたメールボックスと架空のチケット コンテンツを使用して、方向ごとに 1 つのテストを計画します。
生成されたレコードセットを取得して公開する
管理者は、[管理] > [チャネル] > [電子メール] > [詳細設定] > DKIMの構成] を開きます。生成された 4 つをコピーします CNAME レコードを権威DNSサービスに入力してから戻り、ドメインを展開して [検証] を選択します。セットアップは、同じドメイン上のメールボックスごとではなく、ドメインごとに行われます。ステータス インジケーターとアカウント管理者の確認を確認します。出典: Freshdesk 、 DKIMレコードの構成。
ブログのサンプルではなく、アカウントの値によって所有者の名前とターゲットが決まります。追加する前に、各所有者の既存のレコードを検査してください。別のアプリケーションが占有している場合、 セレクタを削除したり、複数のCNAMEターゲットを結合しようとしないでください。 Freshdeskのガイドでは、記録が競合するケースをサポートするよう指示しています。推測することなく問題を解決できるように、正確なアカウント、所有者名、矛盾する値をサポートに提供してください。
一部のDNSエディターでは、ゾーン名が自動的に追加されます。 selector._domainkey.example.comなどのホストは、間違ったフィールド フォームに入力するとselector._domainkey.example.com.example.comになる可能性があります。保存後に、結果として得られる完全修飾所有者を確認します。視覚的にもっともらしい短いラベルだけでは十分ではありません。伝播を待機する一般的なリクエストは、このチェックの前ではなく後に行う必要があります。
共有ドメインの変更の範囲を狭くする
1 つのビジネス ドメインが、複数のFreshdeskアカウント、他の Freshworks 製品、および関連のないメール システムにサービスを提供する場合があります。記録から所有者までのマップを維持します。同一の必須レコードには重複パブリケーションは必要ありませんが、同じCNAME所有者にある異なるターゲットは競合します。重複する値に関するドキュメントのショートカットを、マルチターゲットCNAMEレコードを構築する権限として解釈しないでください。
ドメインを変更しないでください SPF このウィザードにDKIMラベルが付いているという理由だけで、このポリシーが必要になります。ベンダーのレコード セットが配信のいくつかの側面をサポートしている場合でも、 SPFとDKIM別個の認証メカニズムです。実際に構成されているトランスポートと現在のアカウントの手順を使用して、別のSPF更新が必要かどうかを判断します。 SPFを更新する場合は、1 つのポリシーを保持し、他のすべての承認された送信者をその DNS ルックアップ制限内に保持します。
完全なサポート会話をテストする
意図した受信パスを通じて制御されたチケットを開始し、テスト中のサポート アドレスから応答を送信します。元のメッセージは受信メールボックスに保存してください。サポート アドレスとアカウント、表示される差出人、エンベロープ ドメイン、 DKIM d=/s=および信頼できる受信者を記録します。 Authentication-Results。別のドメインで 2 番目のサポート アドレスを個別にテストします。構成されたドメインを共有するアドレスは、異なる動作設定を持ちながら、 DNSセットアップを共有できます。
合成例: support@example.com 、有効な署名d=example.comと無関係のプロバイダー エンベロープのSPFパスで応答します。完全一致DKIM位置合わせされたものを提供できます。 DMARC パス;無関係なSPF結果はそうではありません。 2 番目のサポート メールボックスがカスタム サーバーを使用しており、その署名がない場合は、Freshdesk-default-server 構成がそれに適用されると想定しないでください。実際のトランスポートを特定し、そこで認証を修正します。
DKIMドメインに関連付けられた署名を検証します。 DMARC 、該当するモードで表示される From を基準にして、調整されたSPFまたはDKIM ID を渡す必要があります。どちらのメカニズムも、受信トレイへの配置を保証したり、なりすましを普遍的に不可能にしたりするものではありません。認証とは別にチケットのスレッド化と応答の配信を検証します。
検証と納品を順番に診断
構成ページにドメインが表示されない場合は、レコードを作成する前にサポート電子メールの設定と検証ステータスを確認してください。検証が失敗した場合は、生成された各値を権威DNSと比較し、省略、スペース、重複したサフィックスをチェックします。レコードは正しいように見えても製品の検証が失敗する場合は、アカウントのコンテキスト、出力、および正確なエラーをサポートのために保持してください。
DNSと製品の検証に合格したが、受信者がメールが見つからないと報告した場合は、受信したサンプルの実際の送信エラーとヘッダーを保存します。署名が欠落している場合は、ルートまたは設定の不一致を示しています。無効な署名にはキーとメッセージの整合性の調査が必要です。配置が不適切で整列したパスの場合は、配信調査が必要になります。最初の対応として、無関係なキーをローテーションしたり、ドメイン全体のDMARCポリシーを下げたりしないでください。
実証された範囲のみを受け入れる
顧客向けメールを変更する前に、以前の記録とサポート設定、および承認された代替ルートを保存してください。古いレコードは依存関係を確認した後にのみ削除してください。完了レコードでは、テストされたすべてのサポート ドメインとトランスポート、 DNSと製品の検証、受信者の認証、および応答/スレッドの結果を識別する必要があります。これは合成例を含むドキュメント ガイドであり、 Freshdeskライブ テストではありません。独立したチェック、SME による人間の承認、公開が引き続き必要です。
認証とチケットのクローズを分離する
書面によるサポート ケース FD-01 では、 help@example.comデフォルトのFreshdeskサーバーを使用し、制御された応答がd=example.com, s=demo1 で信頼されたDKIMパスを持っていることを前提としs=demo1.その正確に位置合わせされたパスはDMARC満たすことができますが、それ以外の場合はSPF不明です。次に、返信先アドレスが次の応答を間違ったキューにルーティングすると仮定します。認証を受け入れても、ワークフローの欠陥は解決されません。サポート所有者は、承認された返信ルートを修正し、無害な会話テストを繰り返す必要があります。 DKIMを置き換えたり、 DMARCを下げたりしても、前述の問題は解決されません。カスタムSMTPを使用する 2 番目のメールボックスは、このデフォルト サーバーの結果の外側に残ります。これらは規定された教育インプットであり、実行されたチケットや観察された顧客インシデントではありません。
施行境界を維持する
RFC 9989 セクション 7.4 では、ドメイン公開にはSPFのみではなく有効なDKIMが必要です p=reject、間接メールとメーリングリストの相互運用性について警告します。ダイレクト メッセージ テストが 1 回成功しただけでは、すべての正当なルートがより強力なポリシーに対応できるようになっているという証拠にはなりません。実際のギャップを診断しながら、既存の承認された保護を維持します。政策変更には独自の決定が必要です。