ドメインを購入するとき、空いているか、提示された価格はいくらかだけで判断すると危険です。中古ドメインには、過去のウェブサイト、メール送信、広告用リダイレクト、停止処分、第三者のブランド利用など、現在の所有者からは見えにくい履歴が残っていることがあります。新しいサービスの公式サイト、採用ページ、EC、会員向けログイン、法人メールに使うなら、購入前の調査は小さな確認ではなく取引の一部です。日本の企業では、.jpや日本語ドメインを使う場合に登録条件や表記の違いも確認する必要があります。最終的な結論を一つのスコアにまとめず、何が確認でき、何が不明なのかを残すことが安全な判断につながります。
最初に購入対象を正規化する
売り手から受け取った文字列をそのまま契約書に貼り付ける前に、ドメイン名、ゾーン、Unicode表記、Punycode表記を分けて記録します。日本語ドメインでは、画面に表示される文字列と技術的に使われるASCII表現が異なるため、似た文字を取り違えないようにします。ハイフンの有無、全角文字、末尾のドット、wwwの有無も整理してください。購入するのが登録権なのか、レジストラのアカウント移管なのか、ウェブサイトやメール設定を含む事業譲渡なのかも明確にします。対象が違えば必要な証拠も違います。正規化した入力を一つの識別子として保管すると、RDAP、DNS、証明書、サイトの調査結果を同じ対象に結び付けられます。
RDAPとWHOISで登録状態を確認する
RDAPまたはWHOISでは、登録状態、レジストラ、作成日、更新日、失効日、ネームサーバー、公開されているイベントなどを確認できます。ただし、連絡先が非公開だからといって問題があるとは限りません。個人情報保護やレジストリの方針によって公開項目は変わります。作成日が売り手の説明と一致するか、移管や停止を示すステータスがないか、失効日が取引条件と整合するかを確認してください。情報が返らない場合は「問題なし」ではなく「確認できない」と記録します。ICANNのgTLDと、.jpなどのccTLDではポリシーが異なるため、同じ解釈を機械的に適用しないことも重要です。
- 正規化したドメイン名と確認時刻
- 作成日、更新日、失効日
- レジストラと公開されているステータス
- ネームサーバーと登録イベント
- 非公開だった項目と取得できなかった項目
- 売り手の説明と一致しない点
DNS、メール、サイトの現在地を読む
DNSは過去の利用を完全に証明するものではありませんが、現在の役割を理解する有力な手掛かりになります。AやAAAAはウェブサービスの宛先、MXはメール受信先、TXTはSPFや検証トークン、NSはゾーンの委任先を示します。購入予定のサイトが停止中でも、MXだけが稼働している場合があります。逆に、古いメールサービスのMXや外部サービス用のTXTが残っていれば、移管後に誤配信やアカウント復旧の問題が起きる可能性があります。DNSの空応答、NXDOMAIN、SERVFAIL、タイムアウトは別々の状態として扱い、1回の検索で不存在と断定しないでください。ドメインの用途に必要なレコードと、旧所有者の設定として削除すべきレコードを一覧にします。
HTTPとTLSも別に確認します。トップページが表示されるかだけでなく、httpとhttps、wwwとwwwなし、主要な古いパス、ログインや問い合わせページのリダイレクトを見ます。証明書のSANに購入対象が含まれるか、期限が近くないか、チェーンが正しく返るかも記録します。証明書が存在しても、ブランドの所有権やサイトの安全性が保証されるわけではありません。共用IPや共通の証明書も、同じ運営者の証拠とは限りません。観察した事実と推測を分け、購入判断に必要な追加質問を売り手に返してください。
過去の評判とブランド権利を確認する
過去のドメインがどのようなコンテンツやメール送信に使われたかは、現在の所有者が変わっても利用者や各種サービスの判断に影響することがあります。公開されている評判シグナル、過去のサイト、リダイレクト先、サブドメインの状態を確認し、日付を保存します。1件の不一致だけで不正と断定せず、複数の独立した証拠が同じ方向を示すかを見ます。さらに、ドメイン名が日本国内や進出予定国の商標、会社名、商品名と衝突しないかを確認します。登録されていないことは商標上の安全を意味しません。権利関係に疑問がある場合は、購入後に解決しようとせず、契約前に専門家へ相談してください。
移管直後に必ずやること
購入が成立したら、旧所有者の設定をそのまま信頼しないでください。レジストラのパスワード、復旧用メール、二要素認証、ネームサーバー、DNS管理権限、メールアカウント、証明書、外部サービスの検証トークンを順番に見直します。不要なTXT、古いDKIMセレクタ、未知の管理者、古い転送先は整理します。メールを引き継ぐ場合は、移管前後の受信経路を合意し、誤配信を防ぐ時間帯を設けます。ウェブサイトを新しくする場合でも、古いURLからのリダイレクトがどこへ行くかを確認します。移管日のスナップショットと、移管後の再チェック結果を同じ案件に保存すると、後から原因を追跡できます。
{
"domain": "example.jp",
"checked_at": "2026-08-31T09:00:00Z",
"registration": "confirmed",
"dns": "reviewed",
"reputation": "unknown",
"brand_review": "manual_required",
"decision": "hold"
}自社で複数の候補を比較する場合は、手作業のメモではなく同じ項目を持つプロファイルにします。DomScanのドメインチェッカー、WHOIS履歴、DNS、評判チェックを順に使えば、候補を同じ基準で比較できます。候補が多い場合はDomain Profile APIで正規化した結果を取得し、確認時刻、ステータス、証拠、未知の理由を保存します。自動処理では、登録情報が取得できないこと、DNSが一時的に失敗すること、サイトが403を返すことを区別してください。購入可否を自動で断定するのではなく、明らかな不一致を除外し、残った候補を人が契約条件と権利の観点から確認する流れが現実的です。
調査の合格条件は「すべて緑」ではありません。登録状態と取引条件が一致し、DNSとサイトの役割を説明でき、評判やブランド上の懸念に対応する計画があり、移管後に旧設定をリセットできることが重要です。反対に、所有権の説明が曖昧、正確な対象名が一致しない、複数の独立した不正利用シグナルがある、または移管権限を確認できない場合は、価格が安くても保留します。購入日だけでなく、移管完了後にも同じ項目を再確認してください。ドメインは名前だけでなく、メール、サイト、ブランド、顧客の信頼を結び付ける事業資産だからです。