Câu hỏi thường gặp

echo.email phân tích một email cho mỗi địa chỉ và giải thích kết quả. Các câu trả lời dưới đây cho biết dịch vụ hoạt động thế nào và ý nghĩa của từng mục kiểm tra trong báo cáo.

echo.email hoạt động như thế nào?

Trang chủ cấp một địa chỉ mới gồm ba từ, ví dụ power.file.tube@echo.email. Thư gửi đến địa chỉ này sẽ đến máy chủ thư của echo.email. Máy chủ ghi lại cuộc hội thoại SMTP và chuyển thư đi phân tích. Vài giây sau, trang chuyển sang báo cáo về xác thực, nội dung, tuân thủ và gửi thư. Bạn không cần cài đặt gì và không có tài khoản nào.

Địa chỉ có hiệu lực trong bao lâu?

Địa chỉ hoạt động khi trang còn mở. Trang kiểm tra lại mỗi hai giây, và nếu bạn tải lại trong vòng 10 phút thì tab đó vẫn giữ nguyên địa chỉ. Khi trang đã đóng hơn 10 phút, máy chủ thư từ chối thư mới gửi đến địa chỉ này bằng một lỗi vĩnh viễn.

Thư đến đầu tiên được nhận. Các thư đến sau gửi tới cùng địa chỉ sẽ bị từ chối, vì vậy mỗi báo cáo thuộc về đúng một email. Thư lớn hơn 10 MB bị từ chối ngay trong cuộc hội thoại SMTP.

Báo cáo được lưu trong bao lâu?

Mọi báo cáo, thư được lưu và dữ liệu hình ảnh đã tải về đều tự động bị xóa 24 giờ sau khi thư đến. Trong 24 giờ đó, bất kỳ ai có liên kết báo cáo đều mở được, và sau đó liên kết không còn hoạt động. Báo cáo mẫu là ngoại lệ duy nhất, vì báo cáo mẫu đến từ một thư thử nghiệm được gửi riêng cho mục đích này.

Nội dung thư được xử lý ra sao?

echo.email lưu toàn bộ thư, gồm header, nội dung và tệp đính kèm, cùng với chi tiết phiên SMTP như địa chỉ IP gửi, tên HELO và phiên bản TLS. Dữ liệu được lưu tại EU, và máy chủ thư đặt tại Falkenstein, Đức. Bất kỳ ai có liên kết báo cáo đều xem được toàn bộ thư, vì vậy thư kiểm tra nên có nội dung an toàn để chia sẻ. Bản tin thường có liên kết theo dõi và liên kết hủy đăng ký gắn với một người nhận, và bản sao gửi đến danh sách thử nghiệm giúp giữ kín những liên kết đó.

Hai địa chỉ liên hệ trực tiếp với đơn vị vận hành: contact@echo.email cho câu hỏi và báo cáo, và privacy@echo.email cho yêu cầu về dữ liệu. Chính sách quyền riêng tư có đầy đủ chi tiết.

Bài kiểm tra SPF kiểm tra điều gì?

SPF liệt kê các máy chủ được phép gửi thư dùng một tên miền trong return path. echo.email lấy tên miền từ người gửi phong bì (địa chỉ MAIL FROM, còn gọi là return path) và đánh giá bản ghi SPF của tên miền đó so với địa chỉ IP của máy chủ gửi thư. Chỉ kết quả pass mới được tính là tốt. Với softfail, neutral và none, bên nhận đều không có bằng chứng SPF về người gửi.

echo.email không kiểm tra tên HELO. Các nhà cung cấp hộp thư lớn cũng đánh giá SPF cho thư hàng loạt theo cách này. Báo cáo hiển thị mọi bản ghi và cơ chế trên đường đi, nên bạn thấy rõ cách dẫn đến kết quả cuối cùng.

Vì sao số lượt tra cứu DNS lại quan trọng?

