MENU

Azure Networkingで確認すべきNamecheapとMicrosoft 365のDNS接続手順と注意点

Azure

Namecheapで管理している独自ドメインをMicrosoft 365に接続する場合、管理者が行う作業は「ドメイン所有権の確認」と「Microsoft 365各サービス用のDNSレコード追加」です。2026年5月に更新されたMicrosoft Learnの公式手順では、TXT、MX、CNAME、SRVレコードをNamecheap側で手動追加し、メール、Microsoft Teams、Intune／MDMを利用できる状態にする流れが整理されています。(Microsoft Learn)

特に注意したいのは、すべてのレコードを一律に追加するのではなく、利用するMicrosoft 365サービスに応じて必要なDNSレコードだけを設定する点です。メールを使うならMX・Autodiscover・SPF、Teamsを使うならSRVとCNAME、IntuneやMDMを使うならデバイス登録用CNAMEを確認します。DNSの変更は通常15分程度で反映されることがある一方、インターネット全体への伝播には時間がかかる場合があるため、移行作業は業務時間外や影響の少ない時間帯に計画するのが安全です。(Microsoft Learn)

目次

Azure Networkingの「Connect DNS Records at Namecheap to Microsoft 365」とは

「Connect DNS Records at Namecheap to Microsoft 365」は、NamecheapでDNSをホストしている独自ドメインをMicrosoft 365に接続するための公式手順です。

ここでいうDNS接続とは、Azure Networkingそのものの仮想ネットワーク設定を変更する作業ではありません。Microsoft 365のメール、Teams、Intuneなどが独自ドメインで正しく動作するように、外部DNSプロバイダーであるNamecheapに必要なDNSレコードを登録する作業です。

Microsoft 365管理センターでドメインを追加したあと、Namecheapの「Advanced DNS」画面でレコードを作成します。Microsoft側は、そのDNSレコードを参照して次のようなことを判断します。

  • そのドメインを本当に組織が所有しているか
  • メール配送先がMicrosoft 365に向いているか
  • Outlookなどのクライアントが自動検出できるか
  • Teamsの通信に必要な名前解決ができるか
  • IntuneやMDMでデバイス登録先を解決できるか

つまり、この更新情報の実務上のポイントは「Namecheapを使っているMicrosoft 365管理者が、どのDNSレコードを、どの順番で、どのサービス向けに追加すべきか」を明確にした点にあります。

何が変わるのか：管理者が見るべき更新ポイント

今回の公式情報は、新しいMicrosoft 365機能を追加する発表というより、NamecheapでのDNS設定手順を現行の管理画面に合わせて整理した運用ガイドとして捉えるのが適切です。

Microsoft Learnの内容では、Namecheapで追加するDNSレコードがサービス別に分類されています。対象は、ドメイン検証用TXT、メール用MX／CNAME／TXT、Teams用SRV／CNAME、Intune／MDM用CNAMEです。(Microsoft Learn)

対象サービス追加する主なDNSレコード目的
ドメイン所有権確認TXTMicrosoft 365に対してドメイン所有を証明する
Exchange Online／メールMX、CNAME、TXTメール配送、自動検出、SPFによる送信元認証
Microsoft TeamsSRV、CNAMETeamsのサインインやユーザー間通信を補助する
Intune／MDMCNAMEデバイス登録やモバイルデバイス管理を補助する

実務での変更点として重要なのは、作業対象が「Microsoft 365管理センター」だけで完結しないことです。Namecheap側のDNS画面で手動設定を行い、その後Microsoft 365管理センターで検証します。

また、NamecheapはMicrosoftが管理するサイトではありません。Namecheap側の画面構成やラベルが変更される可能性があるため、公式手順と実際の画面が完全に一致しない場合は、項目名ではなく「レコード種別」「Host」「Value」「TTL」「Priority」などの意味で照合する必要があります。(Microsoft Learn)

対象者：NamecheapでDNSを管理しているMicrosoft 365管理者

