【Microsoft 365】ドメイン変更後に一部ユーザーだけログインできない時のDNSとUPNの見直し

会社の合併やブランド変更などでMicrosoft 365のドメインを変更した後、一部のユーザーのみがログインできなくなるトラブルが発生することがあります。この現象は、DNSレコードの不整合やUPN(ユーザープリンシパル名)の未更新が原因であるケースが大半です。本記事では、ログインできない原因を切り分ける方法と、DNS設定・UPN設定の見直し手順を詳しく解説します。

1. ドメイン変更後に一部ユーザーのみログインできない主な原因

ドメイン変更に伴うログイン障害は、大きく分けてDNSの伝搬遅延とUPNの設定漏れが原因です。しかし、一部のユーザーだけが影響を受ける場合、両方の可能性を考慮する必要があります。

1.1 DNSレコードの更新漏れ

Microsoft 365では、テナントのドメインを追加・検証する際に、DNSにTXTレコードやMXレコードを追加します。ドメイン変更後、新しいドメインのDNSレコードが正しく設定されていないと、一部のユーザー(特に新しいメールアドレスを使用しているユーザー)が認証に失敗することがあります。また、TTL(Time to Live)の設定が長いと、古いDNS情報を参照しているユーザーの端末が残ってしまう可能性があります。

1.2 UPNサフィックスとユーザーUPNの不一致

UPNはユーザーのログイン名の一部(例:user@newdomain.com)です。ドメイン変更後、Azure ADやオンプレミスADで新しいUPNサフィックスが追加されていない場合、そのサフィックスを指定されたユーザーは認証できません。また、ユーザーごとにUPNを変更する作業が漏れていると、該当ユーザーだけが旧ドメインのUPNを持ち続け、ログインできなくなります。

1.3 Azure AD Connectの同期設定不良

ハイブリッド環境では、オンプレミスADのUPN変更がAzure ADに同期される仕組みです。しかし、同期ルールで特定のOUのみ対象としている場合、同期対象外のユーザーはUPNが更新されず、ログインできない状態になります。また、同期のフィルタリングやスコープ設定が原因で、一部ユーザーだけが古い情報のまま残ることがあります。

2. ログインできないユーザーを特定するための確認手順

まず、どのユーザーがどのようなエラーでログインできないのかを整理します。以下の手順で情報を収集してください。

1. エラーメッセージの確認:ユーザーに「このユーザーアカウントが見つかりません」と表示されるのか、「パスワードが間違っています」なのかを尋ねてください。前者はUPNまたはアカウント自体の問題、後者は認証情報の問題です。
2. ブラウザのシークレットモードでテスト:キャッシュの影響を排除するため、シークレットモードでログインを試します。これで成功する場合は、ブラウザのキャッシュが原因の可能性があります。
3. 別のネットワークからのログイン試行:自宅のWi-Fiなど、社内ネットワーク外から試してもらいます。社内DNSが古い情報を参照している場合、外部ネットワークでは正常にログインできることがあります。
4. ユーザーごとのUPN確認:管理者がMicrosoft 365管理センターで該当ユーザーのUPNを確認します。プライマリメールアドレスとログインUPNが一致しているか、新しいドメインになっているかをチェックします。
5. Azure AD Connectの同期状況確認:管理者がAzure AD Connectの「最新の同期」の状態を確認し、該当ユーザーが同期対象に含まれているか、エラーが発生していないかを調べます。

3. DNS設定の見直し手順

DNSの不整合を疑う場合、以下の手順で設定を確認・修正します。これらの作業はドメインのDNS管理権限を持つ管理者しか実行できません。

1. 新しいドメインのDNSゾーンを開く:DNS管理コンソール(GoDaddy、Cloudflare、オンプレミスDNSなど)にアクセスし、新しいドメインのゾーンを開きます。
2. TXTレコードの確認:Microsoft 365でドメインを所有確認するために追加したTXTレコード(例:MS=msXXXXXXXX)が存在し、正しい値になっていることを確認します。
3. MXレコードの確認:メールルーティングに使用するMXレコードがnewdomain-com.mail.protection.outlook.comなどのMicrosoft 365のエンドポイントを指しているか確認します。
4. CNAMEレコードの確認:autodiscoverやlyncdiscoverなどのCNAMEレコードが正しく設定されているか確認します。特にautodiscoverはOutlook接続に必須です。
5. TTL値を適切に設定:更新の伝搬を早めるため、TTLを一時的に300(5分)などに下げてください。問題解決後に元の値(3600など)に戻すことを忘れないでください。
6. nslookupやdigで外部から確認:管理者端末でコマンドプロンプトを開き、nslookup -type=txt newdomain.comなどを実行して、レコードが正しく解決されるかテストします。

4. UPN(ユーザープリンシパル名)の設定確認と修正手順

UPNの問題はユーザー個別に対処する必要があります。以下の手順で確認・修正します。

4.1 Azure AD管理センターでUPNサフィックスを追加

