独自ドメインメールでは、受信先を指定するMXと、送信元を確かめるSPF・DKIM・DMARCなどのDNS設定が関係します。メールサービスの契約だけでなく、ドメインのDNSへ必要な値を登録して使います。
サーバー会社の付属メールなら一部が自動設定される場合もありますが、Google WorkspaceやMicrosoft 365など別のサービスでは、案内された値を追加します。WebサイトのAレコードやCNAMEまで、メールのために変える必要があるとは限りません。
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フォーム・複合機・請求・予約・メール配信など正規の送信元が含まれるかを確認します。レポート先には大量の集計メールが届くことがあるため、専用の解析手段を用意します。
正規送信の認証が整っても、すべてのドメインを拒否方針にする必要はありません。転送やメーリングリストで失敗する可能性があるため、現行のDMARC仕様は、利用者が外部のメーリングリストへ投稿する可能性のあるドメインでのp=rejectを推奨していません。用途と実際の受信結果から適用方針を選びます。
切り替えは受信箱と送信認証を先に用意する
実務では次の順番で進めます。
- 権威DNS、現在のレコード、TTL、旧メール環境を記録する
- 利用者、エイリアス、グループを新しいメール環境へ作る
- 全送信経路を棚卸しし、SPFとDKIMを準備する
- 新環境からの送信と認証を試す。MX変更前の外部受信は、提供元の検証方法で確認する
- 公式値に従ってMXを変更し、旧MXを整理する
- 新旧両方の配送ログを確認し、DMARCを段階導入する
TTLを事前に短くする場合も、すでに保存された古い情報が即座に消えるわけではありません。変更後は一つの確認サイトだけに頼らず、複数の外部DNSリゾルバーからMXとTXTを取得します。社内ネットワークのキャッシュだけを見て判断しません。
切り替え直後は、外部サービスから新環境へ届くことと、新環境から複数の受信サービスへ届くことを確認します。エイリアス・グループ・フォーム通知も別に試します。件名へテスト日時を入れ、どの経路の結果か分かるようにします。
DNSを変えても、過去メールと端末設定は移らない
MX変更は新しく届くメールの配送先を変えます。旧サーバーに保存された過去メールは、新環境へ自動移行しません。移行方法・対象期間・重複・フォルダー構成を別に計画し、旧環境を解約する前に必要なデータを確認します。
パソコンやスマートフォンのメールソフトも、新しい受信・送信サーバーと認証方式へ変更が必要です。Webメールだけで確認を終えると、旧設定の端末から送れない場合があります。共用端末や複合機も一覧にします。
受信はできるのにフォーム通知だけ届かない、といった場合は、MX以外の送信経路が原因かもしれません。Webフォームや請求サービスも同じドメインから送るなら、それぞれの認証設定が必要です。メール未着の切り分けでは症状別に説明しています。
