Làm rối email: Cách nào còn hiệu quả trong năm 2026?

• Đã thử nghiệm nhiều kỹ thuật làm rối bằng HTML·CSS·JavaScript để bảo vệ địa chỉ email khỏi trình thu thập spam, rồi so sánh tỷ lệ chặn
• Kết quả thử nghiệm trên 426 mẫu văn bản và 399 mẫu liên kết cho thấy phần lớn kỹ thuật dựa trên JS·CSS·SVG đạt tỷ lệ chặn 100%
• Các cách cũ như HTML entity·mã hóa URL vẫn cho thấy hiệu quả chặn cao
• Ngược lại, các cách như hiển thị bằng ảnh·thay ký hiệu·đảo hướng văn bản làm suy giảm nghiêm trọng khả năng truy cập và tính tiện dụng
• Tính đến năm 2026, chuyển đổi bằng JS·mã hóa AES·cơ chế tương tác người dùng được đánh giá là những phương án bảo vệ email an toàn và thực dụng nhất

---

So sánh các kỹ thuật làm rối địa chỉ email (tính đến năm 2026)

• Trình bày nhiều kỹ thuật làm rối khác nhau để ẩn địa chỉ email khỏi trình thu thập spam (harvester), cùng hiệu quả thực tế của từng kỹ thuật bằng số liệu thống kê
• Sau khi bảo vệ từng địa chỉ email theo các cách khác nhau, tác giả đo xem harvester có truy cập được hay không trên 426 mẫu văn bản và 399 mẫu liên kết để tính tỷ lệ chặn
• Phần lớn kỹ thuật dựa trên JavaScript cùng một số kỹ thuật CSS·SVG ghi nhận tỷ lệ chặn 100%
• Các cách cũ như HTML entity·mã hóa URL vẫn duy trì tỷ lệ chặn cao
• Một số kỹ thuật gây ảnh hưởng nghiêm trọng đến khả năng truy cập hoặc tính tiện dụng nên không phù hợp để dùng thực tế

1. Kỹ thuật bảo vệ email dạng văn bản thuần

• Hiển thị trực tiếp địa chỉ email trên trang nhưng dùng nhiều kỹ thuật HTML·CSS·JS khác nhau để harvester không đọc được
• Có thể tối đa hóa hiệu quả bằng cách kết hợp nhiều kỹ thuật để bảo vệ theo từng phân đoạn

• Không bảo vệ (No protection)

  • Tỷ lệ chặn 0% (0 trên 426 trường hợp bị chặn)
  • Địa chỉ email bị lộ nguyên vẹn và bị mọi harvester thu thập

• HTML entity (HTML Entities)

  • Tỷ lệ chặn 95%
  • Dù thư viện phía máy chủ tự động giải mã, trên thực tế vẫn chặn được phần lớn harvester

• Chú thích HTML (HTML Comments)

  • Tỷ lệ chặn 99%
  • Chỉ có thể chặn các harvester cơ bản có khả năng phân tích thẻ HTML kém
  • Đơn giản nhưng vẫn duy trì hiệu quả chặn cao

• HTML SVG

  • Tỷ lệ chặn 100%
  • Ẩn địa chỉ email dưới dạng văn bản bên trong đối tượng SVG
  • Trình đọc màn hình cho người khiếm thị vẫn có thể truy cập
  • Bắt buộc dùng phần tử <object>, còn <img> hoặc SVG inline có nguy cơ làm lộ mã nguồn
  • Phụ thuộc vào phông chữ nên cần chỉ định web font

• CSS display:none

  • Tỷ lệ chặn 100%
  • Tận dụng giới hạn của harvester không thể áp dụng quy tắc kiểu dáng
  • Có thể giữ được khả năng truy cập; khuyến nghị dùng display:none thay vì chỉ ẩn trực quan

• Nối chuỗi bằng JS (Concatenation)

  • Tỷ lệ chặn 100%
  • Có thể triển khai đơn giản mà không phụ thuộc bên ngoài
  • Toàn bộ email vẫn tồn tại trong mã HTML nên yếu về mặt bảo mật

• JS Rot18

  • Tỷ lệ chặn 100%
  • Dùng mã xoay ký tự tương tự ROT13
  • Harvester đơn giản không giải mã được, nhưng dễ bị khai thác bởi trình thu thập bỏ qua JS

• Chuyển đổi bằng JS (Conversion)

  • Tỷ lệ chặn 100%
  • Trong HTML chỉ chứa chuỗi vô nghĩa, còn hàm JS sẽ chuyển nó thành email thật
  • Phần lớn harvester không thể thực thi DOM·JS nên không thể khôi phục
  • Đây là kỹ thuật đơn giản nhưng rất hiệu quả