この手順の対象者は、主に次のような管理者です。

  • Namecheapで取得・管理している独自ドメインをMicrosoft 365で使いたい
  • Microsoft 365管理センターにドメインを追加したが、DNS検証が未完了
  • Exchange Onlineで独自ドメインのメールを送受信したい
  • TeamsやIntuneを独自ドメイン環境で利用したい
  • DNSをAzure DNSではなくNamecheap側で管理している

一方で、すでにDNSをAzure DNS、Cloudflare、Route 53、社内DNSなどに移管している場合、このNamecheap向け手順をそのまま適用してはいけません。ドメインのネームサーバーがNamecheapを指していない場合、Namecheapにレコードを追加しても実際の名前解決には反映されないためです。

作業前に、必ず次の2点を確認してください。

確認項目判断基準
ドメインのDNSホスト先NamecheapのAdvanced DNSで管理されているか
Microsoft 365側の状態Microsoft 365管理センターに対象ドメインが追加済みか

Microsoft Learnでも、作業前提としてNamecheapで登録されたドメインを所有していること、Microsoft 365管理センターにドメインを追加済みであることが示されています。(Microsoft Learn)

まず確認すべき全体の作業フロー

NamecheapでMicrosoft 365向けDNSレコードを設定する流れは、次の順番で進めると失敗しにくくなります。

| 手順 | 作業内容 | 管理者の確認ポイント |
| -: | ————————— | ————————— |
| 1 | Microsoft 365管理センターにドメインを追加 | 対象ドメインのスペルが正しいか |
| 2 | ドメイン検証用TXT値を取得 | MS=msXXXXXXXX のような固有値を控える |
| 3 | NamecheapのAdvanced DNSを開く | 対象ドメインを間違えていないか |
| 4 | TXTレコードを追加 | Host、Value、TTLを確認 |
| 5 | Microsoft 365管理センターで検証 | 検証エラー時はDNS伝播を待つ |
| 6 | 利用サービスごとのDNSレコードを追加 | メール、Teams、Intuneの要否を判断 |
| 7 | 既存レコードとの競合を確認 | MXやSPFの重複に注意 |
| 8 | メール配送・自動検出・Teams・MDMをテスト | 実利用に近いアカウントで確認 |

ポイントは、いきなりMXレコードを変更しないことです。MXレコードはメール配送先を変えるため、既存メール環境からMicrosoft 365へ移行する場合は影響が大きくなります。

まずTXTレコードで所有権確認を済ませ、その後にメール切り替えのタイミングを決めるのが安全です。

ドメイン所有権確認用TXTレコードの注意点

Microsoft 365で独自ドメインを利用するには、最初にドメイン所有権を証明する必要があります。Namecheap側にTXTレコードを追加し、Microsoft 365がその値を確認できれば検証完了です。

公式手順では、TXTレコードの例として次の形式が示されています。

TypeHostValueTTL
TXT@MS=msXXXXXXXX30 min

MS=msXXXXXXXX はサンプルです。実際にはMicrosoft 365管理センターで表示される、そのドメイン専用の値を使います。別ドメインの値を流用しても検証は通りません。

このTXTレコードは、ドメイン所有権の確認に使われるものです。Microsoft Learnでは、検証完了後に削除でき、他の機能には影響しないと説明されています。(Microsoft Learn)

ただし、実務ではすぐに削除せず、移行作業が完全に終わるまで残しておく運用もあります。将来的な再検証やトラブル調査で役立つ場合があるためです。削除する場合は、社内のDNS変更履歴に「Microsoft 365ドメイン検証完了のため削除」と記録しておくと安全です。

よくある失敗

TXT検証で失敗しやすい原因は、次の3つです。

失敗例原因対処
Microsoft 365で検証できないValueのコピー漏れ、余分な空白管理センターの値を再コピーする
別ドメインに登録しているNamecheapで編集対象を間違えたDomain Listで対象ドメインを確認する
すぐに検証して失敗するDNS伝播が完了していない数分からしばらく待って再試行する

