メール設定から読み取れること
ドメインのMXレコードは、メールを受け入れるように指定されたサーバーを示し、SPFおよびDMARC TXTレコードは、どの送信者が認証されているか、および認証に失敗したメッセージをレシーバーがどうすべきかを記述します。これらを合わせて、ドメインがどのようにメールを送受信する意図があるかを示しますが、特定のメッセージの内容や意図を記述するものではありません。
注目すべきパターン
MXレコードがないドメインは、メールを受信するように設定されていません。これは、顧客や被害者とメールで積極的にやり取りしているドメインにとっては異例です。法人送信者として提示しているにもかかわらず、無料の消費者向けウェブメールプロバイダーのMXレコードを使用しているドメインは、特にそれが代表しているように見える組織のメール設定と比較した場合、さらに調査する価値のある不一致です。
認証側では、SPFレコードの欠落、無関係なインクルードが多数含まれる過度に緩いSPFレコード、またはレポートアドレスが設定されていないp=noneのDMARCポリシーはすべて、詐欺師が悪用できる保護の弱さの兆候です。これは自身のドメインで行われる場合もあれば、保護の欠けた正規のドメインをなりすます場合もあります。p=rejectとSPF/DKIMが整列されたドメインは直接なりすますのが難しいため、そのようなドメインを騙る攻撃者は通常、代わりに似たようなドメインを登録します。
既知の良好な基準との比較
最も信頼性の高いシグナルは比較から得られます。疑わしいドメインが代表すると主張する組織のMX、SPF、DMARCレコードを調査し、メールプロバイダー、含まれる送信サービス、ポリシーの強度を比較してください。通常、よく知られたビジネスメールプラットフォームを通じて送信するサプライヤーが、突然、異なる新しく設定されたプロバイダーを使用する模倣ドメインによって代表されている場合、それはどちらか一方の事実だけよりも強力な指標となります。
この証拠の限界
これらのレコードは、特定のメッセージの配信ではなく設定を記述しており、いつでも変更される可能性があるため、インシデント後に取得されたルックアップは、メッセージが送信された時点の設定を反映していない場合があります。特定のメッセージが問題となる場合は、レコードが変更された後にSPFまたはDMARCを再計算するのではなく、信頼できる受信メールサーバーによって既に計算され、保存されたオリジナルメッセージのAuthentication-Resultsヘッダーに記録されている認証結果に依拠してください。
- MXホストと優先順位をリストし、メールプロバイダを特定します。
- SPFメカニズムとDMARCポリシー、pct、レポートタグを記録します。
- なりすましの対象となっている組織のメール設定と比較する。
- 特定のメッセージに対して保存されたAuthentication-Resultsヘッダーを使用する。
- メールレコードは変更されるため、レコード収集時間を記録します。