1. 管理者としてAzure AD管理センター(https://aad.portal.azure.com)にログインします。
2. 左メニューから「カスタムドメイン名」を選択し、新しいドメインが「確認済み」状態であることを確認します。確認されていない場合は、DNSにTXTレコードを追加して検証します。
3. 「ユーザー設定」から「ユーザー名とパスワード」を選択し、許可されるUPNサフィックスの一覧に新しいドメイン(@newdomain.com)が含まれているか確認します。含まれていなければ追加します。

4.2 影響を受けるユーザーのUPNを変更

1. Azure AD管理センターで「ユーザー」→「すべてのユーザー」を開きます。
2. ログインできないユーザーを選択し、「プロパティ」→「ユーザー名」の項目でUPNを新しいドメインに変更します(例:olduser@olddomain.com → newuser@newdomain.com)。
3. 変更を保存し、「プロファイル」タブでメールアドレスも新しいドメインに合わせて更新します。
4. オンプレミスADと同期している場合は、オンプレミスADでユーザーのUPNを変更し、Azure AD Connectの強制同期(Delta Sync)を実行してください。

4.3 一括変更スクリプトの活用

ユーザー数が多い場合はPowerShellを使用して一括変更すると効率的です。以下のサンプルスクリプトを管理者が実行できます。

Connect-MgGraph -Scopes User.ReadWrite.All
$users = Get-MgUser -Filter "userPrincipalName endsWith '@olddomain.com'"
foreach ($user in $users) {
    $newUpn = $user.UserPrincipalName.Replace('@olddomain.com', '@newdomain.com')
    Update-MgUser -UserId $user.Id -UserPrincipalName $newUpn
}

5. 状況別比較表

原因を特定するための比較表を以下に示します。

症状	考えられる原因	確認ポイント
全ユーザーがログインできない(特にWeb版)	DNSのTXTレコードやMXレコードの欠落	ドメインが「確認済み」になっているか
一部ユーザーのみ「アカウントが見つからない」	UPNが旧ドメインのまま、またはUPNサフィックス未追加	該当ユーザーのUPNと許可されたサフィックス一覧
特定のアプリ(Outlookなど)だけログインできない	CNAMEレコード(autodiscover)の未設定	DNSにautodiscover CNAMEが存在するか
古いメールアドレスではログインできる	UPNは変更済みだが、メールアドレス(proxyAddresses)が未更新	ユーザーのプロキシアドレスに旧ドメインが残っていないか

6. よくある失敗事例とその対策

実際に発生しやすい失敗パターンと、その回避策を紹介します。

6.1 ドメイン検証用TXTレコードを削除してしまった

ドメイン追加時に作成したTXTレコードを、後日「不要になった」と誤って削除するケースがあります。Microsoft 365では、ドメインを所有していることを定期的に確認するため、TXTレコードを削除するとドメインが「未検証」状態になり、一部のサービスに障害が発生します。対策としては、削除せずに残しておくか、Microsoftが推奨する代替検証方法(レコードの永続性)を採用します。

6.2 UPNサフィックスを追加しただけではユーザーUPNは自動変更されない

新しいUPNサフィックスを許可リストに追加しても、既存ユーザーのUPNは自動的に変更されません。多くの管理者がこの点を見落とします。必ずユーザーごと、または一括でUPNを変更するスクリプトを実行してください。オンプレミスADの場合は、ADユーザーとコンピュータで直接編集するか、PowerShellを使用します。

6.3 Azure AD Connectの同期間隔が長い

デフォルトの同期間隔は30分ですが、状況によってはさらに遅延することがあります。ドメイン変更直後は強制同期(Start-ADSyncSyncCycle -PolicyType Delta)を実行して、変更がすぐにAzure ADに反映されるようにします。また、同期エラーが発生していないかイベントログも確認してください。

7. 管理者へ確認する情報

一般ユーザーが自分で解決できない場合、管理者に以下の情報を伝えると問題解決がスムーズに進みます。

• エラーメッセージのスクリーンショット:ログイン画面で表示される具体的な文言をキャプチャします。
• ユーザーのUPNとメールアドレス(新旧):どのアドレスで試したのか、新旧のUPNを明確にします。
• 発生時刻と再現性:毎回発生するのか、特定の時間帯だけなのかを記録します。
• 使用しているアプリとバージョン:Outlook、Teams、ブラウザなど、どのアプリで問題が出ているか。
• ネットワーク環境:社内LANか社外か、VPN使用の有無。

8. まとめ

ドメイン変更後に一部ユーザーだけログインできない問題は、DNSレコードとUPN設定の両面から切り分けを進めることが重要です。最初にエラーメッセージとネットワーク環境を確認し、その後DNSの伝搬状況やUPNサフィックス、ユーザーごとのUPNを調査します。管理者はこれらの確認と修正をシステム全体に影響を与えないよう慎重に行い、必要に応じて一時的な回避策(旧ドメインからのログイン許可)も検討してください。適切な対応により、迅速に問題を解決できます。

👥

Teams/Outlookトラブル完全解決データベース サインイン、接続エラー、メール送受信の不具合など、特有のトラブル解決策を網羅。困った時の逆引きに活用してください。

🔐

会社アカウント・認証トラブル完全解決データベース 職場または学校アカウント、MFA、Authenticator、VPN、権限、会社ポリシーで止まる問題を横断的に確認できます。