Một lần đánh giá SPF được phép tối đa 10 lượt tra cứu DNS. Mỗi cơ chế include, a, mx, ptr, exists và redirect đều tính vào giới hạn này, kể cả những cơ chế nằm trong các include lồng nhau. Vượt giới hạn sẽ biến kết quả thành lỗi vĩnh viễn, và bên nhận coi thư như không có SPF hợp lệ. Lượt tra cứu rỗng, tức các truy vấn không trả về bản ghi nào, có giới hạn riêng là hai. Nguyên nhân thường gặp là chuỗi dài các include của bên thứ ba, và rút gọn danh sách dịch vụ sẽ giải quyết vấn đề.

DKIM chứng minh điều gì?

DKIM thêm một chữ ký mật mã vào header của thư. Tên miền ký công bố khóa công khai trong DNS dưới một selector, và echo.email lấy khóa đó để xác minh chữ ký với header và nội dung như khi nhận được. Kết quả pass nghĩa là các phần được ký đến nơi mà không bị thay đổi và tên miền ký đã bảo đảm cho chúng.

Báo cáo liệt kê tên miền ký (d=), selector (s=), các header được ký (h=), cũng như loại khóa và độ dài khóa. Giới hạn độ dài nội dung (l=) sẽ được đánh dấu, vì giới hạn này cho phép nối thêm nội dung sau khi ký.

DMARC là gì?

DMARC gắn SPF và DKIM với tên miền trong địa chỉ From mà người đọc nhìn thấy. Tên miền From công bố một chính sách tại _dmarc.<domain> để cho bên nhận biết cách xử lý thư không qua được xác thực: none, quarantine hoặc reject. Thư đạt DMARC khi SPF hoặc DKIM đạt với một tên miền khớp với tên miền From.

DMARC không tự thêm cơ chế xác thực nào. Giá trị của DMARC nằm ở yêu cầu khớp tên miền và ở các báo cáo tổng hợp (rua=) mà bên nhận gửi về cho chủ sở hữu tên miền.

Khớp (aligned) nghĩa là gì?

Khớp là việc so sánh một tên miền đã xác thực với tên miền From. Chế độ khớp nới lỏng yêu cầu cùng tên miền tổ chức, vì vậy mail.example.com khớp với example.com. Chế độ khớp nghiêm ngặt yêu cầu tên máy chủ giống hệt nhau. Tên miền tổ chức được xác định từ Public Suffix List, danh sách này biết rằng các tên như example.co.uk được tính là một tên miền có thể đăng ký. Khi báo cáo ghi khớp mà không nói thêm, phép so sánh là với tên miền From.

BIMI là gì?

BIMI công bố logo thương hiệu để các nhà cung cấp hộp thư hiển thị bên cạnh thư đã xác thực. Bản ghi nằm tại default._bimi.<domain> và trỏ đến một logo SVG (l=) và, với hầu hết nhà cung cấp, một Verified Mark Certificate (a=). BIMI chỉ áp dụng cho tên miền có chính sách DMARC ở mức thực thi, tức quarantine hoặc reject ở mức 100 phần trăm. echo.email hiển thị bản ghi và cho biết chính sách DMARC có đáp ứng yêu cầu hay không.

Vì sao DNS ngược lại quan trọng?

Mỗi địa chỉ IP gửi thư cần một bản ghi PTR trỏ đến một tên máy chủ, và tên máy chủ đó cần một bản ghi A hoặc AAAA trỏ ngược về cùng địa chỉ IP. Vòng kiểm tra này được gọi là DNS ngược được xác nhận chiều xuôi, hay FCrDNS. Các nhà cung cấp hộp thư lớn coi FCrDNS là yêu cầu tối thiểu với máy chủ gửi thư, và thư từ địa chỉ IP không có bản ghi PTR thường bị từ chối ngay.

DNS ngược dạng chung (generic) là gì?

Một số bản ghi PTR theo mẫu đặt tên của nhà mạng, ví dụ 192-0-2-10.dynamic.example.net. Những tên như vậy cho thấy một kết nối gia đình hoặc một máy chủ chưa ai cấu hình để gửi thư, và bộ lọc nghi ngờ chúng. Một tên riêng thuộc tên miền của chính người gửi, ví dụ mail.example.com, cho thấy đây là máy chủ thư được cấu hình có chủ đích.

Tên HELO nào là tốt nhất?

