2026年10月15日
2026年10月15日
Vanity URL(独自ドメインURL)のDNS設定手順|CNAME・所有確認TXT・証明書発行まで
Vanity URL とは、外部サービスの URL を自社ドメインで表示する仕組みのことで、go.example.com(短縮URL)や help.example.com(ヘルプセンター)、status.example.com(稼働状況ページ)のような形がよく使われます。DNS 側でやることは、ほとんどの場合「サブドメインにサービス指定の CNAME を作る」「所有確認の TXT を追加する」の2つです。この記事では、その手順と、反映されない・証明書が発行されないときの確かめ方、解約時の注意までを説明します。
Vanity URL の仕組み
短縮URLサービスやヘルプデスク、メール配信のクリック計測など、多くの SaaS が「カスタムドメイン」「独自ドメイン」といった名前で Vanity URL の機能を提供しています。サービス側のサーバーは1つでも、アクセスしてきたホスト名を見て、どの契約者のページを返すかを判断しています。
そのため設定は次の3者がそろって初めて動きます。
- DNS:自社のサブドメインがサービスのサーバーを指している
- サービスの管理画面:そのサブドメインを自分のアカウントに登録している
- 証明書:そのサブドメイン名の HTTPS 証明書がサービス側で発行されている
どれか1つが欠けると、DNS は正しいのにエラー画面になる、証明書の警告が出る、といった症状になります。なお「Vanity NS(独自名のネームサーバー)」は、ネームサーバー自体を自社名で見せる別の仕組みで、この記事の対象ではありません。
設定の前に確認すること
サブドメインで使うか、ルートドメインで使うか
基本はサブドメインで使います。DNS の仕様上、ルートドメイン(example.com そのもの)には CNAME を置けないためです。ルートドメインにはゾーンの管理に欠かせない SOA と NS のレコードが置かれており、CNAME は他のレコードと同じ名前に共存できません。
ルートドメインで使いたい場合は、次のどちらかになります。
- サービスが案内する A / AAAA レコード(固定 IP)を登録する
- DNS 事業者の「ALIAS」「ANAME」「CNAME フラットニング」といった、ルートでも CNAME 相当の動きをする独自機能を使う
ただし、ルートドメインを外部サービスに向けると WordPress 本体を置けなくなるため、通常はサブドメインを選びます。
既存のレコードと重ならないか
使いたいサブドメインに、すでに A レコードや別の CNAME が無いかを確認します。同じ名前に CNAME と A は共存できず、DNS 事業者によっては登録自体がエラーになります。
dig +short go.example.com A
dig +short go.example.com CNAME
何も返らなければ未使用です。
DNS の設定手順
1. サービスの管理画面でドメインを登録する
先にサービス側でカスタムドメインとして go.example.com を登録すると、DNS に設定すべき値が表示されるのが一般的です。表示される内容はサービスごとに異なりますが、多くは次の組み合わせです(2026年10月現在)。
- CNAME の向き先(例:
custom.service-provider.example) - 所有確認用の TXT レコード(名前と値)
- 証明書発行用の CNAME(サービスによっては必要)
ここに表示された値をそのまま使います。ほかのサイトに載っている値を流用すると、サービスの構成変更で動かなくなることがあります。
2. CNAME レコードを追加する
DNS 事業者の管理画面で、次のように登録します。
名前(ホスト): go
種類: CNAME
値: custom.service-provider.example.
TTL: 300(最初は短め、安定したら延ばす)
名前の欄に go と入れるか go.example.com と入れるかは、DNS 事業者の画面によって違います。go.example.com.example.com のように二重にならないよう、登録後の一覧で確かめてください。値の末尾のドット(.)は、付けると自動で補われる画面と、付けないと自ドメインが連結される画面があります。
3. 所有確認の TXT レコードを追加する
サービスが指定した名前(_verify.go のような形が多い)と値で TXT を登録します。値の前後に余計な空白や引用符が入ると一致しません。画面によっては引用符を自動で付けるため、コピーした値をそのまま貼り、一覧での表示を見て確かめます。
4. 反映を確認する
# CNAME が向き先を返すか
dig +short go.example.com CNAME
# 権威 DNS サーバーに直接聞く(キャッシュの影響を除く)
dig +short NS example.com
dig +short go.example.com CNAME @ns1.your-dns-provider.example
# 所有確認の TXT
dig +short _verify.go.example.com TXT
権威サーバーで正しく返るのに一般のリゾルバーでは古い値が返る場合は、以前の TTL が切れるのを待つだけです。権威サーバーでも返らない場合は、登録先のゾーンが間違っている(ネームサーバーが別の事業者に向いている)可能性があります。
5. サービス側で確認ボタンを押し、証明書の発行を待つ
DNS が反映されたら、サービスの管理画面で確認を実行します。証明書は数分から数時間で発行されるのが一般的です。
うまくいかないときの切り分け
よくある原因を、起こりやすい順に挙げます。
- 名前の入力ミス:前述の二重登録や、TXT の名前違い。
digで実際の名前を引いて確かめます。 - Cloudflare のプロキシが有効になっている:DNS に Cloudflare を使っていて CNAME のプロキシ(オレンジの雲)が有効だと、サービス側からは Cloudflare の IP しか見えず、所有確認や証明書発行に失敗することがあります。サービスがプロキシ非対応なら「DNS のみ」に切り替えます。
- CAA レコードで認証局を制限している:ドメインに CAA レコードがあり、サービスが使う認証局が許可されていないと証明書を発行できません。
dig example.com CAAで確認し、サービスの案内に従って認証局を追加します。 - 古いレコードが残っている:同じ名前の A や AAAA が残っていると、CNAME が登録できない、またはランダムに古いサーバーへ接続されます。
- サービス側でドメインを登録していない:DNS だけ設定して管理画面の登録を忘れると、「このドメインは設定されていません」のような画面になります。
ブラウザで確認するときは、証明書の発行先(サブジェクト代替名)に自分のサブドメインが含まれているかも見ておきます。
echo | openssl s_client -connect go.example.com:443 -servername go.example.com 2>/dev/null \
| openssl x509 -noout -subject -ext subjectAltName
解約・移行するときの注意
サービスを解約したら、DNS の CNAME も削除してください。CNAME だけが残り、向き先のサービスで同じ名前を第三者が登録できる状態になると、自社のサブドメインで他人のコンテンツが表示される「サブドメインテイクオーバー」の原因になります。DNS のレコード一覧を定期的に見直し、使っていない外部向け CNAME が無いかを確認する運用にしておくと安心です。
移行時は、新サービスの CNAME に切り替える前に TTL を短くし、旧サービスでの転送設定(あれば)を一時的に残すと、切り替え中のアクセス切れを減らせます。
まとめ
- Vanity URL は、外部サービスを自社サブドメインで表示する仕組みです。DNS・サービス側の登録・証明書の3つがそろって動きます。
- ルートドメインには CNAME を置けないため、基本はサブドメインに CNAME を作ります。
- 値はサービスの管理画面に表示されたものを使い、名前の二重登録や TXT の引用符に注意します。
- 反映しないときは、権威サーバーへの
dig、Cloudflare のプロキシ、CAA、残ったレコードの順に確かめます。 - 解約したら CNAME を削除し、サブドメインテイクオーバーを防ぎます。