Azure Data Share でパートナーからのデータ共有招待を承諾しようとしたとき、「User Domain Verification Failed」と表示されて先に進めないケースが少なくありません。本記事では、Azure AD/Entra ID のドメイン検証や権限設定、DNS の確認手順まで、原因と具体的な解決方法を順番に解説します。
Azure Data Share の招待が受信できない問題の全体像
Azure Data Share は、別テナント・別サブスクリプション間でデータをセキュアに共有するためのサービスです。しかし、受信側ユーザーが招待（インビテーション）を開こうとした瞬間に「User Domain Verification Failed」というエラーが表示され、ポータル上にも Azure CLI/PowerShell 上にも招待が見えない、という問い合わせが非常に多く発生します。
このエラーは単なる一時的な通信エラーではなく、受信側テナントのドメイン検証やテナント設定が正しく行われていないことを示す重要なサインです。特に、以下のような状況で発生しやすくなります。
- 新しく取得した独自ドメインでサインインしているが、Azure AD/Entra ID 上で「検証済み」になっていない
- TXT レコードを追加したものの、DNS の反映が終わっていない、または誤ったレコードを設定している
- 招待を受け取るユーザーに Azure Data Share 関連のロールが付与されていない
- テナント間の B2B コラボレーション制限や条件付きアクセスにより、招待の引き当てがブロックされている
| 発生タイミング | よくある状況 | 代表的な症状 |
|---|---|---|
| 招待メール内のリンクをクリックした瞬間 | ブラウザで Azure ポータルにサインイン中 | 画面上部に「User Domain Verification Failed」と表示され、招待画面に遷移しない |
| Azure ポータルから招待一覧を開いたとき | 招待されているはずなのに一覧が空 | 「招待が見つからない」「共有が見つからない」と表示される |
| PowerShell / Azure CLI で確認したとき | 送信側では招待が Sent 状態になっている | 受信側コマンドでは招待が 0 件として返ってくる |
「User Domain Verification Failed」エラーの意味を整理する
エラーメッセージに含まれる Domain Verification という言葉が示す通り、このエラーはほぼ確実に「ドメイン検証」に起因します。Azure Data Share の招待は、次のような情報をもとに誰の招待かを判断します。
- ユーザーがサインインしているアカウント（UPN：
[email protected]など）のドメイン部分 - テナントに登録されているカスタムドメインの検証状態
- テナント間の信頼関係（B2B、クロステナントアクセス設定など）
これらの情報に矛盾がある、あるいはカスタムドメインが「未検証」のまま使われていると、Azure 側が「このユーザーは本当にこのドメインを所有している組織の一員なのか？」を判断できず、結果として「User Domain Verification Failed」エラーとなります。
| 要素 | 説明 | エラーとの関係 |
|---|---|---|
| ユーザー ドメイン | UPN の @ 以降の部分（例：@contoso.com） | ここに設定されたドメインがテナントで検証済みでないと、エラーになりやすい |
| カスタム ドメイン | Azure AD/Entra ID に追加する独自ドメイン | TXT レコードで検証されていない場合、「User Domain Verification Failed」の主因となる |
| DNS TXT レコード | ドメイン所有者を証明するために DNS に追加する文字列 | 設定ミスや TTL によるタイムラグがあると、いつまでも検証が完了しない |
原因パターン別のチェックポイント
「User Domain Verification Failed」エラーは、見た目は同じでも裏側の原因は複数存在します。代表的な原因を一覧化すると、次のようになります。
| 原因パターン | 概要 | 確認ポイント |
|---|---|---|
| カスタムドメイン未検証 | Azure AD/Entra ID の「カスタム ドメイン名」で状態が「未確認」または「保留」のまま | TXT レコードが正しく設定されているか、そもそも設定しているか |
| DNS 反映遅延 | DNS プロバイダー側の反映に時間がかかっている | TTL 値、前回の変更からの経過時間、他の DNS キャッシュ状況 |
| サインイン ドメイン不一致 | 招待メールが @contoso.com 宛てだが、ユーザーは @onmicrosoft.com アカウントでサインインしている | メールアドレスとサインインに使っている UPN が一致しているか |
| サブスクリプション無効 | 受信側サブスクリプションが「無効」「支払い問題」などで停止状態 | Azure ポータルのサブスクリプション状態が「有効」になっているか |
| ロール不足 | ユーザーに Data Share 関連のロールがない | 「Reader」「Data Share Contributor」などが付与されているか |
| B2B/ポリシー制限 | 外部ユーザーとのコラボレーションが制限されている | B2B 外部コラボレーション設定、条件付きアクセス、クロステナントアクセス設定 |
解決までの基本ステップ一覧
まずは、次のチェックリストに沿って一通り確認することをおすすめします。多くのケースは、この順番で対応することで解消できます。
| 手順 | 内容 |
|---|---|
| 1. ドメイン検証を確認 | Azure ポータルの Azure AD/Entra ID でカスタムドメインの状態をチェックし、「検証済み」になっているか確認する |
| 2. サブスクリプションと権限を確認 | 受信側サブスクリプションが有効かつ、ユーザーに Reader + Data Share Contributor などの権限が付与されているか確認する |
| 3. ブラウザ対処 | キャッシュ・Cookie を削除し、シークレットモード＋別ブラウザで再試行する |
| 4. 直接 URL で招待一覧へ遷移 | Azure ポータルの Data Share 招待一覧ブレードに直接アクセスして、招待が見えているか確認する |
| 5. PowerShell / Azure CLI で確認 | Az.DataShare モジュールや Azure CLI を利用して、招待が API レベルで見えているか確認する |
| 6. 解決しない場合はサポートにエスカレーション | テナント ID・招待 ID などの情報を整理し、Microsoft サポートに調査を依頼する |
ドメイン検証の確認と復旧手順
Azure AD/Entra ID のカスタム ドメイン状態を確認する
最初に確認すべきは、招待を受信するテナント側のカスタムドメインがきちんと検証済みになっているかどうかです。
- Azure ポータルにグローバル管理者または特権ロール管理者でサインインします。
- 「Entra ID」または「Azure Active Directory」を開きます。
- メニューから「カスタム ドメイン名」を選択します。
- 招待に使っているドメイン（例：
contoso.com）の状態（Status）を確認します。
| 状態 | 意味 | 必要な対応 |
|---|---|---|
| 未確認 | TXT レコードが未設定、または認識されていない | ドメインレジストラ側に TXT レコードを追加し、再検証を実施 |
| 検証保留 | レコードはあるが、反映されていない可能性 | 数時間～最大 72 時間待機し、再度「検証」ボタンを押す |
| 検証済み | Azure からそのドメインの所有者と認識されている | 特に対応不要。次のステップへ進む |
DNS TXT レコードの落とし穴と対策
ドメイン検証がうまくいかない場合、多くは DNS TXT レコードに原因があります。次のポイントを必ず確認してください。
- ホスト名の入力ミス：
@を指定するべきところでドメイン名をそのまま入れている、もしくは逆になっている - 古い TXT レコードが残っている：過去の検証用 TXT レコードが残り、新旧が混在している
- TTL が極端に長い：TTL が 1 日（86400 秒）など長く設定されていると、変更が反映されるまで時間がかかる
DNS の変更は、多くのプロバイダーで「最大 72 時間」程度の反映時間が必要とされます。Azure Data Share の招待がうまくいかない場合は、DNS を変更してすぐにテストするのではなく、十分な時間を置いてから再度試すことも重要です。
サブスクリプション状態と権限（ロール）の確認
サブスクリプションが有効かどうかを確認する
ドメインに問題がなくても、受信側サブスクリプションが「無効」または「保留」状態になっている場合、招待を受け取っても実際のリソース作成が行えず、ポータルや API で不整合が起きることがあります。
- Azure ポータルで「サブスクリプション」を開きます。
- 対象サブスクリプションの「状態」が 有効 になっていることを確認します。
- 課金アカウントや支払いに問題がないかも合わせて確認します。
Azure Data Share を受諾するために必要なロール
Azure Data Share の招待を受諾するには、少なくとも次のロールの組み合わせが推奨されます。
| ロール | 目的 | 付与レベル |
|---|---|---|
| Reader | 対象サブスクリプション / リソースグループの構成を参照する | サブスクリプションまたはリソースグループ単位 |
| Data Share Contributor | Data Share 招待の受諾や共有の管理を行う | Data Share アカウントまたはリソースグループ単位 |
| （代替案）Owner / Contributor | 検証用途で一時的に付与して動作確認する場合 | 必要に応じて一時的に付与し、問題解消後は削除 |
特に、ユーザーが複数テナントや複数サブスクリプションを跨いで利用している場合、「正しいサブスクリプションに正しいロールが付いているか」を丁寧に確認しないと、招待が見えない原因を見落としてしまいがちです。
ブラウザ側の問題を切り分ける
ドメインや権限に問題がなくても、ブラウザのキャッシュや Cookie が悪さをすることがあります。特に、別テナントのアカウントでサインインした直後に、別の招待リンクを開く場合は、セッション情報が混ざりやすくなります。
ブラウザで実施したいチェック
- 現在のブラウザセッションから一旦サインアウトする
- キャッシュと Cookie を削除する（少なくとも
portal.azure.com関連） - シークレット／プライベートウィンドウを開き、そこから招待リンクを開く
- Microsoft Edge、Google Chrome など複数ブラウザで同じ挙動になるか確認する
ブラウザを変えても必ず同じエラーになる場合、その時点で「クライアント側の問題ではない」と判断しやすくなり、サーバー側・テナント設定側の調査に集中できます。
Azure ポータルで招待一覧を直接開く
招待メール経由だと何らかのリダイレクトの問題が絡むこともあります。そのため、一度 Azure ポータルの Data Share 招待一覧画面を直接開いて確認することをおすすめします。
- Azure ポータルにサインインします。
- ブラウザのアドレスバーに、Data Share の招待一覧ブレードの URL を直接入力します。
- 招待が一覧に表示されるか、または空の状態なのかを確認します。
ここで「招待が 0 件」となっている場合、Azure 側がそのユーザーを招待先として認識できていないことを意味します。ドメイン検証や B2B 設定など、テナント構成を重点的に確認する必要があります。
PowerShell / Azure CLI から招待状況を確認する
ポータル上の表示だけでは状況が把握しきれない場合は、PowerShell や Azure CLI を使って API レベルで招待状況を確認するのが有効です。特に、「招待が届いていない」のか「届いているが UI が表示できていない」のかを切り分けるのに役立ちます。
PowerShell で Azure Data Share の招待を確認する例
# 初回のみ（管理者権限で PowerShell を開いて実行）
Install-Module -Name Az.Accounts
Install-Module -Name Az.DataShare
# Azure にサインイン
Connect-AzAccount
# 現在のコンテキスト（サブスクリプション）を確認
Get-AzContext
# 招待一覧を取得
Get-AzDataShareInvitation 上記の Get-AzDataShareInvitation コマンドで、有効な招待が 0 件と返ってくる場合は、そもそも受信側に招待が引き当てられていない可能性が高いです。ドメイン検証や招待先メールアドレスのミスを疑うべきです。
Azure CLI での確認イメージ
Azure CLI を利用している場合も、考え方は同じです。たとえば、ログイン後に Azure Data Share の招待を一覧表示し、件数やステータスを確認します。
# Azure にログイン
az login
# 利用するサブスクリプションを指定（必要に応じて）
az account set --subscription <サブスクリプションIDまたは名前>
# Data Share 招待の一覧を取得（コマンドは環境に合わせて調整）
az datashare invitation list --account-name <アカウント名> --resource-group CLI で招待が見えているのに、ポータルでのみエラーになる場合は、ブラウザキャッシュや UI 側の一時的な不具合も疑うことができます。一方、CLI でも招待が見えない場合は、テナントやドメイン設定に根本原因があると考えられます。
それでも解決しないときに確認したいテナント設定
ここまでの基本的なチェックで解決しない場合は、より深いレベルのテナント設定を疑う必要があります。特に次のポイントは、Microsoft サポートでも確認されることが多い項目です。
B2B 外部コラボレーション設定
- 組織外のユーザーを招待できるか
- 特定のドメイン（例：特定のパートナー企業）からの招待をブロックしていないか
- 既定のアクセスレベルが過度に厳しすぎないか
これらの制限が厳しすぎる場合、Azure Data Share の招待や B2B 招待全般がブロックされ、「User Domain Verification Failed」のようなエラーにつながる可能性があります。
条件付きアクセスとセキュリティ ポリシー
- 特定のクライアントアプリ（ブラウザ、モバイルアプリなど）がブロックされていないか
- 特定の場所／IP アドレスからのアクセスが拒否されていないか
- 多要素認証（MFA）やデバイス準拠が必須条件になっており、満たしていないユーザーがブロックされていないか
条件付きアクセスによって、Azure ポータルへのサインイン自体は成功していても、一部のリソースや操作だけがブロックされるケースがあります。その結果、Data Share 招待の承諾処理だけ失敗し、ユーザー側には「User Domain Verification Failed」といったエラーメッセージしか見えない場合があります。
Microsoft サポートへエスカレーションする際に準備したい情報
ここまでの確認を実施してもなお解決しない場合は、Microsoft サポートへのエスカレーションを検討します。その際、次の情報を事前に整理しておくと、調査がスムーズに進みます。
- 送信側・受信側それぞれのテナント ID
- 問題が発生しているユーザーの UPN（メールアドレス）
- Azure Data Share 招待 ID（可能であれば送信側から取得）
- エラー発生日時とタイムゾーン
- 再現手順（どのリンクをクリックし、どの画面でエラーが表示されたか）
- PowerShell / Azure CLI で取得したログや結果（可能な範囲で）
これらの情報をセットで共有することで、テナント間のポリシーや内部的なエラー状況を、サポート側でより正確に追跡できるようになります。
ケース別のトラブルシューティング例
ケース 1：新しく追加した独自ドメインでのみエラーが発生する
| 状況 | 想定される原因 | 対処のポイント |
|---|---|---|
最近 contoso.com ドメインを追加し、そのユーザーで招待を受けようとするとエラーになる | ドメイン検証が完了していない、または DNS が未反映 | TXT レコードを再確認し、反映完了まで待ったうえで再度ドメイン検証を実行 |
@onmicrosoft.com アカウントでは招待を受諾できる | 新ドメインと既存ドメインで検証状態が異なる | 一時的に @onmicrosoft.com で受諾しつつ、独自ドメイン側の検証を完了させる |
ケース 2：特定のユーザーだけ「User Domain Verification Failed」になる
| 状況 | 想定される原因 | 対処のポイント |
|---|---|---|
| 同じテナントの別ユーザーは問題なく招待を受諾できる | 対象ユーザーだけ UPN ドメインが異なる、または別テナントのゲストアカウントを使っている | 招待メールの宛先アドレスと実際にサインインしている UPN を揃える |
| 対象ユーザーにだけロールが付与されていない | Data Share Contributor などのロール不足 | 動作しているユーザーと比較し、ロール差分を解消する |
ケース 3：複数テナントを使い分けている管理者でのみ発生する
- ブラウザのプロフィール機能やシークレットモードを活用して、テナントごとにサインインセッションを分ける
- 必ず「招待メールを受け取ったテナント」のアカウントでサインインしていることを確認する
- エラーが再現するテナントと再現しないテナントを比較し、ドメイン検証状態や B2B 設定の差分を確認する
トラブルを未然に防ぐためのベストプラクティス
最後に、「User Domain Verification Failed」エラーを発生させないための運用上のコツをまとめます。
カスタムドメインは早期に検証しておく
- テナントを新規構築した直後に、利用予定の独自ドメインをすべて追加・検証しておく
- 検証用 TXT レコードの情報をドメイン運用チームと共有し、更新や削除が行われた場合に把握できるようにする
UPN とメールアドレスをできるだけ揃える
- 「メールアドレスは
@contoso.comだが、サインインは@onmicrosoft.com」のような構成は、外部サービスとの連携時にトラブルを生みやすい - Data Share のようなクロステナント連携を多用する場合は、UPN とメールアドレスを一致させる方針を検討する
定期的な DNS 設定レビュー
- 半年～年に一度は、TXT レコードを含む DNS 設定を棚卸しし、「既に不要なレコード」が残っていないか確認する
- DNS プロバイダーを変更する際には、TXT レコードを含めたすべてのレコードが正しく移行されているか、事前にテストする
トラブルシューティング手順をチーム内で共有する
- 本記事で紹介したチェックリスト（ドメイン検証 → 権限 → ブラウザ → CLI → テナント設定 → サポート）を社内のナレッジとして残しておく
- 新しいドメインを追加した際や、組織変更（ドメイン統合・分割など）があった際には、Data Share を含むクロステナント連携の動作確認をセットで実施する
まとめ：「User Domain Verification Failed」はドメイン検証とテナント構成の見直しが鍵
Azure Data Share の招待承諾時に表示される「User Domain Verification Failed」エラーは、ほとんどの場合、受信側テナントのドメイン検証不備、あるいは テナント構成（B2B やポリシー）との不整合が原因です。
もう一度、解決のポイントを振り返ると次の通りです。
- まずは Azure AD/Entra ID の「カスタム ドメイン名」でドメインが「検証済み」か確認する
- DNS TXT レコードの設定内容と反映状況を確認し、必要であれば十分な時間をおいてから再検証する
- サブスクリプション状態と、ユーザーのロール（Reader + Data Share Contributor など）を見直す
- ブラウザのキャッシュ・Cookie、複数アカウントサインインによる影響を排除する
- PowerShell / Azure CLI で招待が API レベルで存在するかを確認し、UI と API のどちらに問題があるかを切り分ける
- それでも解決しない場合は、テナント ID や招待 ID を整理したうえで Microsoft サポートへエスカレーションする
これらのステップを順番に実施することで、ほとんどの「User Domain Verification Failed」エラーは解消し、Azure Data Share の招待を正常に受諾できるようになります。今後も同様のトラブルが発生した場合は、本記事のチェックリストをたどって、原因を体系的に切り分けていくことをおすすめします。
コメント