サイトのメールを止めずにSPF・DKIM・DMARCを設定する方法

ドメインのメール拒否ポリシーを厳しくする前に、ウェブサイトのためにメールを送信しているサービスを、一つ残らず認証してください。購入の領収書、パスワードの再設定通知、サポートからの返信、そしてそのほかの正当な送信システムも対象に含めます。たった一つの送信元を見落としただけでも、セキュリティを改善するはずの変更が、重要なメッセージが理由も分からず届かなくなるトラブルに見えてしまうことがあります。

SPF、DKIM、DMARCは相互に関連する制御ですが、どれか一つを別のものへ置き換えられる三つの認証マークではありません。まずは送信元を洗い出して一覧にし、実際の動作を確かめる作業として取り組んでください。別のサイトで使われているDNSレコードをそのままコピーする方法は、特に危険です。自分のドメインとは利用している事業者が違うかもしれず、送信用のサブドメインや、配信できなかったメールを返す経路も異なる可能性があるためです。

DNSを編集する前に、本当の送信元を洗い出します

メッセージの種類、送信サービス、表示されるFromアドレス、アカウントの責任者を一覧にします。各経路から許可されたテストを送り、ヘッダーを非公開で保存してください。自分のメールボックスから手動送信しても、アプリの領収書やパスワード再設定サービスのテストにはなりません。

SPFは、配送時に使うエンベロープ送信者のドメインについて送信システムを許可します。DKIMはメッセージにドメインの暗号署名を追加します。DMARCは、認証されたドメインが受信者の見るFromドメインと整合しているかを評価します。この違いはDMARC仕様で説明されています。

仮のサイトでは、サポート返信をメール業者から、購入の領収書を別の商取引サービスから送っているかもしれません。同じブランドを表示していても、技術的な経路は違います。メール業者のDNS手順が会社の全送信を網羅すると決めつけず、両方の経路を検証します。

変更前に現在のDNS値と、復元できる担当者を記録します。サービスが確認用レコードを求める場合は、そのドメイン向けに指定された正確な値を使ってください。送信認証を直すために、無関係なメール経路のレコードを上書きしないようにします。受信メールと送信者認証は別の問題です。

既存の送信元を壊さず認証を追加します

SPF仕様では、同じドメイン名に複数のSPFレコードを置くことは認められていません。二つ目の業者を許可する際は、独立したv=spf1レコードを追加せず、既存ポリシーを意識して変更します。別用途のTXTレコードが複数あるのは普通であり、問題は競合する複数のSPFポリシーです。

SPF評価には、DNS問い合わせを行うメカニズムと修飾子を10個までとする制限もあります。入れ子のincludeが枠を消費するため、見える業者名を数えるだけでは不十分です。業者の画面が緑になるまでincludeを追加するのではなく、メール管理者にポリシー全体を評価してもらいます。

DKIMでは各送信元の鍵とセレクターの手順に従い、そのサービスが実際に送ったメッセージを検証します。鍵を公開しただけでは、それを使った署名が始まった証拠になりません。秘密鍵は非公開に保ち、共有設定の記録には、業者が指定した公開DNS情報だけを含めてください。

定期実行ジョブや別のチームがまだ使っていないか確認するまで、古い送信サービスを削除しないでください。整然としたDNSゾーンの裏で、月次請求メールが壊れている場合もあります。業務上の依存をなくし、代替手段をテストした後で認可を取り下げます。

拒否を始める前にDMARCレポートを使います

正当な送信元をすべて把握していない場合は、観察から始めます。DMARCのp=noneは、DMARCに基づく隔離や拒否を求めない設定です。その間、レポートが認証とアラインメントの問題を見つける助けになります。これは監視段階であり、なりすましメールが遮断されている証拠ではありません。

DMARCの合格には、整合したSPFまたはDKIMが必要です。無関係なドメインで認証に成功しただけでは足りません。届いたテストメールの認証済みドメインを調べてください。見えるブランド名は整合性のテストではなく、一度届いたこともポリシーの正しさを証明しません。

ポリシーを変える前に、集計レポートを確認し、見慣れない送信元を調べる人を決めます。レポートの送付先を保護し、運用データへのアクセスを制限してください。誰も読まない報告用アドレスを作っても、設定は増えますが有用な制御にはなりません。

正当な送信経路が合格し、戻し方を文書化してから、より厳しい扱いへ移ります。業者、Fromドメイン、署名設定を変えた後は再テストします。目的はなりすましの拒否であり、通常の顧客メールを巻き添えにすることではありません。

受信側の要件と実際の配送を確認します

Gmailの送信者向けガイドラインは、個人用Gmailアカウントに送るすべての送信者にSPFまたはDKIMを、大量送信者にSPF、DKIM、DMARCを求めています。Googleは整合性、通信の安全性など配送の実務も扱っています。認証は必要な基礎ですが、受信トレイへの到着を保証しません。

大量の販促メール向けルールを、すべての取引メールへ無条件に当てはめないでください。対象者、メッセージの目的、適用される受信側要件を特定します。領収書やアカウント通知をマーケティングと分け、配信障害の調査が無関係な販促行動と混ざらないようにします。

実装後は、一覧にしたすべての送信元のメールを確認し、拒否通知も調べます。時刻とエラー詳細は残しますが、公開の課題管理ツールに認証情報や顧客の非公開内容を置かないでください。複数のDNSレコードを一度に何度も変えるより、個別の変更と障害を照合します。

送信元の見直しをサイト保守の定期作業に追加し、ホスティングや基盤の変更がメールへ影響する場合にも実施します。ゴールはDNSに三つのレコードを置くことではありません。検証した正当な送信元一覧、観察したポリシー、次の変更の明確な責任者をそろえることです。