• Mã hóa AES bằng JS

  • Tỷ lệ chặn 100%
  • Bảo vệ email bằng mã hóa AES-256
  • Dùng SubtleCrypto API của trình duyệt, chỉ hoạt động trong môi trường HTTPS
  • Không có tệp JS thì không thể giải mã

• Tương tác người dùng bằng JS (User interaction)

  • Tỷ lệ chặn 100%
  • Chỉ hiển thị email khi người dùng tương tác với trang
  • Harvester sẽ phải thực thi DOM + mô phỏng sự kiện người dùng, gần như không khả thi

• Thay ký hiệu trong HTML (Symbol substitution)

  • Tỷ lệ chặn 96%
  • Thay bằng các từ như “AT”, “DOT”
  • Người dùng phải tự sửa lại nên giảm tính tiện dụng

• Chỉ dẫn bằng HTML (Instructions)

  • Tỷ lệ chặn 100%
  • Chèn chỉ dẫn thủ công vào email như “remove the .fluff”
  • Con người hoặc AI có thể hiểu, nhưng gây bất tiện lớn cho người dùng

• Ảnh HTML

  • Tỷ lệ chặn 100%
  • Hiển thị địa chỉ email bằng hình ảnh
  • Người khiếm thị không truy cập được, không thể sao chép, khiến tính tiện dụng gần như sụp đổ

• CSS content

  • Tỷ lệ chặn 100%
  • Hiển thị email bằng pseudo-element ::after
  • Nhìn thấy được bằng mắt nhưng không thể sao chép, và vẫn có thể khôi phục chỉ từ HTML
  • Được đánh giá là kỹ thuật vô ích

• Đảo hướng văn bản bằng CSS (Text direction)

  • Tỷ lệ chặn 100%
  • Dùng direction: rtl để đảo ngược chuỗi
  • Nếu harvester bỏ qua CSS thì có thể giải mã dễ dàng
  • Văn bản bị sao chép ngược nên làm giảm tính tiện dụng

2. Kỹ thuật bảo vệ liên kết có thể nhấp

• Cách bảo vệ thuộc tính href của liên kết mailto:
• Nếu văn bản liên kết có chứa email thì vẫn cần kết hợp thêm kỹ thuật làm rối văn bản riêng

• Không bảo vệ

  • Tỷ lệ chặn 0% (0 trên 399 trường hợp bị chặn)
  • Địa chỉ email bị lộ hoàn toàn

• HTML entity

  • Tỷ lệ chặn 100%
  • Dù bị tự động giải mã ở phía máy chủ, phần lớn harvester vẫn bị chặn

• Mã hóa URL

  • Tỷ lệ chặn 95%
  • Dễ giải mã nhưng trên thực tế vẫn chặn được phần lớn harvester

• Chuyển hướng HTTP

  • Tỷ lệ chặn 100%
  • Ẩn liên kết mailto: để nó trông như liên kết thông thường
  • Thiết lập chuyển hướng 302 hoặc 301 trong .htaccess
  • Dùng nofollow, noindex để ngăn công cụ tìm kiếm lập chỉ mục
  • Khi tự động điền các trường email thì cần cờ QSA

• HTML SVG

  • Tỷ lệ chặn 100%
  • Ẩn liên kết email bên trong SVG
  • Giữ được khả năng truy cập, bắt buộc dùng <object>
  • Cần chỉ định phông chữ

• Nối chuỗi bằng JS

  • Tỷ lệ chặn 100%
  • Có thể triển khai mà không phụ thuộc bên ngoài
  • Email được nhúng trực tiếp trong HTML nên không an toàn

• JS Rot18

  • Tỷ lệ chặn 99%
  • Xoay ký tự tương tự ROT13
  • Harvester đơn giản không thể giải mã

• Chuyển đổi bằng JS (Conversion)

  • Tỷ lệ chặn 100%
  • Trong HTML chỉ tồn tại liên kết giả, còn JS sẽ chuyển nó thành mailto: thật
  • Harvester chỉ truy cập được HTML nên không thể khôi phục
  • Đây là kỹ thuật đơn giản nhưng rất hiệu quả

• Mã hóa AES bằng JS

  • Tỷ lệ chặn 100%
  • Liên kết email được mã hóa bằng AES-256
  • Dùng SubtleCrypto API của trình duyệt, yêu cầu HTTPS

• Tương tác người dùng bằng JS

  • Tỷ lệ chặn 100%
  • Liên kết chỉ được kích hoạt khi người dùng tương tác với trang
  • Harvester khó có thể tái hiện điều này

3. Phê bình và phản biện

• Về quan điểm “spammer không quét web mà mua cơ sở dữ liệu bị rò rỉ”
  • Các địa chỉ email trên trang này chỉ được công khai duy nhất trên trang này nhưng vẫn nhận hàng nghìn email rác