DNSは即時反映とは限りません。画面上で保存できていても、Microsoft 365側から参照できるまで時間差があります。

メールをMicrosoft 365に向けるMXレコードの確認ポイント

独自ドメインのメールをMicrosoft 365で受信するには、MXレコードをMicrosoft 365向けに設定します。公式手順では、NamecheapのMAIL SETTINGSでCustom MXを選び、Microsoft 365管理センターから取得したMX値を登録する流れです。(Microsoft Learn)

公式例では、MX値は次のような形式で示されています。

TypeHostValuePriorityTTL
MX Record@<mx-value>.mail.protection.outlook.com.030 min

ここで重要なのは、<mx-value> が組織ごとに異なる点です。自社ドメイン用にMicrosoft 365管理センターで表示された値を使います。

また、公式手順では、追加したMicrosoft 365向けMXレコード以外のMXレコードを削除するよう案内されています。これは、複数のMXレコードが残っていると、メールが旧メールサーバーに配送される可能性があるためです。(Microsoft Learn)

MX変更は「メール移行の本番切り替え」と考える

MXレコードの変更は、単なるDNS作業ではなく、メール配送先の切り替えです。

たとえば、これまでNamecheapのメール、Google Workspace、オンプレミスのメールサーバーなどを使っていた場合、MXをMicrosoft 365に変更すると、新着メールはMicrosoft 365側へ流れます。旧環境にメールボックスが残っている場合でも、新規メールがそちらに届かなくなる可能性があります。

本番切り替え前に、次の項目を確認してください。

  • Microsoft 365側に全ユーザーのメールボックスが作成されている
  • 必要なライセンスが割り当てられている
  • 旧メール環境からのデータ移行方針が決まっている
  • 共有メールボックスやメーリングリストの移行漏れがない
  • 外部からのテストメール受信を確認できる担当者がいる

MX変更後に問題が起きると、受信メールの遅延や取りこぼしにつながります。小規模組織でも、作業前にロールバック手順をメモしておくことをおすすめします。

Outlook自動設定に必要なAutodiscover CNAME

Outlookや一部のメールクライアントでアカウントを自動設定しやすくするには、Autodiscover用のCNAMEレコードを追加します。

公式手順では、次の値が示されています。

TypeHostValueTTL
CNAMEautodiscoverautodiscover.outlook.com.Automatic

この設定により、ユーザーがOutlookにメールアドレスを入力した際、Microsoft 365側の設定情報を自動検出しやすくなります。

注意点は、Valueの末尾にピリオドが必要な場合があることです。Microsoft Learnでも、autodiscover.outlook.com. の末尾にピリオドを付ける点が強調されています。(Microsoft Learn)

Namecheapの画面仕様によっては、末尾のピリオドを自動補完または正規化する場合があります。保存後に表示が変わっていても、DNSルックアップで正しく解決できれば問題ありません。

SPF TXTレコードは重複させない

Microsoft 365から送信するメールが迷惑メール扱いされにくくなるよう、SPF用TXTレコードを設定します。

公式手順では、次の値が示されています。

TypeHostValueTTL
TXT@v=spf1 include:spf.protection.outlook.com -all30 min

最も重要な注意点は、SPFレコードを複数作らないことです。Microsoft Learnでも、すでにSPFレコードがある場合は新規作成せず、既存レコードにMicrosoft 365の値を追加して、SPFレコードを1つにまとめるよう注意されています。(Microsoft Learn)

既存SPFがある場合の考え方

たとえば、すでに別のメール配信サービスを使っていて、次のようなSPFレコードがあるとします。

v=spf1 include:example-mail-service.com -all

この場合、Microsoft 365用にもう1行TXTを追加するのではなく、既存のSPFにMicrosoft 365のincludeを統合します。

v=spf1 include:example-mail-service.com include:spf.protection.outlook.com -all

ただし、実際の値は利用しているメール配信サービス、CRM、MAツール、請求書発行サービスなどによって異なります。SPFを編集する前に、自社ドメインからメールを送信しているサービスを洗い出してください。

