Route 53へDNSを移行する

このガイドの対象

Microsoft 365を利用するドメインのDNS管理担当者。対象ドメイン、AWSアカウント、DNSとMicrosoft 365の管理権限を確認します。

既存レコードの確認から切り替え後の動作確認まで、以下の順で進めて結果を記録します。

対応の流れ

詳しい手順

1. 既存のDNSレコードと影響するサービスを確認する

現在のDNSレコードを一覧にし、名前、種類、値、TTLを記録します。Webサイトだけでなく、Microsoft 365やその他の業務システムが利用するレコードも対象にします。

• MX：Exchange Onlineなど、現在のメール受信先と優先度を確認します。
• TXT：ドメイン確認用の値、SPF、DMARCの設定を確認します。
• CNAME：Autodiscover、DKIMなど、利用中のサービスに必要な設定を確認します。
• その他：Webサイトや業務システムで使用するA、AAAA、SRVなどを確認します。

Microsoft 365関連の値は管理画面と照合します。SPFはWebシステムやAWSなどの送信元も確認し、用途が不明なレコードは調査せずに削除しないでください。

2. Route 53に必要なレコードを準備して切り替える

対象ドメインのパブリックホストゾーンを作成し、必要なレコードを登録します。Route 53が作成するゾーンのNS・SOAレコードは、移行元の値で上書きしないようにします。

ネームサーバーを変更する前に、移行元と移行先のレコードを照合し、Route 53側の応答を確認します。切り戻しに使う旧ネームサーバーと設定値、判断基準、連絡先も記録します。

TTLを事前に調整する場合は、変更前のキャッシュが失効する時間を確保します。DNSSECを利用している場合は、DSレコードを含む移行手順を事前に確認してください。

準備が整ったら、利用者への影響が少ない時間帯に、ドメイン登録事業者などの委任設定をRoute 53のネームサーバーへ変更します。切り替え後も旧設定を参照する環境があるため、移行元のDNSは反映と動作を確認するまで維持します。

3. Webサイトとメールの送受信・認証を確認する

切り替え後は、名前解決の結果と実際の業務操作を確認します。DNSの管理画面で設定を保存できたことだけで完了にしないようにします。

• Webサイトが正常に表示されることを確認します。
• Microsoft 365から外部宛て、外部からMicrosoft 365宛ての双方でメールを送り、受信側で到着を確認します。
• 受信したメールのヘッダーなどで、SPF・DKIM・DMARCの認証結果を確認します。
• Microsoft 365のドメイン状態と、Teamsなど利用中の主要サービスの動作を確認します。

確認した日時、利用した環境、結果を記録します。キャッシュの影響で結果が異なる場合は、参照先とTTLを確認し、反映状況を継続して監視します。

完了の確認

移行先のDNSレコードが意図した値を返し、Webサイト、メールの送受信・認証、主要業務サービスが正常に動作することを確認します。作業を実施した記録と、目的を満たした結果の両方を残します。

うまく進まない場合

対象レコード、発生時刻、期待した値と実際の応答、影響するサービスを整理します。レコードの欠落や誤記、委任先、キャッシュ、DNSSECの設定を順に確認してください。

影響が広がる場合は作業を止め、事前に決めた基準で切り戻しを判断します。ネームサーバーを戻してもキャッシュの影響ですぐに復旧しない場合があるため、復旧後も実際の送受信とサービスの動作を確認します。

参考情報

• AWS：利用中ドメインのDNSをRoute 53へ移行する
• Microsoft：Microsoft 365に必要な外部DNSレコード

必要なレコードや設定値は利用サービスと構成によって異なります。実施時に対象環境の管理画面と公式資料を確認してください。