ハクソク

世界を動かす技術を、日本語で。

メールの難読化：2026年に効果的な方法は？

54日前原文(spencermortensen.com)

概要

  • メールアドレスをスパマーから隠すための 最新防御テクニック とその突破率を解説
  • HTML・CSS・JavaScript・画像 など多様な方法を網羅
  • それぞれの手法の長所・短所、実用性、ユーザビリティ に触れる
  • クリック可能なメールリンク の保護方法も詳細に紹介
  • 統計データ 付きで、実際にどれだけのスパマーを防げるか明示

メールアドレス防御テクニックと突破率

  • メールアドレスを 平文で記載 すると、全てのスパマーに捕捉される危険性
  • 各手法を 組み合わせて分割 し、複合防御することが理想

1. 平文メールアドレスの保護手法

  • 無防備（No protection）

    • スパマー防御率0%、全く効果なし

  • HTMLエンティティ化

    • 例：ab@...
    • 95%のスパマーをブロック
    • サーバー側で自動デコードされやすく、万能ではないが意外と効果あり

  • HTMLタグ分割

    • 例：ac@email.spencermortensen<!--.example-->.com
    • 98%のスパマーをブロック
    • 基本的なハーベスターには有効、上級者には突破されやすい

  • SVGオブジェクト内に埋め込む

    • 100%のスパマーをブロック
    • 視覚・スクリーンリーダー対応、imgではなくobject必須

  • CSS display:noneで分割テキストを隠す

    • 100%のスパマーをブロック
    • スタイル無視のハーベスターには強い、アクセシビリティも維持

  • JavaScriptで文字列連結

    • 100%のスパマーをブロック
    • HTMLソースに全情報が残るため、完全な安全性はない

  • JavaScript ROT18変換

    • 100%のスパマーをブロック
    • JS非対応のハーベスターには有効、変換パターンの工夫が必要

  • JavaScript独自変換

    • 100%のスパマーをブロック
    • HTML内は無意味な文字列、独自関数で復元、最強クラスの防御

  • JavaScript AES暗号化

    • 100%のスパマーをブロック
    • SubtleCrypto利用、https必須、外部JS必須、復号困難

  • ユーザー操作時のみ表示（JS）

    • 100%のスパマーをブロック
    • ユーザー操作必須、ハーベスターには非常に高い障壁

  • 記号置換（AT/DOT）

    • 97%のスパマーをブロック
    • 誰でも復号可能、ユーザビリティ低下

  • HTML内で補足説明付き記述

    • 100%のスパマーをブロック
    • 人間やAI以外には困難、ユーザーの手間増大

  • 画像化

    • 100%のスパマーをブロック
    • 視覚障害者やコピペ不可、ユーザビリティ最悪

  • CSS content擬似要素で表示

    • 100%のスパマーをブロック
    • テキストは見えるがコピペ不可、HTMLから復元可能

  • CSSテキスト方向逆転

    • 100%のスパマーをブロック
    • 表示は逆順、コピペ時に混乱、基本的に無意味

2. クリック可能なメールリンク保護

  • 無防備なmailtoリンク

    • スパマー防御率0%、全く効果なし

  • mailtoのHTMLエンティティ化

    • 100%のスパマーをブロック
    • サーバー側でデコードされやすいが、現実には有効

  • mailtoのURLエンコード

    • 96%のスパマーをブロック
    • サーバー側で復号容易、意外と効果あり

  • HTTPリダイレクト経由mailto

    • 100%のスパマーをブロック
    • mailtoリンクを通常リンクに偽装、.htaccessによるリダイレクト設定
    • 検索エンジン対策にnofollow, noindex推奨

  • SVG内objectでメールリンク

    • 100%のスパマーをブロック
    • 視覚・スクリーンリーダー対応、object必須、img不可

各手法の要点と選び方

  • HTML・CSS・JS・画像 など多様な手法が存在
  • ユーザビリティと防御力のトレードオフ を考慮
    • 画像化やCSS逆転などはユーザー不便
    • JS変換やSVG埋め込みは高防御・高アクセシビリティ
  • 複数手法の組み合わせ で最大効果
  • https必須の手法 も存在（例：AES暗号化）

