委任されたアシスタント、サポート プラットフォーム、およびメール送信ワークフローでは、From、Sender、Reply-To に異なるアドレスを入力する場合があります。詐欺師も同じ違いを悪用する可能性があります。有益な質問は、ID と返信先が、該当する場合には信頼できる認証証拠によって裏付けられた、検証済みのビジネス取り決めと一致するかどうかです。
役割に応じてフィールドを読みます
From は、メッセージの作成者を識別します。送信者は、実際の送信を担当するエージェントのメールボックスが作成者と異なる場合に識別します。 Reply-To は、作成者が返信の送信先を提案する場所を示します。 Reply-To が存在しない場合、受信者が他の知識を持っていない限り、返信はデフォルトで From に送信されます。これらはメッセージ形式のセマンティクスであり、指定された人物がメッセージを承認したという独立した証拠ではありません。 RFC 5322セクション 3.6.2.
表示名には「Finance」と表示されますが、実際の住所は別の場所に属します。アドレスを展開して調べますが、よく知られた正確なアドレスを十分なものとして扱ってはいけません。ヘッダー テキストは、認証と適切な出所によってサポートされない限り、送信者によって制御されます。 From に複数のメールボックスが含まれる場合、 RFC 5322では、1 つのメールボックスを含む Sender フィールドが必要です。複数の著者を 1 つのアイデンティティに崩壊させるのではなく、その区別を維持します。
認証入力を分離する
DMARC 著者とドメインの関連性を評価します。 SPF または DKIM 認証された識別子。 Reply-To と Sender は代替ではありません アライメント 入力。一致する Reply-To ドメインは、失敗した作成者とドメインの調整の決定を救済することはできません。逆に、別の Reply-To は正当である可能性があり、それ自体ではDMARC障害が確立されません。 RFC 9989.
ドメイン認証パスでは、銀行口座の変更、資格情報の要求、または機密資料の新しい受信者は許可されません。特に返信で機密情報が開示されたり、結果としての約束を受け入れたりする場合は、業務上の指示を分けて扱います。
境界のある例を調べる
From: support@brand.example 、Sender: operator@service.example 、 Reply-To: case123@service.exampleという仮想のサポート メッセージを考えてみましょう。ブランドが承認したサポート ワークフローは、3 つの役割すべてを説明している可能性があります。認識されていない返信アドレスに財務記録を送信する別のリクエストには、作成者のドメインが認証されている場合でも、独立した確認が必要です。これらはでっち上げられた比較であり、解析されたメッセージや認証されたサービス関係ではありません。
実際のメッセージについては、フィールドを承認されたサービス構成および事前に検証されたワークフローと比較します。組織がサポートへの返信を意図的にその宛先にルーティングしているかどうかを尋ねます。疑わしいメッセージで提供された電話番号やリンクではなく、確立された独立したチャネルを通じて、意外なリクエストや影響の大きいリクエストを検証します。
状況に応じた決定を記録する
主張された作成者、送信エージェント、返信先、信頼できる認証結果、およびビジネス検証結果を文書化します。差異が承認された取り決めと一致する場合は、その差異が予想される理由を記録します。宛先が不明な場合は、所有者がそれを確認するまで、結果として生じるアクションを保留します。 3 つのドメインすべてが一致する必要がある包括的なルールは避けてください。これにより、完全な詐欺防御が提供されずに正当な委任が破られる可能性があります。
受信者の次の安全な行動により調査を終了します。それは、既知のサポート ポータルを通じて返信したり、確立された連絡先にリクエストを確認したり、元のメッセージを保存した状態でなりすましの疑いをエスカレーションしたりすることです。
返信前にワークフローを確認する
- 実際の送信者、送信者、返信先のアドレスを展開します。
- 作成者、送信エージェント、および推奨される返信先を個別にマップします。
- ビジネスの承認として扱うことなく、信頼できる認証を裏付けます。
- 確立された独立したチャネルを通じて予期せぬ宛先をチェックします。
- 承認された取り決めが違いを説明するか、結果として生じる措置を保留するかを記録します。