SPF編集で起きやすいトラブル

トラブル起きる理由確認方法
送信メールが迷惑メール扱いされるMicrosoft 365のincludeが入っていないSPFチェックツールやメールヘッダーで確認
一部サービスからのメールだけ失敗する既存の送信サービスをSPFから消してしまった利用中のメール送信サービス一覧を確認
SPF構文エラーになるTXT値に余分な引用符や改行が入ったDNS確認ツールで構文を確認
SPFが複数存在するTXTレコードを追加しすぎたHost @ のTXTレコードを確認

SPFはメール認証の基本設定です。Microsoft 365への移行時は、MXよりも軽く見られがちですが、送信到達率に影響するため慎重に扱う必要があります。

Teamsを使う場合に必要なSRVとCNAME

Microsoft Teamsを使う組織では、Teams向けのSRVレコードとCNAMEレコードを追加します。公式情報では、Teamsに必要なレコードとして、ユーザー間通信向けのSRVが2つ、サインインやサービス接続向けのCNAMEが2つ示されています。(Microsoft Learn)

Teams向けSRVレコード

ServiceProtocolPriorityWeightPortTargetTTL
_sip_tls1001443sipdir.online.lync.com.Automatic
_sipfederationtls_tcp10015061sipfed.online.lync.com.Automatic

Teams向けCNAMEレコード

TypeHostValueTTL
CNAMEsipsipdir.online.lync.com.Automatic
CNAMElyncdiscoverwebdir.online.lync.com.Automatic

Microsoft Learnでは、Teamsを使う場合のみこれらのDNSレコードを追加するよう説明されています。(Microsoft Learn)

つまり、メールだけをMicrosoft 365で使い、Teamsを利用しない組織では、Teams用DNSレコードを急いで追加する必要はありません。ただし、将来的にTeamsを展開する予定があるなら、初期構築時にまとめて設定しておくと、後日の問い合わせや接続トラブルを減らせます。

Teams設定で見落としやすいポイント

TeamsのDNSレコードは、Exchange Onlineのメール配送と違い、設定ミスがすぐに「メールが届かない」という形では見えにくいことがあります。

そのため、設定後は次のような動作確認を行うと実務的です。

  • 対象ドメインのユーザーでTeamsにサインインできるか
  • 組織内ユーザー同士でチャット・通話ができるか
  • 外部連携やフェデレーションを使う場合、対象機能に問題がないか
  • DNS確認ツールでSRVレコードが引けるか

特にSRVレコードは、通常のAレコードやCNAMEより入力項目が多いため、Service、Protocol、Port、Targetを取り違えやすい部分です。

Intune／MDMを使う場合のCNAME設定

Microsoft IntuneやMicrosoft 365のモバイルデバイス管理を使う場合は、デバイス登録に必要なCNAMEレコードを追加します。公式手順では、次の2つのCNAMEが示されています。(Microsoft Learn)

TypeHostValueTTL
CNAMEenterpriseregistrationenterpriseregistration.windows.net.Automatic
CNAMEenterpriseenrollmententerpriseenrollment-s.manage.microsoft.com.Automatic

これらは、ユーザーがデバイスを登録するときに、適切なMicrosoft側サービスへ誘導するためのDNS設定です。

Intuneを利用していない組織では、すぐに追加しなくても運用できるケースがあります。ただし、将来PCやスマートフォンの管理をIntuneへ移行する予定がある場合、早めに設定しておくと展開時のトラブルを減らせます。

デバイス管理を展開する前の確認項目

IntuneやMDMのDNSレコードだけを追加しても、デバイス管理が自動的に完成するわけではありません。DNSはあくまで登録先を見つけるための入口です。

展開前には、次の項目も確認してください。

  • IntuneまたはMDMを利用できるライセンスがある
  • 対象ユーザーにライセンスが割り当てられている
  • デバイス登録制限やコンプライアンスポリシーが設計済み
  • 既存のMDM製品との併用方針が決まっている
  • 社内端末、BYOD端末、モバイル端末の対象範囲が明確になっている

