メールサーバー移行のDNS切り替え手順｜MX・SPF・DKIMの変更順と戻し方

先に結論をまとめます。

1. 新しいサーバーで、今使っているメールアドレスをすべて作ります。ここが済むまでMXは変えません
2. SPFは1本のまま、新旧の送信元を併記します。レコードを2本にしてはいけません
3. DKIMは新しいセレクタを追加します。旧セレクタは残したままにします
4. 実際にメールを送って認証が通ることを確かめてから、MXを新しい値に置き換えます
5. 送受信を確認し、旧サーバーへの新着が止まってから、旧環境を止めます

以下は、この流れをDNSの作業として1つずつ説明したものです。作業そのものは1ステップあたり数分で、全体の長さを決めるのは待つ時間です。

この記事が想定している読者

独自ドメインでメールを使っていて、今のサーバーから別のサーバーへ移すことになった方を想定しています。DNSの管理画面は開いたことがあるものの、MXやSPFが何をしているかまでは詳しくない、という状態を前提にしました。

そのため、出てくる用語はその場で説明します。すでにご存じの場合は読み飛ばしてください。

出てくる用語

最初に、対象と必要なものを確認してください

この記事で扱う作業

扱うのはDNSの設定と、その前後に必要な確認です。

• MXレコードの切り替え
• SPFレコードの書き換え
• DKIMの公開鍵の追加と削除
• DMARCをどう扱うかの判断
• TTLの調整と、反映されたかの確認
• 切り替えに失敗したときの戻し方

次のものは移行先の事業者が用意している手順に従ってください。ただしメールアドレスの作成だけは、MXを切り替える前に終わっている必要があります。作り方は事業者ごとに違いますが、終わったかどうかの確認はステップ5に入れてあります。

• 過去に受信したメールの引き継ぎ
• メールソフトの再設定
• メールアドレスや転送設定の作成手順そのもの
• 移行先の契約と料金の比較

受信と送信では、変える設定が違います

「メールサーバーを移す」と言うとき、実際には別々の2つが動きます。

受信では、送り主のメールサーバーがあなたのドメインのMXレコードを引きます。そこに書いてあるホストへメールを届けるので、MXを新しいサーバーに向ければ以後の受信は新サーバーに入ります。

送信は逆です。あなたが送ったメールを受け取った側が、そのメールが本当にあなたのドメインから出たものかを確かめます。このときに見るのがSPFとDKIMです。

MXを変えてもSPFとDKIMは自動では変わりません。新旧の送信元を併記せずに置き換えると、参照されるDNSの値によっては認証に失敗することがあります。

自分で進められるかを確認してください

次の表がすべて満たせるなら、この記事に沿って自分で進められる可能性があります。満たせない項目があれば、その行の右側に従ってください。

次のどれかに当てはまる場合は、事業者かメール管理者へ相談することをおすすめします。自分だけで進めると、メールが止まったときに戻す手段がなくなります。

• SPFのDNS参照回数が上限の10回に近い
• メールを送る外部サービスをすべて把握できていない
• DMARCを p=reject で運用していて、DKIMの動作を実際のメールで確認できない
• 新旧のサーバーを同時に動かせない
• 旧サーバーの受信状況を確認できない
• DNSの管理者とメールの管理者が別の人である

7つのステップの全体像

待つことになる時間の目安

時間がかかるのは、次の2か所で待つぶんです。

ステップ2の待ち時間は、あなたのドメインの設定値から計算できます。

いずれも「最大で」です。リゾルバがその値を最後に読んだ時点からの残り時間なので、実際にはもっと短く済むことが多くなります。逆に言えば、待つ時間を自分で短くすることはできません。TTLは「その秒数のあいだ覚えておいてよい」という指定なので、こちらから取り消せないためです。

ステップ 1/7：移行の範囲を決めて、今の値を記録してください

1-1 受信と送信のどちらを移すか決めてください