Máy chủ gửi tự giới thiệu bằng tên HELO hoặc EHLO khi bắt đầu cuộc hội thoại SMTP. Một tên tốt thuộc về máy chủ gửi, phân giải được trong DNS và khớp với bản ghi PTR của địa chỉ IP gửi. Địa chỉ IP trần, các tên như localhost và chuỗi ngẫu nhiên là dấu hiệu điển hình của phần mềm độc hại và snowshoe spam, và bộ lọc đánh giá chúng tương ứng.

Vì sao cần kiểm tra TLS?

TLS cơ hội (opportunistic) mã hóa cuộc hội thoại SMTP khi máy chủ nhận cung cấp STARTTLS. echo.email cung cấp STARTTLS trên mọi kết nối và ghi lại phiên bản TLS và bộ mã hóa mà bên gửi chọn. Thư gửi không có TLS đi dưới dạng văn bản thuần giữa hai máy chủ, và Google cùng Yahoo coi TLS là yêu cầu đối với người gửi hàng loạt. Báo cáo cũng đếm các liên kết và hình ảnh tải qua http thường, vì những yêu cầu đó cũng không được mã hóa.

Vì sao cần kiểm tra IPv6?

Hai câu hỏi quyết định mức sẵn sàng cho IPv6. Câu hỏi thứ nhất là người gửi có gửi được đến máy chủ thư chỉ dùng IPv6 hay không. Thư đến qua IPv6 trả lời ngay là có. Thư đến qua IPv4 vẫn được tính là hỗ trợ IPv6 khi máy chủ gửi có bản ghi AAAA, DNS ngược của địa chỉ IPv6 đó trỏ đến cùng máy chủ, và SPF đạt với địa chỉ đó. Hầu hết máy chủ thư chọn IPv4 hoặc IPv6 cho từng kết nối, vì vậy thư tiếp theo từ cùng máy chủ thường đến qua IPv6. Câu hỏi thứ hai là mọi máy chủ cung cấp hình ảnh và liên kết trong thư có bản ghi AAAA hay không, để người đọc trên mạng chỉ có IPv6 hoặc sau carrier-grade NAT vẫn tải được nội dung. Báo cáo đánh dấu thư sẵn sàng cho IPv6 khi cả hai câu trả lời đều là có.

Kích thước email được đo như thế nào?

Kích thước email là số byte khi truyền đi: toàn bộ header, mọi phần MIME, tệp đính kèm và phần dữ liệu tăng thêm do mã hóa base64 hoặc quoted-printable. Gmail cắt bớt thư có hơn khoảng 102 KB HTML và ẩn phần còn lại sau một liên kết, và phần bị cắt thường chứa liên kết hủy đăng ký và pixel theo dõi.

Dung lượng hình ảnh là gì?

Dung lượng hình ảnh là tổng kích thước các hình ảnh từ xa được tham chiếu trong thẻ <img>, đo bằng cách tải mỗi hình một lần. Con số này là mức tối thiểu, vì hình ảnh từ thuộc tính srcset và nền CSS không được tính. Thư có dung lượng lớn tải chậm trên kết nối di động và tốn dữ liệu của người đọc.

Hình ảnh thừa dung lượng là gì?

Chỉ số hình ảnh thừa dung lượng ước tính số byte người gửi có thể tiết kiệm nếu mỗi hình có kích thước gần với kích thước hiển thị trong thư. Hình lớn tối đa gấp đôi kích thước hiển thị được tính là không thừa, vì màn hình mật độ cao dùng đến số pixel thêm đó. Vượt quá gấp đôi kích thước hiển thị, số pixel thêm chỉ làm tăng byte mà không thêm chi tiết. Hình nhỏ hơn 1 KB, ví dụ ảnh đệm, không được tính vào con số này.

echo.email xử lý hình ảnh như thế nào?

Quá trình phân tích tải mỗi hình ảnh từ xa một lần và ghi lại trạng thái HTTP, chuyển hướng, kích thước, loại nội dung và kích thước pixel, sau đó so sánh kích thước pixel với kích thước khai báo trong HTML. Tải hình ảnh cũng là việc ứng dụng thư làm khi người đọc mở thư, vì vậy công cụ theo dõi lượt mở sẽ ghi nhận một lượt mở. Các lượt tải đến từ mạng Cloudflare, và yêu cầu đến địa chỉ riêng hoặc nội bộ bị từ chối.

