.tech はだれでも登録できる新 gTLD で、スタートアップのサービスサイト、技術ブログ、開発者向けドキュメントなどによく使われます。取得自体は数分で終わりますが、技術系のサイトは api・docs・status のようにサブドメインが増えやすく、外部サービスとの連携も多いため、取得後の DNS と証明書の管理が甘いとサブドメインの乗っ取りや証明書の誤発行といった問題につながります。この記事では、.tech を取得する前、取得直後、公開前、運用中の順に、確認しておきたい項目をチェックリストとして整理します。
.tech ドメインの前提
.tech は 2015年ごろに一般登録が始まった新 gTLD で、レジストリは Radix 系の事業者と案内されています。登録者の資格制限はなく、個人でも法人でも取得できます（2026年10月現在）。条件は登録時にレジストリとレジストラの規約で確認してください。
.dev や .app と違い、.tech は TLD 全体が HSTS プリロードされているわけではありません。HTTP でも接続できてしまうため、HTTPS への統一や HSTS の設定は自分で行う必要があります。また、Google は新 gTLD を他の gTLD と同じように扱うと説明しており、.tech だから技術系の検索で有利になるということはありません。
取得前のチェック
名前
- サービス名・プロダクト名と同じ綴りか。GitHub の Organization 名、npm のパッケージ名、SNS のアカウント名と表記をそろえられるか
- 他社のプロダクト名や技術名（言語やフレームワークの名前など）を含んでいないか。J-PlatPat などで商標を確認したか
- 「〇〇tech.tech」のように TLD と重複した読みにくい名前になっていないか
技術名を含む名前は、その技術を管理する団体の商標方針に触れることがあります。名前に入れたい場合は、各団体の商標ガイドラインを先に読んでおきます。
費用
- 初年度価格だけでなく、2年目以降の更新費用を確認したか
- 短い名前や一般的な単語がプレミアムドメインになっていないか。プレミアムは更新も高い価格帯のままのことが多い
- サービスを続ける予定の年数で費用を見積もったか
レジストラと DNS
- DNS の操作を API で自動化できるか（証明書の DNS-01 チャレンジやインフラのコード管理に使う）
- Terraform などの構成管理ツールから扱える DNS サービスか、またはネームサーバーを外部の DNS サービスに向けられるか
- CAA・TXT・SRV など、必要なレコード種別をすべて設定できるか
- アカウントに二要素認証を設定でき、複数人で管理する場合に権限を分けられるか
レジストラ（ドメインの契約先）と DNS サービス（レコードの管理先）は別の会社にできます。技術系のサービスでは、契約はレジストラ、DNS は API が使いやすい DNS サービス、と分けて運用する構成もよく使われます。
取得直後のチェック
- 登録者メールアドレスに届く確認メールを開き、認証を済ませたか。放置すると一定期間後に一時停止される場合がある
- 自動更新を有効にし、支払い方法の有効期限を確認したか
- レジストラロック（移管ロック）が有効になっているか
- 登録情報（WHOIS）の公開代行やプライバシー保護の状態を確認したか
- 更新通知の宛先を、個人ではなくチームで受け取れるアドレスにしたか
登録状態は RDAP で確認できます。
# 登録状態（status）と有効期限（events の expiration）を確認する
curl -sL https://rdap.org/domain/example.tech | python3 -m json.tool
# ネームサーバーが意図したものになっているか
dig +short NS example.tech公開前のチェック
HTTPS と HSTS
- 本体とすべてのサブドメインに証明書を用意し、
https://で応答するか http://からのアクセスをhttps://に 301 でリダイレクトしているか- HSTS を使う場合、最初は短い
max-ageで試し、問題がないのを確かめてから延ばしているか
HSTS に includeSubDomains を付けると、HTTP でしか動かないサブドメインが開けなくなります。プリロードリストへの登録はさらに取り消しに時間がかかるため、すべてのサブドメインが HTTPS に対応していると確認できてから検討してください。
CAA レコードで証明書の発行元を絞る
CAA レコードを設定すると、そのドメインの証明書を発行してよい認証局を指定できます。使っている認証局以外からの誤発行を防ぐ手段になります。
example.tech. 3600 IN CAA 0 issue "letsencrypt.org"
example.tech. 3600 IN CAA 0 issuewild "letsencrypt.org"
example.tech. 3600 IN CAA 0 iodef "mailto:security@example.tech"CDN やホスティングサービスが自動で証明書を発行している場合、そのサービスが使う認証局も CAA に含めないと証明書の更新に失敗します。設定前に、各サービスのドキュメントで使っている認証局を確認してください。
# 設定した CAA レコードを確認する
dig +short CAA example.techサブドメインの台帳を作る
技術系サイトでは、外部サービスにサブドメインを向ける CNAME が増えます。
docs.example.tech. 3600 IN CNAME your-docs-host.example.net.
status.example.tech. 3600 IN CNAME your-status-host.example.net.外部サービスの契約を解約したのに CNAME だけが残っていると、第三者が同じ名前でそのサービスに登録し、サブドメインを乗っ取れてしまう場合があります（サブドメインテイクオーバー）。どのサブドメインを、どのサービスに、だれが向けたかを台帳に残し、解約時には DNS レコードも削除する運用にしておきます。
メール
- 問い合わせや通知にメールを使うなら、SPF・DKIM・DMARC を設定したか
- メールを送らないドメインやサブドメインには、SPF で送信元なし（
v=spf1 -all）を宣言したか - DMARC は
p=noneでレポートを集め、正規の送信元が認証に通っているのを確かめてから強めているか
迷惑メール対策の統計では一部の新 gTLD が悪用の多い TLD として挙がることがあり、受信側の判定が厳しめになる場合もあります。
WordPress で使う場合
- WordPress の「設定」→「一般」で、WordPress アドレスとサイトアドレスが
https://の .tech ドメインになっているか - ドキュメントサイトを別のサブドメインで分ける場合、マルチサイトにするか別インストールにするかを決めたか
- 本番に反映する前に、ステージング環境で URL やリダイレクトを確認したか
運用中のチェック
- ドメインの有効期限と自動更新の状態を、定期的に確認しているか
- 証明書の有効期限を外部の監視で見ているか
- サブドメインの台帳と実際の DNS レコードに差がないか（使っていない CNAME が残っていないか）
- DMARC レポートで、自社以外から自社ドメインを名乗るメールが送られていないか
- 管理画面にアクセスできるメンバーを、退職や異動のたびに見直しているか
まとめ
- .tech はだれでも登録でき、HSTS は TLD で強制されないため、HTTPS への統一は自分で行う
- 取得前はプロダクト名との表記統一、技術名の商標、更新費用、DNS の API 対応を確認する
- 取得直後に確認メールの認証、自動更新、ロック、チームで受け取れる通知先を整える
- 公開前に CAA で証明書の発行元を絞り、サブドメインの台帳でテイクオーバーを防ぐ
- 運用中は期限・証明書・DNS レコード・管理者の権限を定期的に見直す