テナントごとに tenant1.example.com のようなサブドメインを発行するサービスでは、DNSにワイルドカードレコード *.example.com を1件追加し、すべてのサブドメインを同じサーバーへ向けるのが基本の手順です。こうしておけば、テナントを追加するたびにDNSを触る必要がなくなります。この記事では、権威DNSの確認からレコード追加、反映の確認、Webサーバー側の受け入れまでを順番に説明します。テナントの独自ドメイン接続やレコード作成の自動化は、別記事「マルチテナント用サブドメインをDNS設定する方法」で扱っています。
手順0：ホスト名の形を決めておく
作業の前に、テナントのホスト名をどの形にするかを決めます。
tenant1.example.com（サービス本体と同じドメイン）tenant1.app.example.com（テナント用の階層を1段挟む）tenant1.example-app.com（テナント専用に別ドメインを取る）
本体サイトやメールと同じドメインに直接テナントを並べると、www や mail などの予約名とテナント名がぶつかる可能性があります。またブラウザのCookieは設定次第でサブドメイン間に共有されるため、テナント同士の分離を重視するなら専用ドメインや専用の階層を用意する考え方もあります。後から変えるのは大変なので、ここで決めておきます。以下では *.app.example.com を例にします。
手順1：権威DNSサーバーを確認する
レコードを追加する場所は、レジストラではなく「そのドメインの権威DNSサーバー」です。レジストラとDNSサービスが別の会社になっていることは珍しくないため、まず確認します。
dig NS example.com +short表示されたネームサーバー（例: Cloudflare や Route 53 のもの）を管理している画面でレコードを追加します。ここを取り違えると、いくら設定しても反映されません。
手順2：TTLを短くしておく（既存レコードを変える場合）
既に app.example.com などのレコードがあり、向き先を変える場合は、作業の前日までにTTLを300秒程度に下げておきます。キャッシュされた古い値が残る時間を短くでき、問題が起きたときの切り戻しも早くなります。新規に追加するだけなら、この手順は省略できます。
手順3：基点とワイルドカードのレコードを追加する
サーバーのIPアドレスが決まっている場合は、Aレコード（IPv6も使うならAAAAレコード）を追加します。
; ゾーンファイル形式の例（管理画面では「名前」「タイプ」「値」に分けて入力）
app.example.com. 300 IN A 203.0.113.10
*.app.example.com. 300 IN A 203.0.113.10ロードバランサーなどホスト名で指定する先がある場合は、CNAMEで向けます。
*.app.example.com. 300 IN CNAME lb.example.net.管理画面での入力では、名前欄にゾーン名を除いた *.app だけを入れる画面と、完全なホスト名を求める画面があります。入力後の一覧表示で、意図したホスト名になっているかを確認してください。
ワイルドカードの動作で知っておくこと
ワイルドカードレコードは「該当する名前のレコードが存在しないとき」にだけ使われます。この性質から、次のような挙動になります。
admin.app.example.comを個別に登録すると、その名前は個別レコードが優先されます。管理画面だけ別サーバーに向けたい場合に使えます。- 個別登録した名前については、ワイルドカードの値は使われません。たとえば
adminにTXTレコードだけを登録すると、adminのAレコードは返らなくなります。 - ゾーンの頂点（
example.comそのもの）にはCNAMEを置けません。基点をドメインの頂点にする構成では、Aレコードか、DNS事業者独自のALIAS系機能を使います。
手順4：反映を確認する
まず権威DNSサーバーに直接問い合わせ、設定が正しいかを確認します。キャッシュの影響を受けないため、設定ミスと反映待ちを切り分けられます。
# 権威サーバーに直接問い合わせる（ns1.example-dns.com は手順1で確認した名前に置き換え）
dig @ns1.example-dns.com tenant-test.app.example.com A +short
# 存在しない適当な名前でもワイルドカードで応答するか
dig @ns1.example-dns.com random-12345.app.example.com A +short
# 一般のリゾルバー経由の結果
dig tenant-test.app.example.com A +short権威サーバーで正しい値が返り、一般のリゾルバーで古い値が返るなら反映待ちです。以前のTTLが切れるまで待ちます。権威サーバーでも値が返らない場合は、入力した名前の誤りか、別のDNSサービスに登録してしまっている可能性が高いと考えられます。
手順5：Webサーバーとアプリ側で受け入れる
DNSが通っても、Webサーバーがそのホスト名を受け付けなければ、既定のサイトやエラーページが表示されます。
nginx なら server_name *.app.example.com; のように指定し、Apache なら ServerAlias *.app.example.com を設定します。アプリ側は Host ヘッダーでテナントを判別し、未登録のテナント名なら404などを返すようにしておきます。存在しないテナント名でも本体サイトがそのまま表示される状態は、検索エンジンに重複したページとして扱われる原因にもなります。
WordPressマルチサイトをサブドメイン型で動かす場合は、ネットワークのドメインに合わせたワイルドカードレコードを用意し、wp-config.php で SUBDOMAIN_INSTALL を true にします。新しいサイトを追加したら、そのサブドメインでログイン画面が開けるかを確認してください。
HTTPS化にはワイルドカード証明書（*.app.example.com）が必要です。取得方法は「マルチテナント用サブドメインをSSL化する方法」の記事で詳しく説明しています。
よくあるつまずき
- ワイルドカードを追加したのに一部のテナントだけ表示されない: そのテナント名で過去に個別レコードを作っていないかを確認します。個別レコードが残っていると、ワイルドカードより優先されます。
- DNSは正しいのに表示されない: ブラウザやOSのDNSキャッシュ、社内DNSの古いキャッシュが残っている場合があります。
digの結果とブラウザの挙動が食い違うときは、キャッシュを疑います。 - Cloudflare などのプロキシ機能: プロキシを有効にするとDNSの応答がCDN側のIPになり、証明書の扱いも変わります。ワイルドカードのプロキシ対応や証明書の範囲は事業者やプランによって異なるため、利用中のサービスのドキュメントで確認してください（2026年10月現在）。
- テナントの削除後にも名前が解決される: ワイルドカードはどの名前にも応答するため、DNS上は削除と無関係です。アプリ側で「存在しないテナント」として扱う処理が必要です。
まとめ
- 権威DNSサーバーを確認してから、基点のレコードとワイルドカードレコード（
*.app.example.com）を追加します。 - ワイルドカードは個別レコードが無い名前にだけ効きます。個別登録は例外の扱いに使い、残骸を放置しないようにします。
- 反映確認は権威サーバーへの直接問い合わせから行い、設定ミスと反映待ちを切り分けます。
- DNSのほかに、Webサーバーの
server_name/ServerAlias、アプリの未登録テナント処理、ワイルドカード証明書が揃って初めて利用できる状態になります。変更前には現在のゾーン設定を控えておきます。