独自ドメインメールを使うには、受信先を示すMXだけでなく、正規の送信元を示すSPF・DKIM・DMARCも確認します。MXを変更すれば新しい受信先へメールは向かいますが、過去のメールやメールソフト設定が自動で移るわけではありません。
最初に現在の権威DNSと全レコードを保存し、すべての送信経路を棚卸しします。Webフォームや請求サービスを見落としたまま送信認証を強めると、自社の正当なメールが失敗します。受信箱を先に作り、認証を確認してからMXを切り替えます。
DNSを編集する場所と現在のレコードを確認する
ドメインを購入した会社と、DNSを実際に提供する会社は同じとは限りません。まず外部から取得できるネームサーバーを確認し、どの管理画面が権威DNSのゾーンを編集しているかを特定します。関係のない管理画面へレコードを追加しても公開情報は変わりません。
変更前に、MX・TXT・A・AAAA・CNAMEを含む現在のレコードを保存します。画面のスクリーンショットだけでなく、名前・種類・値・優先値・TTLをテキストでも残します。対象ドメインの末尾の点や@の扱いはDNSサービスによって異なるため、提供元の入力方法を確認します。
メール設定のためにネームサーバー全体を変更する必要は通常ありません。Webサイト用のAやCNAMEを削除すると、メールを直す作業でWebサイトを止めます。依頼先には変更するレコードと触らないレコードを明示します。
MXは受信先を示し、送信元は認証しない
MXは、そのドメイン宛メールを受け取るサーバーを示します。優先値は小さい値が優先されるのが一般的ですが、通信速度の順位ではありません。複数MXは、提供サービスがその構成を前提としている場合に公式値どおり登録します。
古いメールサービスのMXを「予備」として残すと、新旧両方が同じ利用者と配送を正しく扱わない限り、メールが旧環境へ入る可能性があります。新サービスの案内にないMXは、切り替え計画に従って削除します。削除前に、新環境へ利用者・エイリアス・グループを作ります。
MXは受信先の情報であり、自社から送るメールが正規かを証明しません。送信認証にはSPF・DKIM・DMARCを使います。受信できたことだけで、相手の迷惑メール判定まで正常とは判断しないようにします。
SPF・DKIM・DMARCは役割が異なる
三つのレコードは置き換え関係ではありません。送信経路と表示上のFromドメインを異なる方法で確認します。
| 設定 | 主な役割 | 導入時に確認すること |
|---|---|---|
| SPF | 送信元IPをドメインとして認可する | 同じドメインから送るすべてのサービス |
| DKIM | メールへ電子署名し、DNSの公開鍵で検証する | 送信サービスごとのセレクターと署名開始 |
| DMARC | FromドメインとSPFまたはDKIMの認証ドメインの整合を見る | 正規送信の一覧、レポート先、適用方針 |
SPFは一つの所有者名に一つの方針としてまとめます。メールサービスごとにv=spf1で始まるTXTを別々に作ると、正しく評価できません。SPFのRFCではDNS参照を伴う仕組みに上限もあるため、includeを無制限に追加せず、不要な送信元を削除します。
DKIMの秘密鍵は送信サービス側が保持し、公開鍵をDNSへ置きます。サービスごとに異なるセレクターを使えば、複数の公開鍵を併用できます。DNSへ公開鍵を追加しただけで署名が始まるとは限らないため、送信側の有効化とテストメールのヘッダーを確認します。
DMARCは正規の送信元を把握してから強める
DMARCは、利用者が見るFromドメインと、SPFまたはDKIMで認証されたドメインの整合を確認します。どちらか一方が成功し、Fromと整合すればDMARCを通過できます。DMARCのRFCでは、方針と集計レポートをDNSで公開する仕組みが定義されています。
導入時は、まずSPFとDKIMを正しく動かします。その後にp=none相当の監視方針でレポートを受け、Webフォーム・複合機・請求・予約・メール配信など正規の送信元が含まれるかを確認します。レポート先には大量の集計メールが届くことがあるため、専用の解析手段を用意します。
正規送信が整合していることを確認してから、隔離や拒否の方針を段階的に検討します。転送やメーリングリストでは認証結果が変わる場合があります。いきなり拒否へすると自社メールへ影響するため、レポートと業務テストを根拠に進めます。
切り替えは受信箱と送信認証を先に用意する
実務では次の順番で進めます。
- 権威DNS、現在のレコード、TTL、旧メール環境を記録する
- 利用者、エイリアス、グループを新しいメール環境へ作る
- 全送信経路を棚卸しし、SPFとDKIMを準備する
- 外部アドレスとの送受信と認証結果をテストする
- 公式値に従ってMXを変更し、旧MXを整理する
- 新旧両方の配送ログを確認し、DMARCを段階導入する
TTLを事前に短くする場合も、すでに保存された古い情報が即座に消えるわけではありません。変更後は一つの確認サイトだけに頼らず、複数の外部DNSリゾルバーからMXとTXTを取得します。社内ネットワークのキャッシュだけを見て判断しません。
切り替え直後は、外部サービスから新環境へ届くことと、新環境から複数の受信サービスへ届くことを確認します。エイリアス・グループ・フォーム通知も別に試します。件名へテスト日時を入れ、どの経路の結果か分かるようにします。
DNS設定とメールデータ移行を別の作業として管理する
MX変更は新しく届くメールの配送先を変えます。旧サーバーに保存された過去メールは、新環境へ自動移行しません。移行方法・対象期間・重複・フォルダー構成を別に計画し、旧環境を解約する前に必要なデータを確認します。
パソコンやスマートフォンのメールソフトも、新しい受信・送信サーバーと認証方式へ変更が必要です。Webメールだけで確認を終えると、旧設定の端末から送れない場合があります。共用端末や複合機も一覧にします。
運用資料には、権威DNS・受信サービス・全送信元・レコードの目的・変更日・確認結果・旧環境の終了日を残します。固定値だけを記録せず、値を取得する公式管理画面と担当者も記載します。将来送信サービスを追加したときは、SPF・DKIM・DMARCの整合を導入条件にします。