Liên kết được trích từ HTML và nhóm theo host, với tham số truy vấn được giải mã cho dễ đọc. echo.email không bao giờ mở các liên kết thông thường, vì mở một liên kết có thể xác nhận một đăng ký, kích hoạt một hành động hoặc ghi nhận một lượt nhấp. Ngoại lệ duy nhất là URL hủy đăng ký một lần nhấp được mô tả bên dưới.

List-Unsubscribe là gì?

List-Unsubscribe là một header được định nghĩa trong RFC 2369. Header này chứa một hoặc nhiều cách để rời danh sách, dưới dạng địa chỉ mailto:, URL https: hoặc cả hai. Các nhà cung cấp hộp thư dùng header này để hiển thị nút hủy đăng ký riêng bên cạnh tên người gửi. URL http thường đã lỗi thời, và https là dạng được mong đợi.

Hủy đăng ký một lần nhấp là gì?

RFC 8058 thêm một header thứ hai, List-Unsubscribe-Post, với giá trị cố định List-Unsubscribe=One-Click. Khi có cả hai header, nhà cung cấp hộp thư gửi một yêu cầu POST đến URL https và người nhận rời danh sách mà không cần mở trang web nào. Google và Yahoo yêu cầu người gửi hàng loạt hỗ trợ hủy đăng ký một lần nhấp.

echo.email gửi cùng yêu cầu POST đó và báo cáo phản hồi. Mọi trạng thái 2xx đều được tính là thành công. Yêu cầu này chỉ hủy đăng ký cho địa chỉ tạm thời của echo.email.

Hủy đăng ký không cần tương tác nghĩa là gì?

Hủy đăng ký không cần tương tác hoàn tất mà người nhận không phải mở trình duyệt hay xác nhận gì. Một lần nhấp theo RFC 8058 là cách được ưu tiên. Địa chỉ mailto: trong List-Unsubscribe cũng được tính, nhưng hủy đăng ký qua thư chậm hơn và không gửi xác nhận cho người nhận, vì vậy các nhà cung cấp coi mailto là phương án dự phòng.

Vì sao vẫn cần liên kết hủy đăng ký trong nội dung thư?

Luật tiếp thị ở hầu hết các quốc gia yêu cầu một cách rời danh sách hiển thị rõ trong thư, thường là liên kết ở chân thư. Các header phục vụ nhà cung cấp hộp thư, còn liên kết ở chân thư phục vụ người đọc. echo.email tìm một liên kết có từ ngữ về hủy đăng ký hoặc URL có dạng hủy đăng ký. Cách phát hiện này dựa trên quy tắc kinh nghiệm (heuristic) và đôi khi chọn nhầm liên kết. Một tham số theo dõi riêng trên liên kết ở chân thư giúp tách lượt hủy qua chân thư và lượt hủy qua header trong thống kê của người gửi.

List-Id là gì?

List-Id (RFC 2919) cho biết thư thuộc danh sách gửi thư nào, ví dụ News <news.example.com>. Google và Yahoo không yêu cầu header này. Bên nhận và người nhận dùng header này để sắp xếp và lọc thư theo luồng, vì vậy thêm header này là thực hành tốt.

Danh sách thực hành tốt là gì?

Danh sách này dựa trên các yêu cầu mà Google và Yahoo công bố cho người gửi hàng loạt vào năm 2024: SPF khớp, DKIM khớp, DNS ngược được xác nhận chiều xuôi (FCrDNS), TLS, tên miền From không thuộc nhà cung cấp email miễn phí và không làm DMARC thất bại, chính sách DMARC đã công bố, ít nhất một phương thức xác thực khớp, hủy đăng ký một lần nhấp và liên kết hủy đăng ký hiển thị rõ. Mỗi dòng ghi có hoặc không. Một dòng màu đỏ là nguyên nhân có thể khiến thư khó vào hộp thư đến hơn ở các nhà cung cấp lớn, và điểm tối đa là mức cơ bản cho thư hàng loạt.

