独自ドメインを Microsoft 365 に追加する手順｜メールを止めずに DNS を切り替える順番
独自ドメインを Microsoft 365 に追加するときは、所有の確認の TXT を先に入れ、全員のメールボックスを作ってから、MX・autodiscover の CNAME・SPF の TXT を同じ時間に切り替えます。メールの届け先が変わるのは MX だけ。TTL の下げ方、Domain Connect のウィザードを止める場所、既定のドメインと onmicrosoft.com の扱いを、Microsoft Learn の手順と管理センターの画面で整理します。
目次 クリックで開く
この記事の要点
- 独自ドメインの追加は、DNS を2回に分けて書き換えます。所有の確認の TXT は今のメールに影響しないので先に済ませ、メールの届け先を変える MX は、全員のユーザーとメールボックスを作ってから変えます。
- 切り替えの日は、前もって MX の TTL を3,600秒以下に下げておき、受け取るメールの少ない夕方か週末に、MX・autodiscover の CNAME・SPF の TXT を同じ時間帯に変えます。SPF が既にあれば、新しく作らず今の1本に足します。
- DNS の事業者が Domain Connect に対応していると、管理センターのウィザードは MX まで一度に書き換えにいくので、メールボックスがそろうまでは所有の確認で止めます。
会社のドメインのメールを Microsoft 365 に移そうとして、管理センターの「ドメインの追加」まで来たものの、DNS を書き換えた瞬間に今のメールが止まらないか、Web サイトまで巻き込まないかが気になって手が止まっている方に向けた記事です。
結論から言うと、メールの届け先が変わるのは MX レコードを変えたときだけです。所有の確認のために入れる TXT は今のメールに影響せず、MX と一緒に変える CNAME と SPF も、順番を守れば今のメールの受け取りを止めません。切り替えの日に届くのが遅れるメールへの備えも、手順3に書きます。
この記事では、メールボックスがそろうまでは管理センターのウィザードを所有の確認で止め、MX は切り替えの日に入れる順番を、レコードごとに書きます。Microsoft 365 と Google Workspace の導入・移行を支援している当社が、Microsoft の説明と、当社の検証用の環境で開いた管理センターの画面をもとに、すすめている順番です。
始める前に：今のメールの行き先と、DNS を書き換えられる人を確かめる
独自ドメイン（Microsoft の説明では「カスタム ドメイン」）を Microsoft 365 に足す作業は、管理センターの中だけでは終わりません。ドメインの DNS の設定は、ドメインを買った事業者や DNS を預けている先（以下、DNS の事業者）の画面にあり、そこを2回書き換えます。1回目は所有の確認、2回目はメールの届け先の切り替えです。ドメインの追加・変更・削除には、ビジネスプランまたはエンタープライズプランの「ドメイン名管理者」である必要があります。テナント全体に響く変更のため、カスタマイズした管理者の役割や一般のユーザーではできません（カスタム ドメインを追加する）。
4つのうち、見落とすとメールが止まりかねないのは Domain Connect（管理センターから事業者の画面に移って承認すると、DNS のレコードが入る仕組み）です。対応した事業者なら、承認するだけで、所有の確認の TXT もメールのレコードも入ります。ただし、こうして設定を終えると「カスタム ドメインの設定が完了すると、ドメインの MX レコードが Microsoft 365 を指すよう更新されます。」とされていて、その時点でドメインのすべてのメールが Microsoft 365 に送られ始めます（カスタム ドメインを追加する）。事業者によっては、今の MX を自動で消すよう提案されることもあります（DNS レコードを追加してドメインを接続する）。どこで止めるかは手順1の最後に書きます。
Web サイトのレコードは、この作業では書き換えません。DNS の事業者の画面で書き換えるのは、この記事に出てくる TXT・MX・CNAME だけで、Web サイトの A レコードなどはそのままにします。Domain Connect の手順も、Web サイトには影響しません。所有の確認で、Web サイトにテキスト ファイルを置く方法を選んだときだけは、Web サイトの側にも作業があります（手順1）。
全体の日程（何週目に何をするか）はMicrosoft 365 導入の手順の記事に、過去のメールの中身を移す方法は、レンタルサーバーからならメールサーバー移行の記事に、Google Workspace からならGoogle Workspace から Microsoft 365 への乗り換えの記事に書いています。この記事は DNS の順番に絞ります。
手順1：ドメインを追加し、TXT で所有を確かめる（今のメールはそのまま）
Microsoft 365 管理センターの左のメニューで［設定］>［ドメイン］を開くと、テナント（Microsoft 365 の契約の単位）に追加済みのドメインが並びます。当社が開いたときは、「(既定)」の付いたドメインが1行だけ並んでいました。独自ドメインを足す前のテナントでは、申し込みで付いた onmicrosoft.com のドメインが既定のドメインです（ドメインに関する FAQ）。上の［ドメインの追加］から始めます。初めて独自ドメインを足すときは、［セットアップ］のページの「カスタム ドメインのセットアップを取得する」からも始められます（この入口は、当社は開いていません）。
［ドメインの追加］を選ぶとウィザードが開きます。最初の画面の左の段は「ドメインの追加（ドメイン名）／ドメインの接続／完了」で、右に［ドメイン名］の欄が出ます。example.co.jp のように、@ の後ろに使うドメインをそのまま入れ、［このドメインを使用する］を選びます。この画面の下の動画「ドメインを追加する方法」に添えた説明には「…一般的なドメイン レジストラーを使用している場合、簡単な 3 段階のプロセスです。そうでない場合は、自分で DNS レコードを更新できます。」とあります。ただし、DNS の事業者が Domain Connect に対応していて、設定を最後まで進めると、MX まで書き換わります（「始める前に」の節）。どこで止めるかは、この節の最後に書きます。
次の画面の題は「ドメインを所有していることを確認する」で、左の段に「ドメインの確認」が加わります。当社が例のドメインを入れたときは、所有を確かめる方法が3つ並び、初めから1つ目の「ドメインの DNS レコードに TXT レコードを追加する」が選ばれていました。
DNS の事業者が Domain Connect に対応している場合は、同じ題の画面でも中身が違います。Microsoft の説明では、この画面に事業者の名前が出るので、それが正しいかを確かめて［確認］を選びます。事業者の画面が別のウィンドウで開き、そこでサインインして TXT の追加を承認すると、所有の確認が済みます。当社が例のドメインを入れたときは、この形の画面は出ませんでした。
手動で進めるなら、ふつうは TXT を選びます。この先の画面は当社は開いていないため、ここからの画面の名前は Microsoft の説明の表記です。［続行］を選ぶと、DNS に入れる TXT の値（MS= で始まる文字列）が出ます。それを DNS の事業者の画面で TXT として入れ、管理センターに戻って［確認］を選びます。TXT を足してから確認できるまでは最大10分、事業者によってはさらに最大48時間かかります（カスタム ドメインを追加する）。TXT は今のメールの届け先に関係しないので、申し込んだ週のうちに入れて構いません。
2つ目の MX で確かめる方法は、画面にも「TXT レコードがドメイン ホストまたはレジストラーでサポートされていない場合にのみ推奨されます。」とあるとおり、TXT を足せない事業者のためのものです。この方法では、確認用の MX の優先度の欄を大きな数字にして、優先順位を今の MX より低くします。そうしないと、今のメールサービスとのメールが中断します（カスタム ドメインを追加する）。
途中で閉じたドメインは「セットアップ未完了」で残る
［このドメインを使用する］を選んだ時点で、そのドメインは一覧に加わります。当社が架空の example.co.jp で試し、所有を確かめる方法を選ぶ画面で［閉じる］を選んだところ、一覧には状態が「セットアップ未完了」の行が残りました。その行の［…］のメニューには［セットアップの開始］と［ドメインを削除］があります。綴りを間違えたなど要らない行は［ドメインを削除］で消せます。消すときの確認には、DNS の事業者での登録や契約は取り消されないと出ます。当社も撮った後にこの行を［ドメインを削除］で消し、一覧が元の1行に戻ったことを確かめました。
確認が済んだら、メールのレコードの画面で止める
確認が通ると「ドメインの接続方法」の画面に進み、そのまま［続行］を選ぶと、メールなどに要る DNS レコードを足す画面［DNS レコードの追加］に進みます。Domain Connect に対応した事業者では、この画面で［DNS レコードの追加］を選ぶと事業者の画面が開き、そこで承認すると MX まで書き換わります。メールボックスがまだそろっていなければ、ここでウィザードを閉じます。DNS のレコードは、ドメインを追加するときに飛ばしても後から足せます。
手順2：MX を変える前に、ユーザーとメールボックスを全員分作る
進める順番は「独自ドメインを追加 → ユーザーを追加 → MX」です。ドメインを先にするのは、ユーザーを最初から yamada@example.co.jp のような独自ドメインの名前で作れて、「ユーザーを 2 回設定する」手間が省けるためです（DNS レコードを追加してドメインを接続する）。ユーザーを MX より先にするのは、MX を変える前にメールボックスを作っておけば、メールが前のサービスから Microsoft 365 に移っても、ユーザーは受け取り続けられるためです。
「全員」には、そのドメインでメールを受け取るすべての宛先が入ります。社員一人ひとりのほかに、問い合わせ先や代表のアドレスのような共有の宛先も、共有メールボックスやグループとして作っておきます。切り替えた後は、作っていない宛先へのメールを受け取るメールボックスが Microsoft 365 にありません。
アカウントのアドレスを独自ドメインにするには（新しく作る人・作ってある人）
既定のドメインは、新しく作るアカウントのアドレスに使われるドメインです。［設定］>［ドメイン］で独自ドメインを選び、［既定に設定］を選びます（この画面名は Microsoft の説明の表記で、当社は押していません）。既定を選ぶには、独自ドメインが少なくとも1つ追加されている必要があります。「既定のドメインを変更すると、新しいアカウントにのみ影響します。」とされていて、既にあるアカウントのアドレスは変わりません（ドメインに関する FAQ）。独自ドメインを足す前に、社員のアカウントを onmicrosoft.com のドメインで作っていた場合は、ユーザーの詳細の［アカウント］タブの［ユーザー名の管理］から1人ずつ、または［アクティブなユーザー］で複数を選んで［ドメインの変更］から変えます（画面名は Microsoft の説明（ドメインを削除する）の表記）。
onmicrosoft.com のドメインは、残したまま通常のメールには使わない
申し込みで付いた onmicrosoft.com のドメインは、名前を変えることも消すこともできません（新しい onmicrosoft.com のドメインを足して、置き換えることはできます）。Microsoft 365 が裏側で使い、独自ドメインを外したときの予備の届け先（フォールバック ドメイン）にもなるためです。SharePoint の URL は申し込みで付いた最初の名前で作られ、置き換えても変わりません。onmicrosoft.com のドメインはテストだけに使い、通常のメールは送らないことが勧められています。2025年10月15日からは、onmicrosoft.com のドメインから送るメールに、外部の宛先が24時間あたり100人を超えると送信を制限することがある仕組みも入っています（onmicrosoft.com フォールバック ドメインを追加または置換する）。社員のアドレスは、切り替えの前に独自ドメインへ移しておきます。
一部の人だけ先に試したいとき
全員のメールボックスがそろう前に、数人だけで Microsoft 365 のメールを試したいなら、MX を変えずに試す方法（Microsoft の説明では「パイロット」）があります。今のメールサービスに転送の機能があること、DNS のレコードを Microsoft 365 に預けず、DNS の事業者のところで管理していることが条件で、ユーザーがごく少ない場合に勧められている方法です（カスタム ドメインからの Microsoft 365 のパイロット）。全員を移す前提なら、この記事の順番で進めます。
手順3：切り替えの日に、MX・CNAME・SPF を同じ時間に変える
全員のメールボックスがそろったら、メールの届け先を切り替えます。管理センターで［設定］>［ドメイン］から独自ドメインを開き、［DNS レコード］から［DNS の管理］を選ぶと、手順1で閉じた「ドメインの接続方法」のウィザードに戻ります。［DNS レコードの追加］の画面で「Exchange と Exchange Online Protection」が選ばれていることを確かめ、MX・CNAME・TXT の欄を開くと、DNS の事業者に入れる値が出ます。Domain Connect に対応した事業者で、今の MX を自動で消させずに自分で入れたいときは、［続行］の代わりに［その他のオプション］から［独自の DNS レコードの追加］を選びます。
前もって、MX の TTL を下げておく
TTL は、ほかの会社のメールサーバーが、自社のドメインの MX を覚えておく時間です。TTL が切れる前に MX を変えると、送ってくる側はまず前の場所に送ろうとし、それから変わったことに気づくため、届くのが遅れます。そのため、移行を始める前に MX の TTL を3,600秒（1時間）以下に下げておくことが勧められています。MX が複数あれば、それぞれ下げます（カットオーバー移行）。
当社の考え下げるのは、切り替えの日から見て、今の TTL の長さ以上前にします。たとえば今の TTL が1日なら、1日以上前に下げておかないと、下げる前の値を覚えている送り手が残ります。
入れる3本と、前の MX をどうするか
- MX（必須）：ホスト名は
@（ドメインそのもの）、値は管理センターに出たものをそのまま写します。値はテナントごとに違うので、ほかの記事の例を使いません。優先度は使える中でいちばん高く（通常は 0）します。前のメールサービスの MX が残っていれば、消すか、優先度を Microsoft 365 より低くします。MX の優先度は数字が小さいほど高く、0 は 10 より高い扱いです。TTL は、DNS レコードの手順のページの表では 3600（1時間）で、Exchange Online が対応するのは6時間（21,600秒）未満です。 - autodiscover の CNAME：ホスト名は
autodiscover、値は管理センターに出たもの（通常はautodiscover.outlook.com）です。Outlook などのアプリが、メールアドレスを入れるだけでサーバーの設定を見つけるためのもので、省略はできますが、強く勧められています。同じ名前の CNAME は1本しか置けないので、前のメールサービスの autodiscover があれば書き換えます。 - SPF の TXT：Microsoft 365 だけから送るなら
v=spf1 include:spf.protection.outlook.com -allです。ただし、ドメインに SPF の TXT が既にあれば、新しく作らず、今の1本にinclude:spf.protection.outlook.comを足します。前のメールサービスの値は消しません。同じドメインに SPF の TXT が2本あると、受け取る側の SPF の確認はエラー（permerror）になります（SPF の設定）。
3本を同じ時間に入れるのは、MX を変えると社員は Microsoft 365 のメールボックスで受け取り、返信も Microsoft 365 から送るようになるためです。SPF に Microsoft 365 の値が入っていないと、切り替えた直後から送るメールが受信側の SPF の確認に通りません。
切り替えの日をいつにするか
今のメールサービスから Microsoft 365 への切り替えには通常2日かかり、DNS の変更は通常1〜2時間で効き始めるものの、インターネット全体に行き渡るまで最大72時間かかることがあります。そのため、受け取るメールが少ない夕方か週末に切り替えることが勧められています（セットアップを計画する）。
行き渡るまでの間は、前のサーバーに届くメールも残ります。MX を変えても、すでに前のサーバーにあるメールは、移さない限りそこに残ります。当社の考え前のメールサービスの契約とメールボックスは72時間より長く残し、その間に前のサーバーに届いたメールを見て、Microsoft 365 に移します。
手順4：切り替えた後に、メールが届くかを確かめて前の MX を片付ける
MX を変えて1〜2時間たったら、社外のメールアドレス（個人の Gmail など）から会社のアドレスに送り、Microsoft 365 のメールボックスに届くかを見ます。逆向きに、Microsoft 365 から社外に送って届くかも見ます。
管理センターの［設定］>［ドメイン］では、ドメインごとの［状態］の列に問題が出ます。問題が出ていれば、ドメインの［…］（その他のアクション）から［正常性の確認］を開くと、直すべきレコードと入れる値が出ます。
メールが Microsoft 365 に届くようになったら、優先度を下げて残していた前のメールサービスの MX を消します（Microsoft 365 の外部 DNS レコード）。当社の考えSPF の TXT に残した前のメールサービスの値は、そのサービスからメールを送ることが無くなったと確かめてから外します。
送信ドメイン認証のうち DKIM と DMARC は、SPF とは別に設定します。手順はMicrosoft 365 で SPF・DKIM・DMARC を設定する記事にまとめています。
うまくいかないときは、症状から見直すレコードを探す
所有の確認が通らないときは、次の3つを疑います。TXT の値を写すときに先頭の MS= を落とした、DNS の事業者の画面で保存の操作をしていない、まだ行き渡っていない（通常は数分、ときに数時間）です（ドメインに関する問題のトラブルシューティング）。
切り替えた後に一部の人にだけ届かないなら、その人のメールボックスが MX を変える前に作られていたかを見ます。作られていなければ、その人のユーザーを作り、ライセンスを割り当てます。手順2に書いたとおり、作るまではその宛先のメールボックスが Microsoft 365 に無いので、それまでに届くメールは Microsoft 365 では受け取れない、というのが仕組みからの当社の読みです。社外からのメールが前のサーバーに届き続けるなら、前のメールサービスの MX が優先度の高いまま残っていないかを見ます。
表の5行目のように、Microsoft 365 から送ったメールが相手の迷惑メールに入る、または届かないなら、SPF の TXT に Microsoft 365 の値（include:spf.protection.outlook.com）が入っているか、SPF の TXT が2本になっていないかを見ます。SPF の確認に通らないメールをどう扱うかは受け取る側のメールシステムによりますが、-all（ハード フェイル）なら通常は破棄され、~all（ソフト フェイル）なら迷惑メールのフォルダーに入ることなどがあります（SPF の設定）。
次にやること
まず DNS の事業者の画面で、今の MX の値と TTL、v=spf1 で始まる TXT が何本あるか、DNS の事業者が Domain Connect に対応しているかを見てください。そのうえで、DNS を書き換えられる人と「所有の確認」と「切り替えの日」の2回の作業日を決めれば、あとはこの記事の順番で進められます。
DNS を預けている先との日程合わせや、切り替えの日の段取りから一緒に進めたい場合は、Microsoft 365 の導入支援でお手伝いしています。
この記事の確かめ方
手順と値は Microsoft Learn（Microsoft の公式の技術文書）の日本語版で、画面は当社の検証用の環境で、どちらも2026年10月29日に確かめました。主に見たページは、カスタム ドメインを追加する、DNS レコードを追加してドメインを接続する、ドメインに関する FAQ、ドメインに関する問題のトラブルシューティングなどで、数字や条件を引いた所には、本文にページへのリンクを付けています。
画面は［ドメインの追加］のウィザードを、所有を確かめる方法を選ぶ画面まで開いて閉じました。所有の確認と DNS の書き換えはしていないため、それより先の画面の名前は Microsoft の説明の表記です。写真の組織のドメイン名は伏せていて、例のドメイン example.co.jp は架空のものです。管理センターの画面と Learn の手順は変わることがあるため、作業の前に各ページの最新を確かめてください。
執筆・監修
Aurant Technologies CAIO（Chief AI Officer）
Microsoft 365 と生成 AI の導入を支援する立場から、Microsoft 365 を管理する方向けにまとめています。
Microsoft 365・Google Workspace の移行と設定のスポット相談
メールの移行、ドメインとDNS、共有アドレスや代理人の権限、新しいOutlookへの切り替え、Copilot・Geminiを使うときの社内ルール。調べた手順で直らないとき、同じことが何人もで起きているときに、いま困っていることを1件から相談できます。