DNS設定が正しくても、ライセンスやポリシー設計が不十分だと、登録エラーや管理対象外端末の混在が発生します。

管理者・開発者が確認すべき影響範囲

このDNS設定は、単にMicrosoft 365管理者だけの作業ではありません。組織によっては、メール運用、セキュリティ、アプリ開発、ヘルプデスクにも影響します。

影響範囲確認すべきこと
メール運用MX変更のタイミング、旧メール環境との切り替え、共有メールボックス
セキュリティSPFの整合性、将来的なDKIM／DMARC設計、なりすまし対策
Teams運用サインイン、チャット、通話、外部連携の確認
デバイス管理Intune登録、MDM方針、既存管理ツールとの競合
アプリ開発システム通知メールの送信元、SMTPリレー、メール認証
ヘルプデスクOutlook再設定、サインイン不具合、DNS反映待ちの案内

特に開発者が注意したいのは、業務システムから送信しているメールです。

たとえば、Webアプリ、予約システム、ECサイト、請求書発行システムなどが独自ドメインを使ってメール送信している場合、SPF設定を誤るとMicrosoft 365移行後にメール到達率が下がる可能性があります。

Microsoft 365へメールを移行する際は、「人が使うメールボックス」だけでなく、「システムが送るメール」も棚卸ししてください。

Namecheap側で設定する前のチェックリスト

作業前に、次のチェックリストを使うと設定漏れを防ぎやすくなります。

チェック項目確認済み
Namecheapで対象ドメインを管理している
対象ドメインのネームサーバーがNamecheap側を向いている
Microsoft 365管理センターにドメインを追加済み
ドメイン検証用TXT値を取得した
既存MXレコードを確認した
既存SPFレコードを確認した
メール移行の本番切り替え時間を決めた
Teamsを利用するか確認した
Intune／MDMを利用するか確認した
DNS変更前の既存レコードを記録した
失敗時のロールバック手順を用意した

DNS変更前の記録は、スクリーンショットだけでなく、レコード内容をテキストでも残すのがおすすめです。スクリーンショットは見返しにくく、値のコピーにも使いにくいためです。

移行時に失敗しやすいポイント

NamecheapからMicrosoft 365へDNSを接続する作業では、次のようなミスがよく起きます。

失敗しやすいポイント影響防止策
MXを先に切り替えるメールが想定外の環境に届くTXT検証後に計画的にMX変更する
SPFを複数作成するSPF認証が失敗する可能性TXTのSPFは1本に統合する
Value末尾のピリオドを忘れる名前解決が意図通りにならない場合がある公式値をコピーして使う
旧MXレコードを残すメール配送が分散するMicrosoft 365向けMX以外を削除する
Teams用SRVの項目を取り違えるTeams関連機能で不具合が出るService、Protocol、Port、Targetを表で照合する
DNS反映前に判断する設定ミスと誤認する反映時間を考慮して再確認する
Namecheap以外でDNS管理しているレコード追加が反映されない実際の権威DNSを確認する

DNS作業では「保存できたか」ではなく、「外部から正しく引けるか」が重要です。保存後はMicrosoft 365管理センターの検証だけでなく、必要に応じてDNSルックアップツールでも確認してください。

展開時のおすすめ手順

実務では、次の順番で進めると影響を抑えやすくなります。

小規模組織の場合

小規模組織では、作業者と影響範囲が限られるため、比較的シンプルに進められます。

  1. Microsoft 365管理センターにドメインを追加する
  2. NamecheapでTXTレコードを追加する
  3. Microsoft 365でドメイン所有権を確認する
  4. 既存MXとSPFを記録する
  5. 業務時間外にMXをMicrosoft 365へ切り替える
  6. Autodiscover CNAMEとSPFを設定する
  7. テストユーザーで送受信を確認する
  8. 必要に応じてTeams、Intuneのレコードを追加する