3つの答えを先に決めてください。ここで手順が変わります。

受信だけを移して送信は今のまま、という組み合わせもあります。その場合はステップ3と4を飛ばせます。

1-2 変更前の値を書き出してください

戻すときに使います。次の値を控えてください。この記録がないと、失敗したときに元に戻せません。

• 現在のMXレコード（ホスト名と優先度をすべての行ぶん）
• 現在のSPFレコードの全文
• 現在のDKIMのセレクタ名（分かる範囲で）
• 現在のDMARCレコードの全文
• それぞれのTTLの値

ドメイン設定の診断を実行して結果の画面を残しておくと簡単です。移行のあとにもう一度実行すれば、変わったところと変わっていないところを比べられます。

1-3 新旧を重ねられない場合

契約の期限などで一気に切り替えるしかないこともあります。その場合でもSPFとDKIMだけは先に両方を書いておけます。この2つは複数の送信元を同時に許可できるので、先に足しておくぶんには今の運用に影響しません。

ステップ 2/7：TTLを確認してから短くしてください

2-1 現在のTTLを記録してください

TTLは、そのDNSの設定値をどれだけの時間覚えておいてよいかを示す秒数です（RFC 1035 §3.2.1）。この値が、切り替えたあとに古い設定が残りうる長さを決めます。

たとえばTTLが86400なら、24時間は古い値が返る可能性があります。

2-2 これから値を変えるレコードだけ短くしてください

短くするのは、このあと値を変えるレコードだけです。

300秒程度にしておくと、切り替えたあとに古い値が残る時間も短くなります。

新しいDKIMのセレクタは、これまで存在しなかった名前です。存在しない名前への問い合わせに対する「ありません」という答えも一定時間覚えられますが、その長さはゾーンのSOAレコードで決まり、まだ無いレコードのTTLを下げても変えられません。この仕組みはDNSの設定が反映されないときの確認方法で説明しています。

2-3 短くした値が使われる状態になるまで待ってください

ここが1つ目の関門です。TTLを短くしても、短くする前の値をすでに読み取ったリゾルバには効きません。新しいTTLが効くのは、その値を読んだあとの問い合わせからです。

たとえば元のTTLが86400秒だった場合、直前にその値を読んだリゾルバはそこから24時間、古い設定を返し続けます。短くする作業は、元のTTLの長さより前に済ませておく必要があります。

ステップ 3/7：SPFに新旧の送信元を併記してください

3-1 変更後の参照回数を先に確認してください

SPFの評価には、DNSを引く回数に上限があります。include や a、mx といった指定は評価のたびにDNSを引きます。その合計が10回を超えると評価がPermErrorという結果で終わり、SPFの認証そのものが失敗します（RFC 7208 §4.6.4）。

移行中は新旧の両方を書くので、この回数が一時的に増えます。include の先がさらに include を持っていることもあるため、書いた行数ではなく、たどった先まで含めた回数で数えます。上限に近い状態で始めると、併記した瞬間に超えることがあります。

数え方と、超えたときの減らし方はSPFのDNS参照回数が10回を超える原因と直し方にまとめています。

3-2 1本のレコードに、新の指定を足してください

SPFレコードを2本作ってはいけません。 1つのドメインにSPFレコードが2本あると、評価はPermErrorになり、SPFの認証そのものが失敗します（RFC 7208 §4.5）。新しいサーバーのぶんを別の行として追加するのではなく、いま公開されている1本の中へ書き足してください。

v=spf1 include:{旧サーバーの指定値} include:{新サーバーの指定値} ~all

{} の部分は事業者が指定する値です。移行先の管理画面かドキュメントに書かれているものを使ってください。診断すると、判定できたメールサービスについては生成した値を表示します。

末尾の -all を ~all へ緩める必要はありません。-all は「ここに書いていない送信元からのメールは拒否してよい」という指定です。新旧のどちらも書いてあれば、どちらから送っても該当します。緩めるかどうかは書き漏らしている送信元があるかどうかの問題で、移行そのものが理由になるわけではありません。