• Về quan điểm “không cần bảo vệ”
  • Nội dung phổ biến sẽ bị thu thập tập trung, nên nếu có khả năng lan truyền thì vẫn cần bảo vệ
• Về quan điểm “chỉ cần bộ lọc spam là đủ”
  • Những kỹ thuật này có thể triển khai miễn phí mà không gây dương tính giả, nên dùng song song với bộ lọc là hợp lý
• Về quan điểm “kỹ thuật bị lộ thì sẽ vô dụng”
  • Số liệu thống kê cho thấy những kỹ thuật giống nhau qua hàng chục năm vẫn còn hiệu lực

4. Phương pháp thử nghiệm

• Công khai thực tế các địa chỉ email được bảo vệ bằng từng kỹ thuật làm rối để vận hành như honeypot dành cho harvester
• Khi có spam gửi đến, coi như kỹ thuật bảo vệ của địa chỉ đó đã bị vượt qua
• Nhóm thư theo từng spammer để tính thống kê theo số lượng người gửi
• Tự xây dựng máy chủ mail và ứng dụng khách để tránh việc lọc spam làm sai lệch thống kê
• Vì harvester dạng văn bản và dạng liên kết là khác nhau nên tách thống kê riêng
• Quy mô mẫu hiện vẫn còn nhỏ, nhưng dự kiến độ tin cậy thống kê sẽ tăng khi số lượng liên kết tăng lên

Kết luận

• Các kỹ thuật chuyển đổi·mã hóa·tương tác người dùng dựa trên JS mang lại mức bảo mật và khả năng truy cập cao nhất
• CSS display:none và kỹ thuật đối tượng SVG cũng rất tốt ở cả khả năng truy cập lẫn tỷ lệ chặn
• Thay ký hiệu, ảnh, đảo hướng văn bản gây hại nghiêm trọng cho tính tiện dụng nên không được khuyến nghị
• Nếu cần công khai email, thì chuyển đổi JS đơn giản hoặc mã hóa AES là lựa chọn hiệu quả nhất tính đến năm 2026

[GN⁺]

Ý kiến trên Hacker News

• Trước đây tôi từng quan tâm đến việc bị thu thập email, nhưng giờ thì cứ công khai email trên website của mình
  Bộ lọc spam đã đủ tốt
  Dù vậy, bài tổng quan về các kỹ thuật này vẫn khá thú vị. Tôi ngạc nhiên là những cách đơn giản cũng hiệu quả đến vậy

  • Từ đầu những năm 2000 tôi đã đăng email dạng văn bản thuần với liên kết mailto: trên blog, mà mỗi ngày chỉ nhận vài thư spam
    Có thể là do bộ lọc của Zoho hoạt động tốt, nhưng tôi không nghĩ nó tốt hơn đáng kể so với các dịch vụ lớn
  • Phần lớn bot thu thập đã có sẵn hàng triệu địa chỉ, nên chẳng mấy quan tâm đến vài email hiếm
    Vì vậy dùng một cách đơn giản của riêng mình cũng ổn, nhưng nếu công khai nó thì có thể bị vô hiệu hóa ngay
  • Từ sau khi tôi đăng email lên website công ty, mỗi tháng nhận hơn 1.500 thư spam
  • Tôi cũng công khai email theo cách tương tự, nhưng nếu các cách đơn giản như HTML entity hay display:none có thể chặn hơn 90% thì cũng đáng để cân nhắc lại
  • Tôi nghĩ email sớm muộn gì cũng sẽ bị lộ. Chỉ là spam dựa trên LLM ngày càng có khả năng lách bộ lọc tốt hơn

• Email của tôi đã xuất hiện hơn 90 lần ở dạng văn bản thuần trong các commit của những kho mã nguồn mở nổi tiếng trên GitHub
  Thế mà suốt 8 năm qua tôi gần như không nhận spam
  Có thể định dạng được bao bởi < và > đã làm bộ thu thập bị rối
  Dạo này có vẻ việc mua danh sách email còn phổ biến hơn cả tự đi thu thập

  • Tôi cấu hình địa chỉ wildcard trên domain của mình
    Spam thường xuyên gửi tới các địa chỉ như git@, contact@, admin@
    Gần đây còn có cả email giả mạo CEO gửi tới những địa chỉ giả như finance@
    Trớ trêu là email tôi đăng công khai dạng văn bản thuần trên hồ sơ HN thì gần như không có spam