Một số dòng chỉ được tính khi áp dụng. Hai dòng hủy đăng ký được tính khi thư có header thư hàng loạt: List-Unsubscribe, List-Unsubscribe-Post, List-Id, hoặc Precedence đặt là bulk, list hay junk. Thư cá nhân không có header nào trong số này sẽ bỏ qua hai dòng đó. Dòng SPF khớp không tính vào điểm khi người gửi phong bì được viết lại bằng SRS và DMARC đạt nhờ DKIM khớp. Sau khi SRS viết lại, SPF kiểm tra tên miền của máy chủ viết lại thay vì tên miền From. Các dịch vụ chuyển tiếp dùng SRS theo thiết kế, và một số máy chủ gửi áp dụng SRS cho mọi thư gửi đi, làm mất khả năng khớp SPF. Điểm số cho biết số dòng đạt trên tổng số dòng được tính.

Thư được hiển thị như thế nào?

Chế độ hiển thị cho thấy phần HTML bên trong một khung sandbox. Trình duyệt thực hiện việc hiển thị, vì vậy kết quả giống trình duyệt máy tính hơn là một ứng dụng thư hay thiết bị cụ thể. Script, biểu mẫu và liên kết bị tắt trong bản xem trước. Các chế độ xem riêng cho thấy thư khi hình ảnh bị chặn và khi văn bản alt thay cho từng hình, cũng là cách nhiều người đọc nhìn thấy thư lần đầu.

Mục MIME trong báo cáo cho thấy gì?

MIME là cấu trúc bên trong một thư: các phần, loại nội dung, bộ ký tự, cách mã hóa truyền tải và các boundary phân tách chúng. Một bản tin điển hình có vùng chứa multipart/alternative với một phần text/plain và một phần text/html. Thiếu phần văn bản thuần, thiếu boundary đóng hoặc lồng nhau bất thường sẽ dễ thấy trong cây cấu trúc.

Phần dữ liệu thư cho thấy gì?

Phần dữ liệu thư hiển thị thư gốc như khi nhận được, kèm số liệu thống kê: tổng kích thước, số dòng, dòng dài nhất, ký tự ngoài ASCII và ký tự xuống dòng đơn. RFC 5322 giới hạn mỗi dòng ở 998 ký tự, và một số máy chủ cắt hoặc từ chối dòng dài hơn. Ký tự xuống dòng đơn không có ký tự về đầu dòng (carriage return) là nguyên nhân phổ biến gây lỗi DKIM, vì các máy chủ trên đường đi sẽ viết lại chúng.

Chế độ xem thư gốc bắt đầu bằng các header dấu vết mà mx.echo.email ghi lại khi nhận thư: Return-Path, Authentication-Results, Received-SPF và Received. Bên dưới là thư đúng như khi nhận được, và liên kết tải xuống cung cấp tệp .eml nguyên vẹn.

Báo cáo kiểm tra những danh sách chặn nào?

Bên nhận tra cứu địa chỉ IP gửi và các tên miền người gửi trên danh sách chặn DNS, và việc bị liệt kê trên một danh sách phổ biến dẫn đến thư bị từ chối hoặc bị lọc. Báo cáo kiểm tra các danh sách giống với scan.mx: Spamhaus ZEN và AuthBL cho địa chỉ IP, Spamhaus DBL và ZRD cho tên miền From và tên miền phong bì, cùng SpamCop, GBUdb Truncate và PSBL cho địa chỉ IPv4. Mỗi dòng ghi có trong danh sách hoặc không có trong danh sách, kèm liên kết đến trang gỡ khỏi danh sách của đơn vị quản lý danh sách.

Mục liệt kê theo chính sách trên Spamhaus PBL đánh dấu một dải địa chỉ không dùng để gửi thư trực tiếp, ví dụ kết nối gia đình. Thư từ địa chỉ như vậy nên đi qua máy chủ thư của nhà cung cấp. Kết quả được lưu đệm trong hai giờ, vì vậy sau khi sửa, bài kiểm tra mới sẽ thấy thay đổi trong tối đa hai giờ.