まとめ

  • メールアドレス公開時は 複数の防御策併用 が最適
  • ユーザー体験と防御力のバランス を意識
  • 最新のJSやSVGを活用 し、できる限り平文は避ける
  • 統計データ を参考に、実運用環境に適した手法選択が重要

Hackerたちの意見

いいね！でも、タイトルは「メールアドレスの難読化」にした方がいいと思う。シェアしてくれてありがとう、でもスパマーもこれを学べるようになっちゃうね（：

└

https://www.gregegan.net/ 連絡先: [any mailbox] [at] [このウェブサイトのドメイン名]。インタビューやサイン会、ポッドキャストへの出演、会議やコンベンションへの参加、フィクションや科学理論、チャットボットが吐き出したテキストへのフィードバックや推薦を求めないでください。これをどうやって難読化しているのか全く分からないです。

└

確かに、「メール」という言葉を「メールアドレス」の意味で使うのはイライラする。普通は「メールメッセージ」を指すことが多いのに。

数年前からメール収集については気にしなくなったよ。ウェブサイトにそのままメールを載せてるし、スパムの処理もまあまあかな。だけど、この技術のレビューは好きだな。シンプルなものでもすごく効果的で、驚いたよ。

└

そうだね、結局アドレスはどこかで漏れちゃう。SpamAssassinはあんまりうまく機能しなかったけど、メールホスティングを自分のサーバーからAppleに移してからは、スパムは問題になってないよ。

└

メールアドレスは結局漏れちゃうと思うけど、LLMはスパム生成が得意だから、すぐにほとんどのフィルターを回避するようになると思う。

└

企業のウェブサイトにメールアドレスを載せてから、月に1,500通以上のスパムメールが来てるよ。

└

2000年代初頭から、当時のウェブサイト（今はブログ）にプレーンテキストでmailto:リンクにメールアドレスを載せてるけど、スパムはあんまり問題じゃないよ。1日に数通のスパムメッセージがスパムボックスに入るくらい。もしかしたら、プロバイダーがスパムフィルタリングが得意なのかもしれないけど、主要なプレイヤーよりも良いとは思えないな。（何年もZohoを使ってるけど、まあ「まあまあ」だから、切り替える価値はないね。）

ちょっと前に「me at foobar dot com」っていう一般的な表現が実際に役立つのか気になって、特に今はLLMがあるから、いくつかの一般的な「難読化」技術を調べてこのサイトを見つけたんだ（2026年の更新じゃなくて、その前のやつ）。それから、サイトの例を使って簡単なLLMクエリを書いたんだ[0]（このツールは、llama.cppとMistral Small 3.1を使ったコマンドラインプログラムのフロントエンドに過ぎないから、比較的早く読み込めてシンプルなプロンプトには十分だよ）。私が見た限りでは、CSSトリックやJavaScriptに頼らないものは何でも明らかにできるかも。ただ、他の人も言ってたけど、個人的には数年前からメール収集は気にしてないよ。スパムフィルターが結構いい仕事してるからね。ここにプレーンテキストでメールを載せてるけど（多分、すごく収集されてるだろうね）、たまに来るスパムは実際に登録したサービスからの「スパム」に埋もれちゃってる（くすっ、LinkedInとかね）。[0] https://i.imgur.com/ytYkyQW.png

└

関連するxkcd: https://xkcd.com/1808/

└

個別のアドレスの方がいいと思う。例えば、ブログを訪れた人がメールを送りたい場合、他の誰にも渡してないアドレスを「得る」ためにCPUを使うっていうのはどう？例えば、user+TOKEN@example.comみたいに、他のTOKENを推測するのが難しいようにアルゴリズムで設計されてる。もし悪用されたら、そのアドレスだけ無効にすればいいし。（紙の広告みたいな非対話的なコンテキストなら、自分で生成することもできる。）もちろん、こういう仕組みを理解しているメールクライアントと、新しいアドレスを生成するAPIを持っているメールサービスがあればベストだね。誰かに冷やかしメールを送りたいときに、新しい送信元アドレスを使えるように。数年前、必要に応じて新しいアドレスを作成したり、無効にしたり、誰に渡したかのメモを管理する電話アプリを作るという夢を持ってた。

