SPF・DKIM・DMARCは、三つをDNSへ追加すれば同じ認証を三重に行う仕組みではありません。SPFは送信経路、DKIMは署名、DMARCは利用者に見えるFromドメインとの整合と失敗時方針を扱います。設定値を書く前に、自社ドメインからメールを送るすべてのサービスを把握します。

メール認証は正規送信の一覧から始める

社員のメールだけでなく、問い合わせフォーム・予約・請求・一斉配信も自社ドメインを名乗る場合があります。送信サービスごとに、エンベロープFrom・ヘッダーFrom・DKIM署名ドメインを確認します。見た目の差出人だけを一覧にしても、SPFとDMARCの判定条件は分かりません。

現在のDNSレコードと各サービスの公式設定値を照合します。使っていない旧サービスがSPFやDKIMへ残っていれば、なりすましに利用できる範囲を広げます。反対に現行のフォーム送信を外せば正規メールが失敗します。追加と削除の担当を決め、変更前の値を保存します。

SPFは配送経路の送信元を検証する

SPFはSMTP配送で使うドメインについて、そのメールを送信したホストが許可されているかを検証します。利用者が見るFromと常に同じドメインを検証するわけではありません。転送などで経路が変われば、元の送信者が正規でもSPFが失敗する場合があります。この限界をDKIMとDMARCとの組み合わせで補います。

一つのドメインへ有効なSPF方針を複数置きません。複数サービスを許可する場合は、各社の公式値を一つの方針へ統合します。includeを増やすとDNS参照数などの制約へ近づくため、使わない経路を整理します。~allと-allは好みで選ばず、サービス案内と現在の移行段階から決めます。

DKIMは署名と本文の整合を検証する

DKIMでは送信側がメールへ署名し、受信側がDNSに公開された鍵で検証します。署名ドメインとセレクタの組み合わせに対応する公開鍵が必要です。メール転送後も署名対象が変更されなければ検証を維持できる可能性がありますが、配送中の変更で失敗する場合もあります。

秘密鍵は送信サービス側で管理し、DNSには公開鍵を登録します。管理画面で有効化しただけでDNSが自動追加されるかは、DNS管理先との連携で異なります。鍵の切り替えでは新旧セレクタの併用期間を設けられるか確認します。古いサービスを終了したら、不要な公開鍵と送信権限を整理します。

DMARCはFromとの整合と受信方針を結ぶ

DMARCはSPFまたはDKIMの合格だけでなく、その認証ドメインがヘッダーFromのドメインと整合しているかを確認します。どちらか一方が整合して合格すればDMARCが合格できる条件があります。このためSPF・DKIMが個別にpassでも、Fromとの関係によりDMARCがfailになることがあります。

DMARC方針は監視だけのp=noneから隔離・拒否まで段階があります。最初から厳格化すると、把握していない正規送信を止める可能性があります。集約レポートの受信先と解析担当を決め、正規経路の整合を確認してから方針を強めます。レポートを受け取るだけで運用が完了するわけではありません。

DNS公開後は実際の受信結果を確認する

DNSへ表示されたことと認証成功は別です。各正規サービスから外部の検証用受信先へ送り、受信ヘッダーのAuthentication-ResultsでSPF・DKIM・DMARCを確認します。社員メールだけでなくフォームや一斉配信も対象です。迷惑メールフォルダに入ったかだけでは、どの認証が失敗したかを判断できません。

失敗した場合は、SPFの送信IP・DKIMの署名ドメインとセレクタ・DMARCの整合を順に見ます。DNS反映待ちという説明だけで終えず、問い合わせ時は送信時刻とMessage-IDを保存します。認証に合格しても内容や送信評判など別要因で迷惑判定されるため、認証だけで受信箱到達を保証しません。

変更と廃止をメール運用へ組み込む

新しい送信サービスを導入するときは、本番送信前にSPF・DKIM・DMARCの整合を試します。サービス終了時はDNSから許可と公開鍵を外し、アカウントやAPIキーも停止します。Webサイト移転でフォームの送信元が変わる場合も、DNS切り替えとは別にメール認証の変更票を作ります。

少なくとも定期的に送信経路一覧とDMARCレポートを照合します。知らない送信元があれば不正利用か設定漏れかを調査します。担当者だけが値を覚える運用にせず、DNS管理先・送信サービス・確認日を台帳へ残します。三つの認証は一度設定する部品ではなく、送信経路の増減を安全に反映する管理の仕組みです。