短縮リンクの独自ドメイン:接続と設定の完全ガイド
- domains
- link-shortener
- marketing
このページの内容
- 短縮リンクに載るドメインが重要な理由
- 認知はクリックより先に起きる
- 共有ドメインは他人の評判を背負う
- 移行を可能にするのは所有権
- ドメインを選ぶ
- 短さこそが要点のすべて
- TLDの選択には実務上の結果がついてくる
- いくつドメインを持てるかは、実際に効いてくる制約
- 実際に作成することになるDNSレコード
- サブドメインにはCNAME
- ApexドメインにはAレコード
- ドメインが自分のものだと証明するTXTレコード
- 更新に追われない自動TLS
- 証明書はどのように発行されるのか
- チャレンジを一度だけ委任する
- 健全な設定の流れとはどんなものか
- 公開中のリンクを壊すDNSのミス
- レコードのプロキシと、Flexibleモードのループ
- 残ったレコードと衝突するレコード
- 発行元を締め出すCAAレコード
- 変更の直前に設定された長いTTL
- レジストラーのパーキングと転送
- 印刷する前に経路を検証する
- 最初から最後までの設定の手順
短縮リンクは、そのクリックがどこへ着地するのかについての約束であり、ドメインはその約束のうち、人が判断を下す前に読める唯一の部分です。bit.ly/3xKqR2p のような文字列は、誰が声をかけているのかを何も語りません。go.yourbrand.com/spring-sale なら、誰が、そして何のためかを両方とも伝えます。この差があるからこそ、リンクを真剣に扱うチームはたいてい最後には共有ドメインを離れますし、その移行がしばしば半分のところで止まるのも同じ理由です。これはマーケティングの服を着たDNSのプロジェクトであり、その壊れ方は、それを求めた人たちにとって馴染みのないものだからです。
このガイドは道筋の全体を扱います。ドメインの選び方、サブドメインとApexドメインのそれぞれで作る正確なレコード、所有権の検証と証明書の発行が実際にはどう動いているのか、壊れた設定の大半を生んでいる少数のDNSのミス、そして回収のきかない包装に印刷してしまう前に、完成したリダイレクトの経路をどう検証するかです。
短縮リンクに載るドメインが重要な理由
認知はクリックより先に起きる
どのリンクも、1秒ほどで下される小さな信頼の判断です。共有の短縮ドメインでは、読み手の手元に情報はまったくありません。そのホスト名は数百万人が使うサービスのものであり、そのうちの何人かは、その週にフィッシングのキャンペーンを回しています。ブランドのホスト名は、その推測を事実に置き換えます。
ベンダー各社はブランド化されたリンクのクリック率の向上を数字で公表していますが、比較の条件が揃っていることはまれなので、方向性の参考として受け取ってください。長く変わらないのは背後の仕組みのほうです。URLが目に入るのにクリックできないチャネル——印刷物、QRコードに添えた説明文、プレビューが剥がれたSMS——では、読み手が頼れるものはほとんどホスト名だけです。
共有ドメインは他人の評判を背負う
こちらのほうが鋭い論点です。共有ドメインでは、あなたのリンクは自分では制御できない評判を引き継ぎます。メールのフィルター、企業のプロキシ、メッセンジャーのリンクスキャナー、ブラウザーの安全対策プログラムは、いずれもホスト名の粒度で判断を下します。だから同じドメイン上の無関係なアカウントが起こしたスパムの波が、あなたのキャンペーンには警告の中間ページや無言のブロックとして降りかかります。
自分で所有するドメインは、この関係を逆転させます。評判はあなたのものであり、あなた自身のトラフィックが積み上げたものなので、見知らぬ他人に傷つけられることはありません。裏返しの義務も同じ形をしています。そのドメインの下で公開されるすべてについて、結果を引き受けるのはこれからはあなたです。リンクを他人に再販するなら、不正利用の管理とユーザーごとのリンクの可視性を頭に置いておくべき理由が、まさにここにあります。
移行を可能にするのは所有権
自分が握っているドメインは恒久的な住所です。プラットフォームを変えてもレコードを1つ向け直すだけで、前の四半期の包装に載ったコードは解決され続けます。ベンダーの共有ドメインで公開すれば、印刷したものすべてがそのベンダーの価格設定の人質になります。ホワイトラベルのモデルを後押ししているのも、まったく同じ理屈です。
ドメインを選ぶ
短さこそが要点のすべて
短縮リンクは短くあるために存在します。ホスト名の1文字は、スラッグに使えなくなる1文字であり、しかもホスト名の文字こそ、人が声に出して読み、ポスターから打ち込み、SMSに押し込むものです。実用的な目標は、リンク全体の長さが印刷の1行に無理なく収まることです。目安としては、ホスト名が10〜15文字、そこに5〜12文字のスラッグが加わる形になります。
| 形態 | 例 | 向いている用途 | トレードオフ |
| --- | --- | --- | --- |
| メインドメインのサブドメイン | go.yourbrand.com | 素早い立ち上げ、自社チャネル、メール | 3つの中で最も長い |
| 短いTLD上のブランド略称 | yrbrnd.co | SMS、印刷、包装 | 新しく登録が必要で、分かりにくい |
| テーマ性のあるTLD上のフルブランド名 | yourbrand.link | キャンペーンの拠点、QRコード | Apexの設定が必要、TLDの評判はまちまち |
TLDの選択には実務上の結果がついてくる
すべてのトップレベルドメインがフィルターに同じように扱われるわけではありません。安価でプロモーション目的のTLDはスパムの密度が高く、企業のメールゲートウェイのなかにはそれを乱暴に処理するものもあります。単語の語尾として使われる国別コードのTLD——.co、.io、.to、.ly を生んだ一族です——は、それぞれ独自の方針と更新費用を持つレジストリーの管轄下にあります。登録する前に、初年度の価格ではなく更新の価格、登録者に対する制限の有無、そして公開するチャネルがその接尾辞をそもそも自動でリンクにするのかどうかを確認してください。
いくつドメインを持てるかは、実際に効いてくる制約
ドメインの割り当てはベンダー間で大きく異なり、扱うブランドやクライアントが1つを超えた途端に噛みついてきます。2026年8月時点で、Short.ioは無料の階層でも独自ドメインを5つ含みます。Rebrandlyは有料の各階層で1つ、2つ、3つ、10個です。BL.INKは1ユーザーと1ドメインで、月48 USDから始まります。LinkProfitはStarterが月49 USDでリダイレクト用ドメインを3つ、Scaleでは30含みます。クライアントのリンクを管理しているなら、今月ではなく1年後に必要になるドメインの数を数えてください。
証明書の対応範囲も、同じ流れで確認しておく価値があります。2026年8月時点で、Cutt.lyがLet's Encryptの証明書を自動で発行するのは月25 USDのSingleプランからであり、それより下の階層では独自ドメインをHTTPSで完全には使えないということです。機能の完全な比較は、当社の独自ドメインのページにあります。
実際に作成することになるDNSレコード
ほとんどすべての構成は、3つのレコードで足ります。トラフィックを流すもの、所有権を証明するもの、そして証明書の検証を委任するものです。どのルーティング用のレコードを使うかは、サブドメインとApexのどちらを選んだかで決まります。
サブドメインにはCNAME
これが一般的な経路であり、選ぶべき経路でもあります。サブドメインはプラットフォームが所有するホスト名を指し、そのホスト名にはプラットフォームのエッジネットワークが応答します。
Type Name Value TTL Proxy
CNAME go cname.linkprofit.com 300 DNS only
2つの細部が人をつまずかせます。多くのDNSの管理画面はゾーンからの相対名を求めるので go.yourbrand.com ではなく go ですが、完全修飾の形式を求めるものも少数あり、間違ったほうを入力すると黙って go.yourbrand.com.yourbrand.com が作られます。もう1つ、DNSをCloudflareでホストしているなら、このレコードはプロキシを通さないままにしなければなりません。管理画面がDNS onlyと呼んでいる状態です。理由は下のミスの節にあります。ベンダーごとに宛先は違いますが、形は変わりません。2026年8月時点でShort.ioは cname.short.io を、Rebrandlyは registrar.dedicated.domains を使います。主要なレジストラー向けの手順ごとのスクリーンショットは、CNAME設定のドキュメントにあります。
ApexドメインにはAレコード
DNSはゾーンのApexでのCNAMEを禁じています。ApexはSOAとNSのレコードも併せて持たなければならず、CNAMEは同じ名前の他のレコードと共存できないからです。したがって yourbrand.link そのものをCNAMEにすることはできません。出口は2つあります。
1つ目はプロバイダー側のフラット化で、ALIAS、ANAME、CNAMEフラット化といった名前で提供されています。DNSプロバイダーが宛先を解決し、そのアドレスで応答する仕組みです。Cloudflare、DNSimple、Namecheap、Porkbun、DNS Made Easy、easyDNS、NS1、Bunny、Azure DNS、Google Cloud DNSが対応しています。Route 53、GoDaddy、IONOS、Network Solutionsは、自社のエコシステム外の宛先には提供していません。
2つ目は、プラットフォームがあなたに発行する受信IPアドレスを指すAレコードです。下に挙げるアドレスはドキュメント用に予約された範囲の例示値なので、実際にはご自身の管理画面に表示される値を使ってください。
Type Name Value TTL
A @ 203.0.113.10 300
AAAA @ 2001:db8::10 300
CNAME www cname.linkprofit.com 300
www のリンクを公開するつもりがなくても、www のレコードは追加してください。人は習慣で打ち込みますし、応答のない www が返すのはリダイレクトではなく接続エラーです。Apexにまつわる細かな点は、どのプロバイダーがApexのレコードにどのラベルを表示するのかも含めて、Apexドメインのドキュメントで扱っています。これらのアドレスは各ベンダーが公開しており、2026年8月時点でShort.ioは 207.174.61.1 を、Rebrandlyは 52.72.49.79 を記載しています。この経路が特殊なものではなく標準的なやり方だと確かめる、ちょうどよい傍証です。
ドメインが自分のものだと証明するTXTレコード
所有権の証明がなければ、共有プラットフォーム上で誰でも go.yourbrand.com を主張でき、あなたがCNAMEを作った瞬間から、あなた宛てのトラフィックを受け取れてしまいます。そこでプラットフォームはトークンを発行し、配信を始める前にそれを確認します。
Type Name Value
TXT _linkprofit-verify dom_2f7a91c4be0d3856
このトークンは、あなたのドメインのレコードに固有のものです。ホスト名が有効になったあとは、このレコードをそのまま残しておいて構いません。削除しても稼働中のドメインが壊れることはありませんが、残しておけば再検証のときに驚かずに済みます。
更新に追われない自動TLS
証明書はどのように発行されるのか
あなたのプラットフォームは、自分では所有していないホスト名に対して有効な証明書を必要とします。ACME、つまりLet's Encryptの裏側にあるプロトコルが自動化するために作られたのは、まさにこれです。プラットフォームが go.yourbrand.com の証明書を要求し、認証局がチャレンジを出し、プラットフォームはそれに応答することで管理権を証明します。チャレンジを通過すれば、ドメイン検証型の証明書は数秒で発行され、費用もかかりません。
重要な性質は有効期間です。現代の証明書は設計上そもそも短命なので、発行は一度で終わる設定の手順ではありません。ドメインが接続されているかぎり回り続ける更新のループであり、システム内のすべてのドメインにわたって走り続けます。
チャレンジを一度だけ委任する
そのループを目に見えないものにする確実なやり方は、検証を委任することです。チャレンジ用の名前にCNAMEを1つ作り、プラットフォームが管理する委任先を指しておけば、以後の更新はすべてプラットフォームが応答し、あなたは何もしなくて済みます。
Type Name Value
CNAME _acme-challenge.go the delegation target shown in your dashboard
もう一方のやり方、つまり更新の周期ごとに新しいTXTの値を貼り付ける運用は、そのカレンダーの通知を持っている人が転職するまでは、きっちり機能します。ベンダーの設定の流れが定期的な手作業の検証を要求するなら、それは面倒ごとではなく、既知の将来の障害として扱ってください。
健全な設定の流れとはどんなものか
目に見える状態が3つと、その間の自動的な遷移を期待してください。レコードがまだ観測できないあいだはDNS待ち、観測できたら証明書待ち、トラフィックを配信できるようになれば有効です。再確認はボタンを押したときだけでなく、1分ほどの間隔で自動的に走るべきですし、画面は漠然とした失敗ではなく、どのレコードが足りないのかを具体的に伝えるべきです。きれいなゾーンでTTLが低ければ、端から端まで数分というのが典型的な所要時間です。
公開中のリンクを壊すDNSのミス
レコードのプロキシと、Flexibleモードのループ
Cloudflareでホストされたゾーンで、最もよくある失敗です。オレンジの雲を点灯させると、そのホスト名のTLSをすでに終端しているプラットフォームの前に、TLSの終端点がもう1つ置かれます。暗号化をFlexibleにしていると、プロキシは平文のHTTPでオリジンに接続し、オリジンはHTTPSへのリダイレクトで応答し、プロキシはそれをブラウザーへ返し、ブラウザーが諦めるまでループが続きます。Rebrandlyは自社の利用者向けにこの衝突を文書化していますが、これは特定のベンダーの性質ではなく、この構成そのものの性質です。特別な理由がないかぎりレコードはプロキシなしのままにし、どうしてもプロキシを通すなら、暗号化をFull strictに設定してください。
残ったレコードと衝突するレコード
かつて別の場所を指していたサブドメインには、たいていAレコードがまだ残っており、1つの名前がCNAMEと他の種類のレコードを同時に持つことはできません。2つ目のレコードを明確なエラーで拒否する管理画面もあれば、受け付けたうえで断続的な名前解決を生む管理画面もあります。何かを追加する前に、その名前に存在するレコードをすべて列挙し、古くなったものを削除してください。ワイルドカードのレコードにも注意が必要です。ゾーンにある * のエントリーは、明示的なレコードがなければ go にも応答するので、存在しないCNAMEが動いているように見えてしまいます。
発行元を締め出すCAAレコード
ゾーンがCAAレコードを公開している場合、それはそのゾーンに対して証明書を発行できる認証局を限定します。1社の商用CAに固定されたゾーンは、Let's Encryptの発行を黙って止めてしまい、その失敗は、証明書がいつまでも現れないという形で表に出ます。プラットフォームが使う発行元を追加するか、該当のホスト名について制限を外してください。
変更の直前に設定された長いTTL
TTLは、古い答えがどれだけの期間有効であり続けるかについて、リゾルバーに与えた約束です。TTLが86400のレコードを変更すれば、一部のリゾルバーは前の値を1日持ち続けます。切り替えを計画しているなら、少なくとも前日までにTTLを300へ下げ、新しい構成を検証できたらまた戻してください。
レジストラーのパーキングと転送
登録したばかりのドメインには、パーキングのページ、URLの転送、レジストラーの既定のレコードが最初から入っていることがよくあります。とくに転送は、プラットフォームの不具合のように見える形で邪魔をします。リクエストがあなたのリダイレクトのエンジンに届く前に、レジストラーが応答してしまうからです。新しいドメインは空だと決めてかからず、明示的に無効化してください。
印刷する前に経路を検証する
名前解決とリダイレクトは別々の問題なので、両方を確認してください。
dig +short go.yourbrand.com CNAME
dig +short go.yourbrand.com A
curl -sSI https://go.yourbrand.com/spring-sale | grep -i -E 'HTTP/|location'
curl の出力には、1つのリダイレクトのステータスと、それに続いて最終的なリンク先を直接指す location ヘッダーが1つだけ現れるはずです。見るべきものは2つあります。1つ目はホップの数です。ホップが1つ増えるたびに往復が1回増え、参照元のデータも薄まるので、リンク先へ届く前に計測用のドメインを経由する経路は、まとめてしまうべきです。2つ目に、リンク先のURLはUTMパラメーターも含めて、設定したとおりでなければなりません。リンク先そのものが http から https へ、あるいはApexから www へリダイレクトすると、意図しないホップが1つ増えるからです。
同じ確認をApexと www の形式について、http と https の両方で実行し、リンク先が端末に応じて振り分けているなら、モバイルのユーザーエージェントでも一度試してください。ターミナルを開かずに手早く確認したいなら、当社のリンクチェッカーが経路の全体を展開し、それぞれのステータスコードを表示します。競合や取引先のリンクを再共有する前に中身を見るにも、これがいちばん速い方法です。最後に、自分のリンクを1つクリックして、そのイベントが分析に現れることを確認してください。名前解決もリダイレクトも通るのに何も記録されないドメインは、たいてい自分が思っているのとは別のオリジンにトラフィックが届いていることを意味します。
最初から最後までの設定の手順
- ドメインを登録するか選び、更新の価格とレジストリーの制限を確認します。
- 置き換える予定のレコードのTTLを、できれば前日までに下げておきます。
- リンクのプラットフォームにドメインを追加し、表示されたレコードをそのまま書き写します。
- ルーティング用のレコードを作成します。サブドメインならCNAME、フラット化のないApexならAとAAAAです。
- 所有権を証明するTXTレコードと、委任用のチャレンジのCNAMEを作成します。
- DNSがCloudflareにあるなら、ルーティング用のレコードがプロキシを通していないことを確認します。
- 同じ名前の古くなったレコードを削除し、それを覆い隠しうるワイルドカードがないか確認します。
- 状態が証明書待ちを経て有効へ移るまで待ち、
digとcurlで検証します。 - Apex、
www、http、httpsを、さらにモバイルのユーザーエージェントを1つ加えてテストします。 - 正式なリンクを1つ作成し、それをクリックし、そのクリックが記録されることを確認します。
- TTLを元に戻し、ドメインの更新を誰が担当するのかを文書に残します。
きれいなゾーンであれば、この大半は15分ほどの作業です。例外は2つあります。1つはフラット化に対応していないプロバイダーでのApexドメインで、これはIPの経路が必要になります。もう1つは何年分ものレコードが積み上がったゾーンで、そこでの仕事は追加ではなく削除です。
ブランドのドメインは、リンクの運用にとって手に入る最も安い信頼性の底上げであり、いったん接続してしまえば、その先のスタックはあなたがすでに握っている基盤の上で動きます。自分のためではなくクライアントのためにドメインを設定しているなら、クライアントごとのドメインこそが、その提案を信頼に足るものにします。プランごとに割り当てがどう変わるかは、独自ドメインをご覧ください。
よく聞かれる質問
yourbrand.link のようなApexドメインを短縮リンクに使えますか?
使えますが、DNSの経路が違います。ゾーンのApexにCNAMEを置くことはできないので、CNAMEのフラット化かALIASレコードを提供するプロバイダーを使うか、プラットフォームが発行する受信IPアドレスへAレコードを向けることになります。Cloudflare、DNSimple、Namecheap、Porkbun、DNS Made Easy、easyDNS、NS1、Bunny、Azure DNS、Google Cloud DNSはフラット化かALIASに対応しています。Route 53、GoDaddy、IONOS、Network Solutionsは自社エコシステム外の宛先には提供していないため、これらのゾーンではIPの経路が必要です。
独自ドメインが動き始めるまで、どれくらいかかりますか?
待ち時間は2つ重なります。1つ目はDNSの伝播で、置き換えたレコードのTTLと各リゾルバーのキャッシュに左右されます。TTLがもともと低ければ数分、そうでなければ最長で1日ほどかかります。2つ目は証明書の発行で、レコードが見えるようになってから始まり、通常は10分以内に完了します。よくできた管理画面は、検証ボタンを何度も押させるのではなく、自動で再確認します。
短縮用ドメインのためにSSL証明書を購入する必要はありますか?
ありません。証明書はリダイレクトを配信するプラットフォームがACMEを通じて自動で発行し、追加費用はかからず、更新も自動で行われます。本当に大事なのは更新の仕組みです。チャレンジ用のレコードにCNAMEを置いて検証を一度だけ委任してしまえば、以後の更新であなたがDNSに触れることは永久にありません。数か月ごとに新しい検証レコードを貼り付けるようベンダーが求めてくるなら、それは設定の手順ではなく、日程の決まった障害です。
メインサイトのサブドメインと、別の短縮用ドメイン、どちらを使うべきですか?
go.yourbrand.com のようなサブドメインは立ち上げが速く、追加の費用もかからず、人々がすでに知っているドメインの認知をそのまま引き継げます。別に取った短縮用ドメインはより短く、これはSMSや印刷物で効いてきますし、リンクの評判をメインサイトから切り離せます。両方を運用するチームも少なくありません。自社チャネルにはサブドメイン、1文字でも惜しいキャンペーンには短縮用ドメインという使い分けです。
Cloudflareのプロキシを有効にしたら、なぜリンクが壊れたのですか?
レコードをプロキシに通すと、そのホスト名のTLSをすでに終端しているプラットフォームの前に、TLSの終端点をもう1つ置くことになります。Flexibleモードではプロキシが平文のHTTPでオリジンに接続し、オリジンはHTTPSへのリダイレクトで応答するので、ブラウザーが諦めるまでリクエストが回り続けます。Rebrandlyも自社の顧客向けにこの衝突を文書化しています。対処は、そのレコードをプロキシなしのままにすることです。どうしてもプロキシを経路に残す理由があるなら、暗号化をFull strictに切り替えてください。
あとでリンクのプラットフォームを乗り換えたら、既存のリンクはどうなりますか?
ドメインはあなたのものなので、行き先の主導権も手元に残ります。CNAMEまたはAレコードを新しいプロバイダーへ向け直し、スラッグとリンク先の対応表を取り込めば、すでに印刷されたコードもそのまま解決され続けます。切り替えで気をつける点は2つあります。スラッグはDNSを動かす前に作り直しておくこと、そして新しいプロバイダーがトラフィックの到着前にそのホスト名の証明書を発行し終えていることです。だからこそ段階的な切り替えでは、前日までにTTLを低く設定しておきます。