Điểm SpamAssassin có ý nghĩa gì?

SpamAssassin là bộ lọc spam mã nguồn mở được nhiều máy chủ nhận sử dụng. Máy chủ thư chấm điểm từng thư kiểm tra bằng SpamAssassin và bộ quy tắc mặc định, được cập nhật hằng ngày. Báo cáo hiển thị tổng điểm, ngưỡng spam là 5 và mọi quy tắc khớp, xếp theo điểm cao nhất trước. Điểm âm có lợi cho thư, ví dụ một chữ ký DKIM hợp lệ.

Các bài kiểm tra mạng tra cứu địa chỉ IP gửi và các tên miền trong liên kết trên Spamhaus (qua DQS), URIBL, SURBL và các danh sách khác trong bộ quy tắc mặc định. Học Bayes và các mạng mã băm dùng chung Razor, Pyzor và DCC đều tắt, vì vậy điểm số chỉ phụ thuộc vào chính thư và không có gì về thư rời khỏi máy chủ để phục vụ việc học.

Điểm này chỉ để tham khảo và không tính vào điểm của mục Thực hành tốt. Mỗi bên nhận chạy bộ lọc riêng với quy tắc và ngưỡng riêng, và Gmail cùng Outlook hoàn toàn không dùng SpamAssassin. Điểm trên 0 là bình thường. Các quy tắc có nhiều điểm nhất cho thấy thay đổi nào giúp ích nhiều nhất. Thư lớn hơn 500 KB không được chấm điểm.

Vì sao tên miền người gửi cần máy chủ thư?

Thư trả lời được gửi đến tên miền From, còn thư báo lỗi được gửi đến tên miền của người gửi phong bì. Cả hai đều cần bản ghi MX, hoặc ít nhất là bản ghi địa chỉ mà máy chủ thư dùng làm phương án dự phòng. Null MX, tức một MX duy nhất trỏ đến dấu chấm (RFC 7505), tuyên bố rằng tên miền hoàn toàn không nhận thư, và một số bên nhận từ chối thư từ tên miền như vậy.

Phần tử HTML nào được coi là rủi ro?

Script, biểu mẫu, iframe, object và embed hiếm khi phù hợp với email. Hầu hết ứng dụng thư loại bỏ chúng, và bộ lọc spam coi chúng là dấu hiệu lừa đảo. Liên kết và hình ảnh thông thường làm được cùng việc mà không bị trừ điểm. Phần nội dung cũng cho thấy kích thước HTML và lượng văn bản hiển thị trong HTML, vì thư gần như chỉ toàn mã định dạng hoặc hình ảnh trông đáng ngờ với bộ lọc.

Vì sao báo cáo cảnh báo về dịch vụ rút gọn liên kết?

Các dịch vụ rút gọn công khai như bit.ly che giấu đích đến thật. Các chiến dịch lừa đảo dùng chúng rất nhiều, vì vậy bộ lọc không tin các liên kết đi qua chúng. Liên kết trỏ thẳng đến tên miền của người gửi giúp xây dựng uy tín.

Phần DNS cho thấy gì?

Mọi truy vấn DNS thực hiện cho báo cáo đều xuất hiện trong phần DNS, được nhóm theo mục đích: DNS ngược, SPF, DKIM, DMARC, BIMI, máy chủ thư và kiểm tra IPv6. Các lượt tra cứu danh sách chặn không có trong danh sách này, vì tên truy vấn của chúng chứa khóa truy cập. Mỗi mục hiển thị tên, loại bản ghi, mã phản hồi, các câu trả lời kèm TTL và mọi bản ghi authority. Danh sách cho thấy bản ghi nào tạo ra từng kết quả, điều này hữu ích khi một thay đổi DNS gần đây chưa đến được mọi resolver.

Thêm công cụ miễn phí

scan.mx
Kiểm tra cấu hình email của một tên miền: MX, SPF, DKIM, DMARC, BIMI.
portscan.com
Kiểm tra cổng TCP nào đang mở trên một địa chỉ IP, kể cả cổng 25.