年始に自分のbrainfckインタープリターをCで作ったとき、言語の使い道を見つけるのに本当に苦労したんだ。最終的に、ウェブサイトのメールをこの言語で難読化するアイデアが浮かんだ。基本的に、各メールはbrainfckプログラムとして書かれて「data-」属性に保存される。HTMLにはデフォルトで「メールを見るにはJavaScriptを有効にしてください。」っていうもっと原始的な難読化された文が含まれていて、それが別のbrainfckインタープリター（JSで書かれた）によってbrainfckコードの出力に置き換えられる。ASCIIだけを出力するから、出力する値に常に32を足すことでbrainfckコードのサイズを減らせるんだ。JavaScriptは、見た目はサードパーティのドメインから読み込まれる。そこでヒューリスティックに基づいてフィルタリングして、「referer」が一致するか確認してから実際のインタープリターコードを送信する。もちろん、これがうまくいかない場合もあるけど、最近読んだところによると、CSSでDOOMを実行できるようになるらしいから、CSSでbrainfckインタープリターを持つのも可能だよね？それが次のステップかも…ただJavaScriptを排除するために。でも、メールの難読化のためだけにJavaScriptを使うデメリットには納得してるよ。とにかく…私はその公開連絡先を定期的に（少なくとも年に一回）ローテーションしてる。

└

このアプローチは、メールをそのJSに保存されたランダムなバイト列とXORするJavaScriptを使うのとどう違うの？

└

スクレイパーがスクリーンショットを撮って、それをLLMやOCRに渡す場合、どうなるの？

一つのトリックは、ウェブサイトにターピットメールアドレスを持つことだよ。CSSを使って隠してるから、実際の訪問者には見えないけど、ソースには見えるんだ。そのアドレスにメールが届いたら、そのIPを24時間ブロックすればいいんだ。

└

これは悪いアドバイスに聞こえるし、Googleや他の主要なESPをブロックする結果になると思う。時々、Gmailアカウントを作るために手間をかけた人からスパムが来ることがある。このアドバイスに従うと、ハニーポットのメールアドレスがGmailアカウントからスパムを受け取って、あなたのスクリプトがGmailサーバーをブロックすることになるよ。

└

これに似た感じだね: https://www.projecthoneypot.org/

なんで、302で「mailto:」に飛ぶと、リンクをクリックしなくてもメールクライアントが開くの？おかしいと思うんだけど。

└

一部のブラウザは、その場合にメールクライアントを開くかどうか聞いてくるよね。リダイレクトされたダウンロードリンクがMIMEタイプやファイルの拡張子に基づいてプログラムを開くのと、あまり変わらないと思う。YouTubeリンクがYouTubeアプリで開くような、アプリに関連付けられた別のURLパターンへのリダイレクトとも同じだし。

HTML CGIフォームは省かれたね。ウェブページでメールを生成して、サーバーが基本的なチェックやスパム対策をした後にメールを送信するんだ。例えば、CSSのパズルを解いたり、DOOMのゲームに勝ったりする感じ。

すごくシンプルな暗号化とちょっとしたパディング（記事の中のフラフ）を使ってるけど、メールアドレスはJSで更新されるんだ。これにはJSと結果のDOMを評価する必要がある。JSを評価しないと、アドレスは「please@activate.javascript」みたいになるよ。もしくは「potus@whitehouse.gov」を使うと、無知なスクレイパーがアメリカ政府にスパムを送る羽目になる。

僕の仮説では、メールスクレイパーはHTMLを全く解析してないと思う。おそらく、@の文字を探して、その両側にあるものを取ってるんじゃないかな。それなら、HTML解析が高くつくことを考えると、現実的に使えるアドレスをたくさん集められると思う。（同様に、ほとんどのリンクはバイトストリングで「href」を検索して、その右側にあるものを取ることで見つけられると思う。）これがHTMLエンティティが効果的な理由かもね。一方で、TLSハンドシェイクはHTML解析よりもずっと高コストじゃない？リソースを大量に消費するパーサーの失敗モードを避けるためなのかな？

└

@の周りでトークンベースの抽出は、ちょっとした調整でうまくいく方法の一つだね。

└

本当に色々だね。君の言う通り、ほとんどの現代的なものはバイトストリングで@を探すけど、ブラックハットマーケティングの世界にはメールをスクレイピングするための何百もの異なる方法があると思うよ。

これは、メールハーベスターをさらに良くするための素晴らしいリストだね。