1. 独自ドメインを使う送信元を全部書き出す
最初に、差出人欄で会社の独自ドメインを使う仕組みを一覧にします。メールサーバー、Google WorkspaceやMicrosoft 365などの外部メール、WordPressの問い合わせフォーム、請求書、予約、採用、メールマガジンを別々の送信元として確認します。
担当者が知らない自動送信が残っていると、新しい認証設定でその経路だけ失敗することがあります。サービス名、用途、差出人アドレス、送信サーバー、管理者、公式設定ページを一行ずつ記録し、使っていない送信元は停止候補へ分けます。
- 社員が使うメールサーバーとメールソフト
- 問い合わせフォームやWordPressからの通知
- 請求・予約・採用・顧客管理サービス
- メール配信サービスと古い自動送信
2. SPFは許可する送信元の一覧として確認する
SPFは、受信側が送信元ドメインを確認するための仕組みです。利用中の各サービスが指定する値を集め、現在公開されているTXTレコードと照合します。値を推測したり、別サービスの例をそのまま流用したりせず、契約中サービスの公式案内を使います。
同じドメインへSPFレコードを無計画に追加すると、複数の記述が競合して認証に失敗する場合があります。既存値を保存し、複数の送信元を一つの方針へ統合できるか、参照回数などの制限に触れないかをサービス提供元へ確認します。
- 現在公開されているSPFの値
- 許可すべき送信サービスの一覧
- サービスごとの公式な設定値
- 重複レコードと参照回数の確認
3. DKIMはサービスが発行した鍵情報を使う
DKIMは、送信サービスが付けた電子署名を受信側が検証するための仕組みです。DNSにはサービスが指定するホスト名と公開情報を登録します。SPFと同じTXT形式でも、ホスト名や値の意味が異なるため、別の設定として扱います。
メールサービスを切り替えると、DKIMのセレクタや値も変わることがあります。新旧の送信が重なる移行期間は、どの送信元がどの鍵を使うかを記録し、旧サービスを止めた後に不要なレコードを整理します。
- サービスが指定したDKIMのホスト名
- 公開情報を登録するDNSレコードの種類
- 新旧サービスが重なる期間
- 停止後に削除する古いセレクタ
4. DMARCは認証失敗時の扱いを段階的に決める
DMARCは、SPFやDKIMの認証結果を基に、受信側へ失敗時の扱いを伝える仕組みです。いきなり厳しいポリシーへ変更すると、把握していなかった正規の送信まで届かなくなる可能性があります。まず送信元の一覧と認証状況を確認し、影響を見ながら方針を決めます。
集計レポートを受け取る場合は、通知先、閲覧担当、確認頻度、異常を見つけたときの連絡先を決めます。レポート用アドレスがDNSから参照される場合もあるため、公開して差し支えない専用アドレスを検討します。
- 現在のDMARCレコードとポリシー
- 認証に失敗している正規の送信元
- レポートの通知先と確認担当者
- ポリシーを変更する判断条件
5. DNS変更前に現状と切り戻し手順を保存する
DNSを編集する前に、対象ドメインのMX、SPF、DKIM、DMARCと、外部サービスの確認用レコードを一覧で保存します。誰が、いつ、どの値を、どの公式案内に基づいて変えるかを記録し、一度に複数の問題を持ち込まない小さな変更単位にします。
反映には時間差があるため、変更直後の一回だけで成否を決めません。旧値へ戻す条件、待つ時間、問い合わせ先を先に決め、メールとホームページでDNS管理を共有している場合はWeb側への影響も確認します。
- 変更前のDNSレコード一覧を保存した
- 変更値の出典となる公式ページを記録した
- 変更担当者と実施時刻を残した
- 切り戻す条件と旧値を用意した
6. 外部宛てに送り認証結果を確認する
設定後は、社内同士だけでなく、普段の取引先が使う外部メールサービスへテスト送信します。受信箱と迷惑メールを確認し、受信したメールのヘッダーや提供される診断画面でSPF、DKIM、DMARCの結果を読み取ります。
社員のメールソフト、問い合わせフォーム、請求サービスなど、一覧にした送信元ごとに試します。一つの経路が成功しても別の経路が同じ結果になるとは限りません。返信先、表示名、添付、フォーム通知も業務で使う形に近い条件で確認します。
- 異なる外部メールサービスで受信できた
- SPF・DKIM・DMARCの結果を確認した
- 迷惑メールへの振り分けを確認した
- 自動送信を含む全経路を試した
7. 新しい送信サービスを追加する手順を決める
メール認証は一度設定して終わりではありません。新しいフォームや配信サービスを追加するときは、契約前に必要なDNSレコード、送信ドメイン、管理者、停止時の削除項目を確認し、既存のSPFやDKIMへ与える影響をレビューします。
担当者変更時には、DNSを編集できる人、メールサービスの管理者、レポートを読む人を引き継ぎます。半年ごとなど継続できる周期で送信元一覧と公開レコードを照合し、使っていないサービスや古い認証情報を整理します。
- 追加前に必要なDNS変更を確認する
- 本番前に外部宛ての送信テストを行う
- 停止時に削除するレコードを記録する
- 定期点検日と管理担当者を決める