Microsoft Entra ID で外部の SAML / WS-Fed IdP を連携するとき、「メールドメインと IdP ドメインが違うから TXT レコード DirectFedAuthUrl を追加してくれ」と言われて戸惑うことがあります。この記事では、この TXT レコードが何のために使われていて、外部 IdP の追加・検証が終わったあとに削除してよいのかを、実際の動作と管理運用の観点から詳しく解説します。
Entra ID 外部 IdP 追加時の DNS TXT レコードは残すべきか？
結論から言うと、外部 IdP の追加と検証が完了したあとに、DirectFedAuthUrl の TXT レコードを恒久的に残しておく必要はありません。TXT レコードはあくまで「メールドメインと IdP エンドポイントの関連付けを検証するための一時的な手段」として利用され、検証完了後は Entra ID テナント内にドメインと IdP の対応が保存されます。
Microsoft Q&A でも MVP による公式回答として、「TXT レコードはフェデレーション追加時の検証にのみ使われ、保存されたドメイン→IdP 対応を参照してサインインをルーティングするため、削除しても既存のサインインは影響を受けない」と明言されています。
ただし、将来の再設定や別の管理者による再構成を考えると、意図的に残しておくメリットもあります。この記事では、「消してよい」だけで終わらせず、削除する前に確認すべきポイントや、運用設計としてのベストプラクティスまで踏み込んで解説します。
前提シナリオ：メールドメインと IdP ドメインが異なるケース
問題となるのは、次のようなケースです。
ユーザーのメールドメイン：fabrikam.com
IdP のパッシブ認証エンドポイント： https://fabrikamconglomerate.com/adfs
Entra ID の外部 ID（External Identities）の「SAML/WS-Fed IdP とのフェデレーション（Direct federation）」を追加する際、ウィザードで 「ドメイン」と「パッシブ認証 URL」 を入力します。ここで、
- ユーザーのメールアドレス：
[email protected] - IdP の URL：
https://fabrikamconglomerate.com/adfs
のように ドメイン部分が一致しないと、ポータルは次のようなエラーを出したり、TXT レコードの追加を要求します。
「Invalid domain fabrikam.com. Domain should match the passiveSignInUri. Otherwise, please add the passiveSignInUri in the domain DNS TXT record like this DirectFedAuthUrl=…」
このとき、Microsoft の公式ドキュメントでは次のような TXT レコードを fabrikam.com のパブリック DNS に追加する例を示しています。
fabrikam.com. IN TXT DirectFedAuthUrl=https://fabrikamconglomerate.com/adfs
この TXT レコードがあることで、「fabrikam.com ドメインのユーザーは、https://fabrikamconglomerate.com/adfs という IdP で認証されることをドメインの管理者が承認した」ということを Entra ID に証明できます。
TXT レコードが必要になる／不要なパターン
| メールドメイン | パッシブ認証エンドポイント | TXT レコードの要否 |
|---|---|---|
| fabrikam.com | https://fabrikam.com/adfs | 不要（同一ドメイン） |
| fabrikam.com | https://sts.fabrikam.com/adfs | 不要（同一ドメインのホスト） |
| fabrikam.com | https://fabrikamconglomerate.com/adfs | 必要（異なるドメイン） |
| contoso.co.jp | https://login.partner-idp.com/saml | 必要（異なるドメイン） |
このように、パッシブ認証 URL のドメインがメールドメインと一致しないときだけ TXT レコードが必要になります。
TXT レコードが担っている役割
DirectFedAuthUrl の TXT レコードは、次の 2 つの役割を持っています。
- ドメイン所有者の確認（Domain ownership / delegation）
「このメールドメインの管理者が、特定の IdP エンドポイントに紐付けることを了承している」という意志表示です。 - ドメインと IdP の対応関係の検証
Entra ID のフェデレーション設定ウィザードが、メールドメインに対して DNS ルックアップを行い、TXT レコードに書かれた URL と入力されたパッシブ認証 URL が一致するかを確認します。
重要なのは、この TXT レコードは「検証に成功したかどうか」を判断するために参照されるだけという点です。検証が通ったら、その結果は Entra ID の外部 IdP 設定（カスタム SAML/WS-Fed IdP）に 「関連付けられたドメイン」として保存されます。
なぜ削除してもサインインに影響しないのか
ここが本題です。「TXT レコードを消すと、ユーザーのサインイン時に DNS を引きに行っているのでは？」という不安が出がちですが、実際にはそうなっていません。
Entra ID がサインイン時に参照しているもの
外部ユーザーが [email protected] でサインインしようとしたとき、Entra ID が行っていることを簡略化すると次のようになります。
- メールアドレスのドメイン部分（例：
fabrikam.com）を抽出。 - テナント内の外部 IdP 設定に保存されている「関連付けられたドメイン」の一覧を検索。
fabrikam.comが紐付けられている IdP が見つかったら、その IdP のパッシブ認証 URL にリダイレクト。
つまり、サインイン時に見ているのは「テナントに保存されているドメイン→IdP 対応」だけであり、TXT レコードを再度引きに行くわけではありません。Microsoft Q&A の回答でも「TXT レコードはフェデレーション追加時の検証専用であり、サインイン時には保存済みのマッピングを使う」と説明されています。
TXT レコードを削除してもよいタイミング
次の条件をすべて満たしていれば、TXT レコードを削除してもサインインに影響しないと考えて問題ありません。
- Entra 管理センターの該当 IdP 設定に、対象メールドメインが「関連付けられたドメイン」として表示されている。
- 対象ドメインのユーザーでテストサインインを行い、IdP に正常にリダイレクトされている。
- TXT レコードを削除したあとも、DNS キャッシュの期限（TTL）経過後に再度テストして、問題が発生しないことを確認できている。
この状態であれば、TXT レコードはもはや「追加時の証拠」としてしか意味を持ちません。
実務でのおすすめ削除フロー
実際に TXT レコードを削除する場合は、次のようなフローで進めると安全です。
1. Entra ID 側の設定を確認
- Entra 管理センターにサインイン。
- 外部 ID > すべての ID プロバイダー を開く。
- 対象のカスタム SAML/WS-Fed IdP を選択。
- 画面内の「関連付けられたドメイン」の一覧に、対象ドメイン（例：
fabrikam.com）が表示されていることを確認。
2. テストサインイン
- 対象ドメインのユーザー（例：
[email protected]）を用意。 - テスト用アプリや My Apps からサインインを試行。
- 意図した外部 IdP のログイン画面にリダイレクトされ、正常に認証が完了することを確認。
3. DNS から TXT レコードを削除
問題なければ、DNS 管理ツールから対象ドメインに設定した TXT レコードを削除します。
（削除前の例）
fabrikam.com. 3600 IN TXT "DirectFedAuthUrl=https://fabrikamconglomerate.com/adfs"
削除直後は DNS のキャッシュにより、数分〜数時間ほど古い情報が残っている場合があります。そのため、削除後も一定時間おいてからもう一度テストサインインを行うと安心です。
4. 監査・記録
トラブルシュートや監査の観点から、少なくとも次の情報は残しておきましょう。
- 削除した TXT レコードの内容
- 削除日時
- 作業者
- 削除前後に実施したテスト内容と結果
後から「なぜ TXT レコードがないのか？」と聞かれたときにも、これらの記録が役に立ちます。
あえて TXT レコードを残しておくメリット・デメリット
TXT レコードは削除してもサインインには影響しませんが、運用方針として残しておく選択もあります。それぞれのメリット・デメリットを整理してみましょう。
| 選択肢 | メリット | デメリット |
|---|---|---|
| 残す | 将来の再設定時に検証を省力化できる 別組織や別管理者が設定し直す場合のヒントになる DNS 自体が「このドメインはどの IdP と連携しているのか」の簡易ドキュメントになる | 外部から設定意図がある程度読み取れる 複数 IdP を使うようになったときに混乱の元になる場合がある DNS レコードの管理対象が増える |
| 削除する | 不要な公開情報を減らせる DNS 管理がシンプルになる 今後の構成変更時に「古い TXT の消し忘れ」で混乱しにくい | 将来の再設定時には再度 TXT を追加する手間が発生 過去の構成意図が DNS からは読み取れなくなる |
個人的なおすすめとしては、「現行の IdP 連携を今後も長期的に維持するが、頻繁に構成変更しない」環境では削除、「連携形態を見直す可能性が高い」「複数の組織が関わる」環境では残す、といった使い分けです。
TXT レコードを残すべき代表的なケース
以下のケースでは、TXT レコードを残すメリットが比較的大きくなります。
1. 将来、再追加や構成変更を行う予定がある
たとえば、次のような状況です。
- PoC（検証）環境から本番環境へと段階的に移行している
- IdP 側の URL が変わる予定があり、再度フェデレーション設定をやり直す可能性が高い
- テナントを統合・分割するロードマップが見えている
このような場合、TXT レコードを残しておけば、再度 IdP を追加する際の検証ステップをスムーズに再現できます。
2. 別の管理者や別組織が後日設定をやり直す可能性がある
グループ会社やパートナー企業との連携など、複数組織が関係するケースでは、「どのドメインがどの IdP に紐付いているか」を DNS を見ればある程度推測できるようになります。
たとえば、fabrikam.com の DNS に次のような TXT レコードが残っていれば、
fabrikam.com. IN TXT "DirectFedAuthUrl=https://fabrikamconglomerate.com/adfs"
「このドメインは fabrikamconglomerate.com の ADFS とフェデレーションしていた」というヒントになり、後任の管理者が構成の全体像を理解しやすくなります。
新しいドメインを追加するときはどうなるか
同じ IdP に対して、別のメールドメインを追加したいケースもあります。
@fabrikam.comに加えて@fabrikam.co.jpのユーザーも同じ IdP で認証したい- ブランド統合などで新ドメイン
@newfabrikam.comを追加したい
この場合も、新しく追加するメールドメインのドメイン名と IdP のパッシブ認証 URL のドメインが異なるなら、同様に TXT レコードによる検証が必要になります。
つまり、「一度 TXT レコードで検証したから、今後はどのドメインを追加しても不要になる」というわけではありません。メールドメインごとに「ドメイン→IdP」の対応関係を証明する必要があると考えてください。
他のシナリオとの違いに注意
DirectFedAuthUrl の TXT レコードは、Entra ID の「外部 ID（External Identities）」で、SAML / WS-Fed IdP と直接フェデレーションするための仕組みです。
似たような機能が他にもありますが、動作や要件が異なることに注意してください。
Azure AD B2C / Entra External ID（顧客 ID）
B2C / External ID（顧客向け）では、IdP との連携方法や DNS の要件がシナリオによって異なります。TXT レコードを使わず、ポータル上の設定だけで完結するケースも多いため、必ず対象機能のドキュメントを確認してください。
Microsoft 365（Exchange Online など）のドメイン検証
Microsoft 365 でカスタムドメインを追加する場合も TXT レコードによるドメイン所有確認を行いますが、これは メールルーティングやライセンス割り当てなど、別の目的の検証です。DirectFedAuthUrl の TXT レコードとは用途が異なります。
他社クラウドサービスとの SSO（サービスプロバイダー側）
たとえば、他社サービスが Entra ID を IdP として利用する場合（SP 側の設定）は、そのサービスの仕様により DNS レコードの要否が変わります。今回のテーマである 「外部 IdP を Entra ID 側に登録する」シナリオとは逆向きになるので、混同しないようにしましょう。
よくある疑問とベストプラクティス
Q1. TXT レコードを削除したあと、しばらくしてサインインエラーが出ることはある？
TXT レコード削除とサインインエラーが直接結びつくことは基本的にありません。もしエラーが出た場合は、
- IdP 側で証明書やエンドポイント URL が変更されていないか
- Entra ID の外部 IdP 設定（メタデータ・証明書の期限など）が最新か
- ユーザーのメールアドレスや UPN が想定どおりのドメインになっているか
といった別の要因を疑うべきです。TXT レコードは検証時にしか参照されません。
Q2. TXT レコードの TTL 値はどのくらいにしておくべき？
検証目的であれば、3600 秒（1 時間）程度の TTL が扱いやすいです。長すぎる TTL を設定すると、誤った値を入れてしまったときに修正が反映されるまで時間がかかってしまいます。一方、運用時には TXT レコードはあってもなくてもサインインに影響しないため、TTL の最適値を追求する必要性は高くありません。
Q3. TXT レコードを複数設定しても大丈夫？
DNS の仕様上、同一ドメイン名に複数の TXT レコードを設定することは可能です。ただし、
- SPF 設定など、他用途の TXT と混在する
- DirectFedAuthUrl が複数存在するように見える
といった状況になると、人間が構成を理解しにくくなるため、できるだけ整理しておくことをおすすめします。DirectFedAuthUrl は基本的に「ドメインごとに 1 つ」を前提とした運用が分かりやすいでしょう。
Q4. TXT レコードを誤って別の URL に変えてしまったら？
一度フェデレーションの追加と検証が完了していれば、TXT レコードの値を変えても既存のサインインは影響を受けません。ただし、将来新しい IdP を追加したり、既存 IdP の構成を作り直すときに誤解を招く恐れがあります。誤って変更してしまった場合は、正しい値に戻すか、いっそ削除しておく方が安全です。
まとめ：TXT レコードは「追加時の検証用」、本番運用はテナント内のマッピングで動く
ここまでの内容を整理すると、ポイントは次のとおりです。
| ポイント | 内容 |
|---|---|
| TXT レコードの主な役割 | メールドメインと IdP エンドポイントの関連付けを、フェデレーション追加時に検証するための手段 |
| サインイン時に参照される情報 | Entra ID テナント内に保存された「関連付けられたドメイン」情報（TXT レコードではない） |
| 削除してよい条件 | 外部 IdP の設定にドメインが関連付けられていることと、テストサインインが問題なく行えること |
| 削除の影響 | 既存のサインイン動作には影響しない（TXT レコードは検証専用） |
| 残すべきケース | 将来の再設定や別組織・別管理者による構成変更が見込まれる場合 |
迷ったときは、次の 2 点を確認してください。
- Entra ID 上で、対象ドメインが IdP に関連付けられていること
- 対象ドメインのユーザーでテストサインインが成功すること
これらを満たしていれば、DirectFedAuthUrl の TXT レコードは削除してもサインインは止まりません。あとは、再設定のしやすさや情報公開ポリシーを踏まえ、組織のガバナンスに沿った方針で「残すか削除か」を決めていくのがよいでしょう。
コメント