3-3 公開された値を確認してください

書き換えたSPFが実際に引ける状態になっているかを確認します。ドメイン設定の診断を実行すると、現在公開されているSPFレコードと参照回数が表示されます。

コマンドで確認する場合は次のようにします。example.jp の部分を自分のドメインに置き換えてください。

dig txt example.jp +short

新旧の両方が入った行が1行だけ返れば成功です。

"v=spf1 include:_spf.old-provider.example include:_spf.new-provider.example ~all"

v=spf1 で始まる行が2行返る場合は、レコードが2本になっています。1本にまとめてください。書き換える前の値がそのまま返る場合は、まだ反映されていません。ステップ2でTTLを短くしてあれば、その秒数を過ぎてからもう一度確認してください。

ステップ 4/7：DKIMの新しいセレクタを追加してください

DKIMの公開鍵は、セレクタという名前で区別してDNSに置きます。セレクタは同時に複数を公開できます。RFC 6376 §3.1 は、1つの署名ドメインが複数の公開鍵を同時に持てるようにするための仕組みとしてセレクタを説明しています。

旧サーバーのセレクタを消す必要はありません。新しいセレクタを追加すれば、新旧のどちらで署名されたメールも検証できます。旧セレクタを消すのはステップ7です。

4-1 新しい公開鍵をDNSへ追加してください

セレクタ名は移行先が決めます。事業者ごとに規則が違い、日付を含むものや、契約ごとにランダムな値が割り当てられるものがあります。診断では、判定できたメールサービスについてはそのサービスが使うセレクタを探しにいきます。分からない場合の調べ方はDKIMのセレクタが分からないときの確認方法にあります。

ここで2つ確認してください。

• レコードの種類がTXTとは限りません。 事業者によっては、鍵そのものではなく事業者側の名前を指すCNAMEを登録する形になります。移行先が案内している種類のとおりに登録してください
• 新旧が同じセレクタ名を使う場合は併存できません。 名前が同じなら、後から登録したほうで上書きされます。この場合は新旧を重ねられないので、切り替えの前後で送信が一時的に認証を通らない時間を見込んでください

4-2 新サーバー側で署名を有効にしてください

公開鍵をDNSに置いただけでは、署名が付いているかどうかは分かりません。署名するのは送信側のサーバーで、その設定が有効になっていなければ、鍵はあるのに署名の無いメールが出ていきます。

4-3 実際に送って、DKIMの合格を確認してください

ここが2つ目の関門です。自分宛にメールを1通送って、届いたメールのヘッダーを見てください。

ヘッダーの中に Authentication-Results という行があります。これは受信側のメールサーバーが、SPF・DKIM・DMARCの認証を実際に評価した結果を記録したものです（RFC 8601 §4）。次のような形で書かれています。

Authentication-Results: mx.example.com;
  spf=pass smtp.mailfrom=example.jp;
  dkim=pass header.d=example.jp header.s=selector2;
  dmarc=pass header.from=example.jp

見るのは3か所です。

• dkim=pass になっていること。dkim=none なら署名が付いていません。新サーバー側で署名が有効になっているかを確認してください
• header.s= が新しいセレクタ名になっていること。旧セレクタのままなら、まだ旧サーバーから送られています
• header.d= が自分のドメインになっていること。事業者のドメインになっている場合、署名はされていてもDMARCの判定には使えません

ヘッダーの出し方はメールソフトによって違います。Gmailなら、メールを開いて右上のメニューから「メッセージのソースを表示」を選ぶと全文が出ます。

出したヘッダーはメールヘッダー解析に貼り付けると読める形にできます。貼り付けた内容はブラウザの中だけで処理され、送信されません。