小規模でも、MX変更だけは慎重に行うべきです。既存メールがどこに届いているかを確認しないまま変更すると、問い合わせ対応に追われることになります。

中規模以上の組織の場合

中規模以上では、DNS担当、Microsoft 365担当、セキュリティ担当、ヘルプデスクが分かれていることがあります。

この場合は、作業前に次のような役割分担を決めておくとスムーズです。

役割担当作業
DNS担当Namecheapでのレコード追加、既存レコードのバックアップ
Microsoft 365管理者管理センターでのドメイン追加、検証、サービス確認
メール管理者MX切り替え、メール配送テスト、旧環境確認
セキュリティ担当SPF、DKIM、DMARC、送信元サービスの確認
ヘルプデスクOutlook設定、ユーザー問い合わせ対応

中規模以上では、DNS変更そのものより、関係者間の認識ズレがトラブルの原因になります。特に「MXを変える日」と「ユーザーがMicrosoft 365でメールを使い始める日」は明確に合わせてください。

Azure Networking観点での注意点

今回の手順はMicrosoft 365向けDNS設定ですが、Azure Networkingの観点では「名前解決の責任範囲」を明確にすることが重要です。

たとえば、同じ組織で次のような構成を使っている場合、DNS管理が分散しがちです。

  • パブリックDNSはNamecheap
  • AzureリソースのDNSはAzure DNS
  • 社内向け名前解決はオンプレミスDNS
  • VPNやExpressRoute経由で社内システムと連携
  • アプリのメール送信はMicrosoft 365または外部配信サービス

このような環境では、Microsoft 365用レコードをどこに追加するべきかを誤りやすくなります。

判断基準はシンプルです。インターネット上で対象ドメインの権威DNSになっている場所に追加します。Namecheapが権威DNSならNamecheap、Azure DNSが権威DNSならAzure DNSです。

Namecheapでドメインを購入していても、ネームサーバーをAzure DNSに変更している場合、NamecheapのAdvanced DNSにレコードを追加しても効果はありません。ここは管理者が最初に確認すべきポイントです。

設定後に確認すること

DNSレコードを追加したら、次の順番で確認します。

確認対象確認内容
TXTMicrosoft 365管理センターでドメイン検証が成功するか
MX外部メールからMicrosoft 365メールボックスに届くか
AutodiscoverOutlookでアカウント自動設定ができるか
SPFMicrosoft 365から送ったメールがSPFを通過するか
Teams対象ユーザーでサインイン、チャット、通話ができるか
Intune／MDMデバイス登録が想定通りに進むか

メールは、社内からの送信だけでなく、Gmailや他社ドメインなど外部からの受信テストも行ってください。社内送受信だけでは、MX変更の問題を見落とすことがあります。

また、SPFはメールヘッダーで確認すると確実です。単に「メールが届いた」だけでは、SPFやDMARCの状態まで判断できません。

すぐに取るべきアクション

Namecheapで独自ドメインを管理し、Microsoft 365を利用する管理者は、まず現在のDNS管理先と既存レコードを確認してください。

次に、Microsoft 365管理センターでドメインを追加し、TXTレコードで所有権確認を行います。その後、メールをMicrosoft 365へ移行するタイミングに合わせてMX、Autodiscover、SPFを設定します。TeamsやIntuneを利用する組織では、追加のSRV／CNAMEレコードも忘れずに確認しましょう。

特に重要なのは、MXとSPFです。MXはメール配送先を変え、SPFは送信メールの信頼性に関わります。既存環境を記録し、利用中のメール送信サービスを洗い出してから変更すれば、移行後のトラブルを大きく減らせます。

NamecheapとMicrosoft 365のDNS接続は、作業自体は難しくありません。しかし、影響範囲を理解せずに進めると、メール停止、Outlook設定不備、Teams接続不具合、デバイス登録エラーにつながります。まずは対象サービスを整理し、必要なDNSレコードだけを正確に追加することが、安定した展開への近道です。

Azure
DNS Microsoft 365 Azure Networking Namecheap

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次