通るレジストラ abuse 通報の書き方 — 無視されないための 6 つの設計

類似ドメインや偽ログインページを見つけた後、次に立ちはだかるのが レジストラへの abuse 通報 です。ここで多くの企業セキュリティチームが経験するのが、「丁寧に書いて送ったのに、何の返答もないまま 2 週間経った」——という状況です。

実はレジストラの abuse チームは、通報の書き方だけで "読む / 読まない" を判断している節があります。2024 〜 2026 年にかけて GoDaddy、Namecheap、NameSilo の 3 社と onboarding 対話をしてきた経験から言うと、通る通報には明確な共通点があり、逆に無視される通報にも共通点があります。

この記事では、実際に運用中の通報テンプレートをベースに、返答率を大きく左右する 6 つの設計ポイント を整理します。類似ドメインの検知そのものについては前回の類似ドメイン検知の実務ガイドを合わせてお読みください。

前提：レジストラの abuse チームが抱えている構造的な負荷

通報を書く前に、相手側の事情を理解しておくと戦略が立てやすくなります。

大手レジストラの abuse チームは、1 日に数百〜数千件の通報 を捌いています。そのうち多数が：

• 誤分類（DMCA / TM 苦情が abuse 通路に入ってくる）
• 証拠不十分（URL だけ貼られても検証できない）
• 感情的な文面（"あなたの会社のせいで"で始まる攻撃的な通報）
• 競合同士の嫌がらせ（SEO / 口コミ紛争を abuse と称して通報）

これが意味するのは、通報は 最初の 30 秒で "これは本物の phishing 報告だ" と判断されなければ、優先度を下げられる ということです。

設計 1 — 「何の abuse か」を 1 行で明示する

レジストラの abuse policy には必ず分類があります。Namecheap の場合は公開された abuse policy で Phishing / Malware / Spam / CSAM / Copyright / Trademark などに分かれており、通報先のメールアドレスや担当チームが分類ごとに違うケースもあります。

メール件名は次の形式が最強です：

Phishing Abuse Report — freee-login-help.com impersonating freee K.K.

避けるべきパターン：

• ❌ 「お問い合わせ」「ドメインの件で」——無視される
• ❌ 「著作権侵害とフィッシング」——分類混在で担当が保留にする
• ❌ Subject 空欄や全角記号混入——スパム判定される可能性

ポイント：商標紛争は UDRP、著作権は DMCA、credential 奪取目的のページは abuse。絶対に混ぜない。

設計 2 — 証拠を "後で検証可能な形" で添付する

abuse チームは通報内容を必ず再現検証します。再現できなければ suspend しません。通報テンプレートには次の要素が揃っていると検証がスムーズです：

1. live screenshot（ヘッドレスブラウザで取得した画像の URL、公開アクセス可能）
2. 視覚類似度スコア（pHash distance、SSIM）——主観ではなく数値で主張する
3. 動作証拠（login form の action URL、credential フィールドの有無、ブランドキーワードの出現）
4. WHOIS / RDAP メタデータ（creation date、registrar IANA ID、nameservers）
5. 外部脅威インテル（Google Safe Browsing、PhishTank ID など）

逆に やってはいけないのは "URL だけ貼って通報"。担当者がその場でブラウザを開いて確認する手間を強いる通報は、最も後回しにされます。

設計 3 — 分類根拠を明示する（abuse か、TM か、copyright か）

abuse 通報は「これが abuse であり、TM / copyright ではない理由」を明示的に書くと通りやすくなります。テンプレートの該当部分：

This domain hosts a credential-collection page designed to deceive {{victim_brand}}'s customers into entering their account credentials, which is consistent with {{registrar}}'s published abuse policy classification of "Phishing". This report is filed under the abuse category, not under DMCA (no copyrighted content claim) or UDRP (no trademark dispute claim).

これを書くことで、abuse チームが「これは UDRP に回すべきかも」と迷う時間を削除できます。通報 1 件あたりの処理時間を短縮してあげる ことが、返答率を上げる最短経路です。

設計 4 — ブランド保有者との代理関係を明言する

「OpenBait が独自判断で通報している」のではなく、「ブランド保有者 X 社から授権されて代理通報している」ことを明示します：

The legitimate brand owner ({{victim_brand_legal_name}}) has authorized OpenBait to submit takedown requests on their behalf as part of their anti-phishing program.

これは abuse チームが「第三者による悪意ある通報」を排除するための判断材料です。被害ブランドの正式名称（ K.K. / Co., Ltd. まで含む） を書くと効果が上がります。

設計 5 — Reporter identity を固定する

GoDaddy と Namecheap の abuse チームから明示的に言われた要望が、「同じ reporter address から送ってくれ」 でした。理由はシンプルで、abuse チーム内で reporter ごとに信頼プロファイルを管理している からです。

• ✅ 1 つの固定アドレス（例: [email protected]）から継続的に送る → 信頼が積み上がり、3〜6 か月後には優先処理される
• ❌ 社員個人メールからバラバラに送る → 毎回ゼロから検証される

特に GoDaddy は、trusted reporter プログラム を用意しています（公開されていないが対話で確認済み）。一定期間の信頼積み上げがあれば、通常の abuse email チャネルから API 経由の bulk submit に切り替えられる、という建て付けです。

設計 6 — エスカレーションパスを事前に把握しておく

通報後 72 時間以上返答がなかった場合の選択肢を、通報する前に整理しておきます。

ブラウザブロックリスト（Google Safe Browsing、Microsoft SmartScreen）は、レジストラが動く前にエンドユーザーを守る ための極めて有効な並行パスです。通報と同時に走らせておくのが基本戦略です。

OpenBait での自動化

OpenBait のプラットフォームを使えば、この一連のフローを手動で繰り返す必要はなくなります：

1. 候補検知（CT ログ + NRD feed + dnstwist）
2. 証拠収集（ヘッドレスブラウザでのスクリーンショット、pHash / SSIM 計算）
3. 通報生成（テンプレート自動充填、registrar 別の分岐）
4. 送信（固定 reporter address、Brevo SMTP relay 経由）
5. 結果 tracking（返答のキャッチ、ステータス管理）

という一連の流れが自動化されます。無料枠で試す か、まずは 無料のタイポスクワット候補チェッカー で候補だけ確認することもできます。

最後に — "1 件通す" ではなく "継続して通す" を設計する

一回きりの通報は、運良く通ることもあれば無視されることもあります。重要なのは、同じ品質のテンプレートを同じアドレスから継続的に送る ことで信頼を積み上げ、abuse チーム側に「この reporter は本物だ」と認識させることです。

中堅〜上場企業のセキュリティチームにとって、レジストラ abuse 通報は「やれる人が限られ、しかも継続が難しい」業務の典型です。専任担当が他の業務に移った瞬間に、積み上げてきた reporter 信頼がゼロから巻き戻しになります。

通報を属人化せず、仕組み化する ——これが、通る通報を量産する唯一の道です。OpenBait はこの仕組みを提供することに専念しています。