DMARCを p=reject で運用している場合はここを飛ばさないでください。メーリングリストや転送を経由すると送信元のIPアドレスが変わるためSPFは失敗しますが、DKIMの署名は転送されても残ります。RFC 9989 §7.4 は p=reject を掲げるドメインについて、DMARCの合格をSPFだけに頼ってはならず（MUST NOT）、有効なDKIM署名を適用しなければならない（MUST）と定めています。

なおDMARCそのものは、移行のために引き下げる必要があるとは限りません。DMARCが合格するには、SPFとDKIMのうち少なくとも1つが、送信者として表示されるドメインと揃った状態で通っていれば足ります（RFC 9989 §5.1）。ステップ3と4を踏んでいれば、両方が同時に落ちる時間は生まれません。

ステップ 5/7：MXを新サーバーへ切り替えてください

5-1 全アドレスが新サーバーで受信できることを確認してください

MXを変える前に必ず終わらせてください。 移行先に作られていないアドレス宛のメールは、新サーバーが「そのようなアドレスはありません」として拒否します。この拒否は送り主へのエラーとして返り、旧サーバーを残していても救えません。

次をすべて確認してください。

• 今使っているメールアドレスが、すべて新サーバーに作られている
• 転送だけの設定になっているアドレス（info@ から個人宛への転送など）も作られている
• 別名で受けているアドレス（エイリアス）も作られている
• 部署宛やメーリングリストのアドレスも作られている

作り方は移行先の手順に従ってください。ここで確認するのは「作られているか」だけです。

このあいだ、メールソフトには新旧の両方のアカウントを設定しておくと安全です。切り替えの直後は、送り主によって新旧のどちらに届くかが分かれるためです。

5-2 移行先が指定するMXと優先度を設定してください

移行先が公式に案内している値をそのまま使ってください。優先度の数字もあわせて指定されます。書式で起きやすい間違い（IPアドレスを直接書く、CNAMEを指す）はMXレコードにCNAMEを指定できない理由で扱っています。

旧サーバーのMXは残さず、置き換えてください。 旧サーバーのMXを優先度の低い予備として残すと、新サーバーが一時的に応答しなかったときに旧サーバーへ配送され、そのメールは新しい受信箱に入りません。取りこぼしを防ぐつもりの設定が、逆に取りこぼしを作ります。

設定したあと、公開されているかを確認します。

dig mx example.jp +short

移行先が案内している値と同じホスト名が返れば成功です。たとえば次のように出ます。数字は優先度で、小さいほうが先に使われます。

1 aspmx.new-provider.example.
5 alt1.aspmx.new-provider.example.

旧サーバーのホスト名が返るうちは、まだ切り替わっていません。ステップ2でTTLを短くしてあれば、その秒数を過ぎてからもう一度確認してください。

この時点のDNSレコードの状態

MXは新サーバーだけにしますが、旧サーバーの受信機能は止めません。切り替え前に旧サーバーへ配送されたメールを受け取るためです。

ステップ 6/7：送受信と認証を確認してください

6-1 確認する項目

6-2 外部の宛先に送って、認証結果を見てください

社内どうしのやり取りだけでは、SPFとDKIMが実際に検証される経路を通りません。普段使っているフリーメールなど、外部のアドレス宛にも1通送ってヘッダーを確認してください。

次のようになっていれば、移行は成功しています。

Authentication-Results: mx.example.com;
  spf=pass smtp.mailfrom=example.jp;
  dkim=pass header.d=example.jp header.s=selector2;
  dmarc=pass header.from=example.jp

まず見るのは dmarc=pass です。 DMARCは、SPFとDKIMのうち少なくとも1つが、送信者として表示されるドメインと揃った状態で通っていれば合格します。したがって spf=fail が出ていても、dkim=pass かつ header.d= が自分のドメインであれば dmarc=pass になります。

dmarc=fail が出ている場合は、次の順に確認してください。

