メール難読化: 2026年に効果的な方法は?
(spencermortensen.com)- メールアドレスをスパム収集ボットから保護するため、さまざまなHTML・CSS・JavaScript難読化手法を実験し、遮断率を比較
- 426件のテキスト・399件のリンク標本を対象にテストした結果、大半のJSベース・CSS・SVG手法が100%の遮断率を記録
- HTMLエンティティ・URLエンコードのような古い方式も、依然として高い遮断効果を示した
- 一方で画像表示・記号置換・テキスト方向反転などは、アクセシビリティと使い勝手を深刻に損なう
- 2026年時点では、JS変換・AES暗号化・ユーザーインタラクション方式が最も安全で実用的なメール保護手段と評価される
メールアドレス難読化手法の比較（2026年時点）
- メールアドレスを**スパム収集ボット（ハーベスター）**から隠すためのさまざまな難読化手法と、各手法の実際の効果を統計で提示
- それぞれのメールアドレスを異なる方法で保護した後、**426件（テキスト）および399件（リンク）**の標本を対象に、ハーベスターが取得できるかを測定して遮断率を算出
- 大半のJavaScriptベース手法と一部のCSS・SVG手法が100%の遮断率を記録
- HTMLエンティティ・URLエンコードのような古い方式も、依然として高い遮断率を維持
- 一部の手法はアクセシビリティや使い勝手を大きく損ない、実運用には不向き
1. 一般テキストのメール保護手法
- メールアドレスをページに直接表示しつつ、さまざまなHTML・CSS・JS手法でハーベスターに読ませない方式
- 複数の手法を組み合わせてセグメントごとに保護すると、効果を最大化できる
-
保護なし (No protection)
- 遮断率 0%（426件中0件を遮断）
- メールアドレスがそのまま露出し、すべてのハーベスターに収集される
-
HTMLエンティティ (HTML Entities)
- 遮断率 95%
- サーバー側ライブラリが自動でデコードするが、実際には大半のハーベスターを遮断
-
HTMLコメント (HTML Comments)
- 遮断率 99%
- HTMLタグ解釈が弱い基本的なハーベスターしか遮断できない
- 単純だが、なお高い遮断効果を維持
-
HTML SVG
- 遮断率 100%
- メールアドレスをSVGオブジェクト内部のテキストとして隠す
- 視覚障害者向けスクリーンリーダーからアクセス可能
<object>要素の使用が必須で、<img>やインラインSVGはソース露出の危険がある- フォント依存性があるため、Webフォント指定が必要
-
CSS display:none
- 遮断率 100%
- スタイル規則を適用できないハーベスターの限界を利用
- アクセシビリティを維持でき、視覚的非表示の代わりに
display:noneの使用を推奨
-
JS文字列連結 (Concatenation)
- 遮断率 100%
- 外部依存なしで簡単に実装可能
- メール全体がHTMLソース内に存在するため、セキュリティ上は脆弱
-
JS Rot18
- 遮断率 100%
- ROT13に似た文字回転暗号を使用
- 単純なハーベスターでは解読できないが、JSを無視する収集器には脆弱
-
JS変換 (Conversion)
- 遮断率 100%
- HTMLには意味のない文字列だけを含め、JS関数がそれを実際のメールへ変換
- 大半のハーベスターはDOM・JSを実行できず復元不可
- 簡単で非常に効果的な手法
-
JS AES暗号化
- 遮断率 100%
- AES-256暗号化でメールを保護
- ブラウザのSubtleCrypto APIを使用し、HTTPS環境でのみ動作
- JSファイルなしでは復号できない
-
JSユーザーインタラクション (User interaction)
- 遮断率 100%
- ユーザーがページと相互作用したときにのみメールを表示
- ハーベスターにはDOM実行 + ユーザーイベントのシミュレーションが必要で、事実上不可能
-
HTML記号置換 (Symbol substitution)
- 遮断率 96%
- “AT”, “DOT” などで置換
- ユーザーが手動で修正する必要があり、使い勝手が低下
-
HTML指示文 (Instructions)
- 遮断率 100%
- メールに “remove the .fluff” のような手動指示を含める
- 人間やAIには解釈できるが、ユーザーの負担が大きい
-
HTML画像
- 遮断率 100%
- メールアドレスを画像として表示
- 視覚障害者が利用できず、コピーもできないなど、使い勝手が崩壊
-
CSS content
- 遮断率 100%
::after疑似要素でメールを表示- 見た目には表示されるがコピーできず、HTMLだけでも復元可能
- 無意味な手法と評価
-
CSSテキスト方向 (Text direction)
- 遮断率 100%
direction: rtlで文字列を反転- ハーベスターがCSSを無視すれば容易に解読可能
- テキストが逆向きにコピーされ、使い勝手が低下
2. クリック可能なリンクの保護手法
mailto:リンクのhref属性を保護する方式- リンクテキストにメールが含まれる場合は、別途テキスト難読化手法の併用が必要
-
保護なし
- 遮断率 0%（399件中0件を遮断）
- メールアドレスが完全に露出
-
HTMLエンティティ
- 遮断率 100%
- サーバー側の自動デコードにもかかわらず、大半のハーベスターを遮断
-
URLエンコード
- 遮断率 95%
- デコードは容易だが、実際には大半のハーベスターを遮断
-
HTTPリダイレクト
- 遮断率 100%
mailto:リンクを通常のリンクのように見せかけて隠す.htaccessで302または301リダイレクトを設定nofollow, noindexで検索エンジンのインデックスを防止- メールフィールド自動入力時にはQSAフラグが必要
-
HTML SVG
- 遮断率 100%
- メールリンクをSVG内部に隠す
- アクセシビリティを維持し、
<object>の使用が必須 - フォント指定が必要
-
JS文字列連結
- 遮断率 100%
- 外部依存なしで実装可能
- メールがHTMLに直接含まれており安全ではない
-
JS Rot18
- 遮断率 99%
- ROT13に似た文字回転
- 単純なハーベスターでは解読不可
-
JS変換 (Conversion)
- 遮断率 100%
- HTMLには偽のリンクだけが存在し、JSがそれを実際の
mailto:に変換 - ハーベスターはHTMLにしかアクセスできないため復元不可
- 簡単で非常に効果的な手法
-
JS AES暗号化
- 遮断率 100%
- AES-256で暗号化されたメールリンク
- ブラウザのSubtleCrypto APIを使用し、HTTPSが必要
-
JSユーザーインタラクション
- 遮断率 100%
- ユーザーがページと相互作用して初めてリンクが有効化
- ハーベスターがこれを再現するのは難しい
3. 批判と反論
- 「スパマーはWebをスクレイピングせず、流出データベースを購入する」という主張について
- このページのメールアドレスはこのページでのみ公開されていたにもかかわらず、数千件のスパムを受信
- 「保護は不要」という主張について
- 人気コンテンツは集中的に収集されるため、バイラルの可能性を考えると保護が必要
- 「スパムフィルターだけで十分」という主張について
- これらの手法は誤検知なしで無料実装が可能で、フィルターとの併用が望ましい
- 「手法が知られたら無意味」という主張について
- 数十年間同じ手法が依然有効であることが統計で確認された
4. 実験方法論
- 各難読化手法で保護したメールアドレスを実際に公開し、ハーベスター用ハニーポットとして運用
- スパムが到着したら、そのアドレスの保護手法が突破されたと見なす
- スパマーごとにメッセージをグループ化し、送信者数ベースの統計を算出
- スパムフィルタリングが統計を歪めないよう、メールサーバーとクライアントを自前で構築
- テキストベースとリンクベースのハーベスターは異なるため、別統計として分離
- 標本数はまだ少ないが、リンクが増えるほど統計の信頼性向上が見込まれる
結論
- JSベースの変換・暗号化・ユーザーインタラクション手法が最も高いセキュリティとアクセシビリティを提供
- CSS display:none と SVGオブジェクト手法も、アクセシビリティと遮断率の面で優秀
- 記号置換、画像、テキスト方向反転などは使い勝手を深刻に損なうため非推奨
- メール公開が必要な場合、簡単なJS変換またはAES暗号化方式が2026年時点で最も効果的な選択肢
1件のコメント
Hacker Newsの意見
以前はメールアドレス収集を気にしていたが、今は自分のWebサイトにそのままメールアドレスを公開している
スパムフィルタリングが十分優秀だからだ
それでもこういう技術レビューは興味深かった。単純な方法でもかなり効果があるというのが意外だった
mailto:リンクでメールアドレスを平文で載せているが、スパムは1日に数通程度しか来ないおそらくZohoのフィルタリングがうまく機能しているのだろうが、大手サービスより特別に優れているとは思わない
だから自分なりの簡単な方法を使っても構わないが、それを公開するとすぐ無力化される可能性がある
display:noneのような簡単な方法で90%以上防げるなら、また検討する価値はある自分のメールアドレスはGitHubの人気オープンソースリポジトリのコミットに平文で90回以上含まれている
それなのに8年間ほとんどスパムを受け取ったことがない
<と>で囲まれた形式が収集器を混乱させているのかもしれない最近は直接収集するよりメールリストの購入のほうが一般的なようだ
git@、contact@、admin@のようなアドレスにはよくスパムが来る最近は
finance@のような偽アドレス宛てにCEOなりすましメールが届くこともある皮肉なことに、HNプロフィールに平文で載せているメールアドレスにはほとんどスパムが来ない
私の仮説では、メールアドレス収集器はHTMLをパースせず、単に**
@文字の周辺の文字列**だけを探しているHTMLのパースはコストが高いので、こうした単純な方法のほうが効率的なのかもしれない
だからHTMLエンティティが効果的なのだろう
だからそういうアドレスは最初から無視しているのかもしれない
@周辺のトークンベース抽出も、少し変形するだけで十分機能するこの記事はよく書けているが、ドメイン全体を所有して受信者ごとに固有のメールアドレスを与える方法に触れていないのが惜しい
スパムが来たらそのアドレスだけブロックすればよい
あるいは、そもそもメールを使わない生活という手もある。最近は使い捨てメールで大半が解決できる
ただしスパムの大半は、友人や家族が私のアドレスをアプリに共有することで発生する
公開メールアドレスについては、簡単なJavaScript連結方式で100%防げていた
効果はほぼ同じで、管理はずっと楽だった
Webサイトにtarpitメールアドレスを隠しておく方法がある
CSSで隠して人には見えなくし、ボットがそこにメールを送ってきたらそのIPを24時間ブロックする
Gmailアカウントから来るスパムもあるので、副作用が大きい
内容は良いが、タイトルは**「Email address obfuscation」**のほうが適切だと思う
ただ、こういう記事を見るとスパマー側も学べてしまいそうだ
以前、「me at foobar dot com」のような表現が今でも有効か気になって試してみた
LLMを使ってさまざまなメールアドレス難読化方式を解かせてみたところ、CSSやJSベースでないものは大半が解釈できた
それでも最近はスパムフィルタがよく機能するので、平文のメールアドレスを公開しても大きな問題にはならなかった
むしろサービス通知メールのほうが厄介だ
abuseが発生したらそのアドレスだけ破棄すればよい
クライアントとメールサーバーがこうしたAPIをサポートしていれば理想的だろう
だから単純なregexボットを防ぐ初歩的な難読化は依然として有効だと思う
今年の初め、CでBrainfuckインタプリタを作っていたときに、メールアドレス難読化に使ってみた
各メールアドレスをBrainfuckプログラムとして保存し、JSインタプリタが実行して平文を表示する
JSは外部ドメインから読み込まれ、refererを検証した上で実際のコードを送信する
もちろんJSを実行する収集器には無力だが、創造的な難読化実験としては面白かった
この記事は、メールアドレス収集器をより賢くするためのガイドにも見える