• Giả thuyết của tôi là bot thu thập email không phân tích HTML, mà chỉ đơn giản tìm chuỗi quanh ký tự @
  Phân tích HTML tốn kém, nên cách đơn giản như vậy có thể hiệu quả hơn
  Có lẽ vì thế mà HTML entity lại hữu ích

  • Có thể bot đã học được rằng spam gửi đến các địa chỉ bị làm rối có tỷ lệ phản hồi thấp
    Nên chúng bỏ qua hẳn những địa chỉ như vậy
  • Đúng vậy, đa số chỉ tìm kiếm byte đơn giản, nhưng phía marketing blackhat có đủ loại kỹ thuật scraping
  • Cuối cùng vẫn là vấn đề đối phương lì lợm đến mức nào. Kẻ tấn công phi lý trí sẽ bám theo đến cùng
  • Cách trích xuất dựa trên token quanh @ cũng vẫn hoạt động tốt chỉ với vài biến thể nhỏ

• Bài này viết tốt, nhưng tiếc là không nhắc đến cách sở hữu cả một domain để cấp email riêng cho từng người nhận
  Khi có spam thì chỉ cần chặn đúng địa chỉ đó
  Hoặc cũng có thể sống mà không dùng email. Giờ đây phần lớn việc có thể xử lý bằng email tạm thời

  • Tôi cũng vận hành kiểu đó suốt 20 năm nay
    Nhưng phần lớn spam lại đến từ việc bạn bè hay người thân chia sẻ địa chỉ của tôi cho ứng dụng
    Email công khai thì tôi chặn được 100% bằng cách ghép nối bằng JavaScript đơn giản
  • Trước đây tôi từng định tạo email riêng cho từng người, nhưng cuối cùng đã đơn giản hóa thành một địa chỉ duy nhất dựa trên whitelist
    Hiệu quả tương tự mà quản lý dễ hơn nhiều

• Có cách giấu một địa chỉ email tarpit trên website
  Dùng CSS để ẩn đi để người không thấy, còn nếu bot gửi thư vào đó thì chặn IP đó trong 24 giờ

  • Nhưng cách này có nguy cơ chặn cả máy chủ mail lớn như Google
    Vì spam cũng có thể đến từ tài khoản Gmail nên tác dụng phụ khá lớn
  • Có một khái niệm tương tự là Project Honey Pot

• Nội dung hay, nhưng tôi nghĩ tiêu đề nên là 'Email address obfuscation' thì phù hợp hơn
  Chỉ là đọc những bài như thế này có vẻ bọn spammer cũng sẽ học được gì đó

  • Dùng “email” thay cho “email address” dễ gây nhầm lẫn. Trong ngữ cảnh này nhiều khi người ta sẽ hiểu là “thư email”
  • Cách ghi thông tin liên hệ trên trang của Greg Egan quá khó hiểu, gần như không thể giải mã

• Trước đây tôi từng thử xem kiểu viết như “me at foobar dot com” liệu còn hiệu quả không
  Khi dùng LLM để giải nhiều cách làm rối email khác nhau, tôi thấy hầu hết các cách không dựa trên CSS hay JS đều có thể diễn giải được
  Dù vậy, hiện nay bộ lọc spam hoạt động khá tốt nên công khai email dạng văn bản thuần cũng không thành vấn đề lớn
  Ngược lại, email thông báo từ dịch vụ còn gây phiền hơn

  • Cách tốt hơn là để khách truy cập dùng một ít CPU để tạo ra email token duy nhất
    Nếu có abuse thì chỉ cần hủy đúng địa chỉ đó
    Sẽ là lý tưởng nếu client và máy chủ mail hỗ trợ kiểu API này
  • Bot thu thập dựa trên LLM có thể còn giỏi diễn giải chỉ dẫn hơn cả con người
    Vì vậy các kỹ thuật làm rối cơ bản để chặn bot regex đơn giản vẫn còn hữu ích
  • Cũng có truyện tranh xkcd 1808 liên quan đến chủ đề này

• Đầu năm nay khi làm một trình thông dịch Brainfuck bằng C, tôi đã thử dùng nó cho việc làm rối email
  Mỗi email được lưu thành một chương trình Brainfuck, rồi trình thông dịch JS sẽ chạy để hiển thị dạng văn bản thuần
  JS được tải từ domain ngoài, sau khi kiểm tra referer mới gửi mã thực tế
  Tất nhiên gặp bot có chạy JS thì vô dụng, nhưng như một thử nghiệm làm rối sáng tạo thì khá thú vị

  • Tôi tò mò không biết cách này khác gì so với việc chỉ mã hóa XOR trong JS
  • Nếu bot đưa ảnh chụp màn hình vào LLM hoặc OCR thì cách này có lẽ cũng bị vô hiệu hóa

• Bài này đôi khi trông như một hướng dẫn để làm cho bot thu thập email thông minh hơn

  • Đúng vậy, nhưng việc chạy JS hay CSS, render SVG v.v. vẫn là các tác vụ tốn kém, nên với bot quy mô lớn thì vẫn là gánh nặng