• dkim=none なら署名が付いていません。ステップ4-2 に戻ってください
• dkim=pass でも header.d= が事業者のドメインなら、DMARCの判定には使えません。移行先で自分のドメインでの署名を有効にしてください
• spf=fail なら、SPFに新サーバーの指定を書き忘れているか、まだ反映されていません。ステップ3に戻ってください

dmarc=pass であっても、spf=fail を放置しないでください。転送されるとDKIMだけが残るのと同じで、片方に頼ると経路によって結果が変わります。

6-3 診断で見える範囲

診断の反映状況の確認は、ドメインの権威ネームサーバーと、代表的な公開DNSリゾルバの2つを比べています。使っているのはGoogle Public DNSで、応答がない場合はCloudflareです。世界中のすべてのリゾルバを調べているわけではありません。

この2つが一致していれば、権威サーバーの値が公開リゾルバまで届いていることは言えます。ただし取引先が使っているリゾルバがどうなっているかは、そこからは分かりません。

診断で「まだ反映されていない」と出た場合、それは設定が間違っているという意味ではありません。キャッシュが原因であれば、TTLが切れたあとの問い合わせから新しい値が参照されます。

切り替えに失敗したときの戻し方

次のどれかが起きたら、先へ進まずに戻してください。

• 外部から送ったメールが届かない、またはエラーで返ってくる
• 新サーバーで作り忘れていたアドレスが見つかった
• 送ったメールが dmarc=fail になり、原因がすぐに分からない

戻す手順は次のとおりです。

1. MXをステップ1-2で記録した旧サーバーの値に戻します。 ホスト名と優先度を、記録したとおりに書き戻してください
2. SPFとDKIMは戻しません。 新旧を併記したままにしておきます。これらは新旧のどちらから送っても通る状態なので、戻すと逆に認証が落ちます
3. TTLを短くしてあれば、数分から数十分で旧サーバーへの配送に戻ります

戻したあと、原因を直してからもう一度ステップ5をやり直します。MXを戻すだけで復旧できるのは、旧サーバーの受信機能を止めていない場合だけです。 ステップ7を先に進めていると戻せません。

ステップ 7/7：旧サーバーを止めて、古い設定を削除してください

7-1 止めてよい条件

ここが3つ目の関門です。「24時間待つ」「2〜3日待つ」といった時間の目安をよく見かけますが、時間ではなく状態で判断してください。

• MXを切り替えたあと、旧サーバーの受信箱かログを確認して新着が続いていない
• 新サーバーから外部宛に送ったメールが dmarc=pass になっている
• 旧サーバーに残っているメールの引き継ぎが終わっている

停止と解約は同じ日にしないでください。 まず旧サーバーのメール機能だけを止めて、数日おいてから解約します。解約すると受信できなくなり、そこから差し戻すことはできません。旧サーバーの契約にドメインやDNSが紐付いている場合は、解約でそちらも止まらないかを先に確認してください。

7-2 旧のSPF指定とDKIMセレクタを削除してください

旧サーバーからの送信が完全に止まってから消します。止めた直後には消さないでください。 送信の途中だったメールが相手に届くまでには時間差があり、その間に鍵を消すと、届いた時点で署名の検証に失敗します。

1. SPFから旧サーバーの include を消す
2. 数日おいてから、旧セレクタのDKIMレコードを削除する

この2つを消すまでが移行です。残したままにすると使っていない送信元を許可し続けることになり、SPFの参照回数も無駄に消費します。

7-3 TTLを元の値に戻してください

ステップ2で短くしたTTLを、元の値に戻します。300秒のままにしておくと、リゾルバがそのレコードを何度も引き直すことになります。

元の値はステップ1-2で記録してあります。

7-4 最後にもう一度診断してください

削除まで終わったら、もう一度ドメイン設定の診断を実行してください。ステップ1で記録した内容と比べれば、意図した形になっているかを確認できます。

利用中のDNS事業者の管理画面でどこを触るかは、事業者別の設定手順にまとめています。