なりすましを防ぐため、メールのドメインにSPF・DKIM・DMARCを設定する

## メールのDNS設定を変える前に、担当者と変更を取り消す方法を決める メール認証を共有インフラとして扱う。レコードの変更は、同じドメインを使うトランザクションメール、サポートシステム、マーケティング、社内ツール、第三者へ影響することがある。 - 対象となる送信ドメイン、サブドメイン、表示Fromドメイン、事業上重要なメール経路を特定する。 - 説明責任を負うドメインオーナーと、権限を持つDNS運用者を指名する。 - 各変更について、提案、レビュー、承認、反映、検証、監視を誰が行うかを分ける。 - 現在のDNS値、存続時間、依存関係、テスト済みのロールバック値を記録する。 - 重要なメール経路のオーナーが結果を観測できる時間帯に変更を予定する。 - 明示的な承認と復旧計画なしに本番DNSを編集しない。 - 送信元の棚卸しまたは所有責任の証拠が不完全な場合は、強制段階への移行を止める。 ## 自分のドメインでメールを送るサービスを全部書き出す 認証レコードを書く前に、送信元の棚卸しを行う。正規サービスを一つでも見落とすと、ポリシー強制によって必要なメールが遮断されることがあり、古い認可を残すとなりすまし可能範囲が広がる。 - そのドメインを使って送信する各プラットフォーム、アプリケーション、リレー、端末、外部事業者を列挙する。 - エンベロープ送信者、表示Fromドメイン、署名ドメイン、IPの所有者、担当チームを記録する。 - 直接送信元を、転送、メーリングリスト、ゲートウェイ経路と区別する。 - DKIMで署名できる送信元と、SPF整合に依存する送信元を記録する。 - 廃止済みの送信元は、正規のトラフィックを送っていないことを確認した後にだけ対象から外す。 - リスクや所有責任が異なるグループは、専用サブドメインへ分離することを検討する。 - 棚卸し情報を変更記録と認証レポートに関連付けておく。 ## すべての送信元を含む、正しいSPFの設定を1つだけ作る SPFは、エンベロープ送信者でドメインを使用できるシステムを認可する。接続元を評価するものであり、内容へ署名せず、単独では表示Fromアドレスを認証しない。 - 必要な各ホスト名に、SPFポリシーを一つだけ反映する。 - SPFレコードを重複させず、すべての正規送信元を一つのポリシーへ統合する。 - 担当する送信サービスが対応するメカニズムとincludeだけを使う。 - SPF評価時にDNS問い合わせを伴うメカニズムを、上限値 10 以内に保つ。 - 上限に近づく前に、重複したincludeと未使用の送信元を取り除く。 - 末尾のallメカニズムを意図的に選び、網羅性が証明された後にだけ厳格化する。 - 構文、展開経路、問い合わせ回数、代表的な送信元からの結果を検証する。 ## メールを送るサービスごとに、DKIMの署名を有効にする DKIMでは、送信元が選択したメッセージ内容へ署名用の非公開鍵で署名し、受信側が対応する公開鍵をDNSから取得する。署名の合格は、署名対象の内容が転送中も保たれたことを示し、署名ドメインを特定する。 - 各送信元が対応する方法に従い、別々のセレクターと鍵ペアを生成する。 - 送信元とDNSサービスの双方が対応する場合は、2048-bit鍵などの強い鍵を優先する。 - 送信元が指定したセレクター位置へ、正確な公開鍵レコードを反映する。 - 署名用の非公開鍵を保護し、DNS、チケット、共有文書、ログへ決して記載しない。 - 公開レコードが正しく名前解決された後にだけ署名を有効にする。 - 実際のテストメールを送り、セレクター、署名ドメイン、署名結果、ヘッダーの対象範囲を検証する。 - 古い鍵を廃止する前に新しい鍵を実証できるよう、セレクターを使った鍵ローテーションを計画する。 ## DMARCを見張るだけの設定で始め、届くレポートを読む DMARCは、表示Fromドメインが、合格したSPFまたはDKIMの識別子と整合しているかを評価し、その後ドメインオーナーが反映したポリシーを適用する。認証に合格しても、整合していなければDMARCに失敗することがある。 - 各正規メール経路が、SPF、DKIM、または両方を通じて整合していることを確認する。 - 緩和整合と厳格整合のどちらがドメイン構造とリスクに合うかを把握する。 - 必要なポリシー用ホスト名に、権限を持つレポート送付先を含むDMARCレコードを反映する。 - 正規と未認可の送信元を発見する間は、監視ポリシーから始める。 - レポートからインフラの詳細が分かることがあるため、レポート用メールボックスを保護し、アクセスを制限する。 - 失敗を、送信元、認証結果、整合、量、事業オーナー別に分類する。 - 重要な正規メール経路を把握するまで、強制ポリシーへ移行しない。 ## DMARCを、必要なメールを止めずに少しずつ厳しくする 正規メールの整合が保たれていることを証拠が示した時にだけ、監視から隔離、拒否へ進める。強制はリスク統制の意思決定であり、一度だけ行うDNSの書式設定作業ではない。 - 各段階について、合格率、未知の送信元、事業影響の基準を定める。 - ポリシーの厳格度を上げる前に、正規メールの失敗を是正する。 - 対応していてリスク低減に有益な場合は、限定した強制割合を使う。 - 各変更後に、集約レポート、配信エラー、サポート事案、重要なメール経路の健全性を監視する。 - 移行中は常に、文書化したロールバック用ポリシーを準備しておく。 - 強制を強める、または整合モードを変える前に、説明責任を負う者の承認を得る。 - 正規メールが拒否、隔離、または予期せず未認証になった場合は、停止して調査する。 ## 変更のたびに、DNSの設定と実際のテストメールを確かめる レコードの反映と実際のメール動作の両方を確認する。構文上有効なDNSレコードだけでは、すべての送信元がそのレコードを使うことも、DMARC整合が成功することも証明できない。 - 伝播後、権威DNSへSPF、DKIMセレクター、DMARCを問い合わせる。 - レコードの重複、切り詰められた値、誤ったホスト名、意図しない継承ポリシーを確認する。 - 代表的な本番経路をすべて通して、複数の受信環境へテストメールを送る。 - メッセージヘッダーで、SPF、DKIM、DMARC、ドメイン、セレクター、整合結果を点検する。 - 通常のメッセージと、転送やリレーなどの重要な変種の両方をテストする。 - テスト経路、日時、結果、証拠、レビュアーを記録する。 - 送信元、DNS、ルーティング、署名の変更後は必ず検証を繰り返す。 ## SPF・DKIM・DMARCの失敗の原因を、メールのヘッダーなどから探す 認証結果、DNS応答、メッセージヘッダー、変更履歴から診断する。偶然テストに合格するまでレコード編集を繰り返さない。 - SPFの永続エラーでは、重複ポリシー、構文、再帰的include、上限値 10 を確認する。 - DKIMの失敗では、セレクター名、転記した鍵情報、署名状態、正規化方式、メッセージ変更を確認する。 - DMARCの失敗では、表示FromドメインをSPFおよびDKIMの識別子と比較する。 - 正規メールが遮断された場合は、ポリシーを緩める前に正確な送信元を特定する。 - 本番メール経路が損なわれた時は、原因となった最小の変更をロールバックする。 - 各修正後に、失敗した経路と影響を受けていない対照経路を再テストする。 - 原因と修正の証拠を、将来の変更に備えて保全する。 ## 認証の結果だけでなく、迷惑メール入りや戻ってきたメールも見る SPF、DKIM、DMARCはなりすましを減らし、受信側の重要な検査を満たすが、受信箱への到達を保証しない。評判と受信者の反応は別のシグナルである。 - 認証合格率とともに、拒否、一時保留、迷惑メールへの振り分け、苦情、バウンスを監視する。 - 正確な受信者リストを維持し、無効または継続的に失敗するアドレスを対象から外す。 - 送信量と送信パターンを、ドメインに確立された評判と整合させる。 - 誠実な送信者情報、関連性のある内容、不要なメールを停止する明確な方法を使う。 - ドメイン、メール経路、受信側、内容、反映イベント別に急な変化を調査する。 - ウォームアップ活動や認証検査の合格を、健全な評判の証明として扱わない。 - 継続的な害を示す証拠がある時は、リスクのあるメール経路を停止する。 ## 送信元の一覧とDKIMの鍵を、決まった間隔で見直す サービスの変更、鍵の経年、オーナーの離任、新しい送信元によるレビューの迂回があると、認証は劣化する。完了済みの設定プロジェクトではなく、継続的な統制として維持する。 - 定めた周期で、送信元の棚卸し、DNSレコード、DMARCレポート、所有責任を確認する。 - 有効な署名を保つ重複期間を設け、DKIMセレクターと鍵をローテーションする。 - includeや送信サービスが変わるたびに、SPFの問い合わせ回数を再検証する。 - ポリシー変更、承認、反映値、検証証拠、ロールバック結果を追跡する。 - 新しい送信元、合格率の低下、レポートの欠落、突然の整合失敗を通知対象にする。 - 関係するメール経路が停止していることを確認した後、古い認可を対象から外す。 - リスク、量、事業用途が変わった時は、サブドメイン境界と強制ポリシーを再評価する。