Phân tích header email đã nhận: dựng lại đường đi và soi dấu hiệu giả mạo
Dán toàn bộ header của một thư đã nằm trong hộp thư, công cụ bóc chuỗi Received thành dòng thời gian có tính độ trễ từng chặng, đọc kết quả SPF, DKIM và DMARC kèm giải thích tiếng Việt cho từng trạng thái, đối chiếu From với Return-Path và Reply-To, rồi chấm một điểm rủi ro tổng hợp có nêu rõ lý do. Mọi thứ chạy trong trình duyệt, header không được gửi đi đâu.
Tính năng nổi bật
- Bóc header đã gấp dòng theo chuẩn RFC 5322, giữ nguyên thứ tự xuất hiện của từng trường
- Dựng chuỗi Received thành dòng thời gian theo đúng chiều thời gian, kèm độ trễ giữa hai chặng liền nhau
- Đọc Authentication-Results và Received-SPF, hiện trạng thái SPF, DKIM, DMARC kèm giải thích tiếng Việt cho từng mức pass, fail, softfail, neutral, none và các mức lỗi
- Đối chiếu tên miền của From với Return-Path, Reply-To và Message-ID theo tên miền đăng ký được chứ không so nguyên chuỗi
- Phát hiện tên hiển thị chứa một địa chỉ email khác với địa chỉ thật trong From
- Liệt kê mọi header X-Spam và các trường điểm số của bộ lọc thư rác nếu máy chủ có ghi lại
- Rút danh sách IP trung gian từ chuỗi Received, đánh dấu dải nội bộ và dải dành riêng để bạn khỏi tra nhầm
- Chấm điểm rủi ro tổng hợp trên thang 100 và liệt kê từng dấu hiệu đã cộng điểm cùng lý do
- Có hướng dẫn lấy header cho Gmail, Outlook trên web, Outlook cài máy và Apple Mail, kèm header mẫu để thử ngay
Vì sao phải đọc header thay vì tin vào phần thư nhìn thấy
Thứ hiện trên màn hình khi bạn mở thư là phần dễ làm giả nhất trong toàn bộ một bức thư điện tử. Tên hiển thị do người gửi tự đặt, không ai kiểm duyệt, nên viết là phòng kế toán của một ngân hàng cũng được. Địa chỉ trong From cũng chỉ là một dòng chữ trong thư, giao thức gửi thư không bắt buộc nó phải trùng với địa chỉ thật đã dùng để gửi. Trên điện thoại, phần lớn ứng dụng thư còn giấu luôn địa chỉ và chỉ hiện tên, nên khoảng cách giữa thứ bạn thấy và thứ thật sự xảy ra càng lớn. Header là nơi ghi lại dấu vết kỹ thuật của quá trình vận chuyển: máy chủ nào nhận thư từ máy chủ nào, vào lúc mấy giờ, kết quả kiểm tra xác thực ra sao, thư báo lỗi sẽ quay về đâu và thư trả lời sẽ đi đâu. Những dấu vết đó do các máy chủ trung gian ghi chứ không do người gửi viết, nên khó bịa hơn nhiều. Khi cần trả lời câu hỏi thư này có thật do bên kia gửi không, chỉ có header mới trả lời được.
Lợi ích khi sử dụng
- Trả lời được câu hỏi thư này thật sự do ai gửi, thay vì đoán theo tên hiển thị
- Hiểu ba kết quả SPF, DKIM, DMARC bằng tiếng Việt mà không cần đọc tài liệu chuẩn
- Nhìn ra ngay bẫy Reply-To trỏ sang tên miền lạ, kiểu bẫy khiến câu trả lời của bạn rơi vào tay người khác
- Có bằng chứng kỹ thuật rõ ràng để báo cho bộ phận kỹ thuật hoặc để lưu hồ sơ sự việc
- Header nhạy cảm không rời khỏi máy vì toàn bộ xử lý chạy trong trình duyệt
Cách phân tích header email
- 1Mở thư nghi ngờ rồi lấy header gốc: Gmail chọn Hiển thị bản gốc, Outlook web chọn Xem chi tiết thư, Outlook cài máy vào Tệp rồi Thuộc tính, Apple Mail chọn Nguồn thô.
- 2Chép toàn bộ phần header, tức đoạn từ dòng đầu tiên cho tới dòng trống đầu tiên, rồi dán vào ô nhập trên trang.
- 3Đọc điểm rủi ro và danh sách dấu hiệu đã cộng điểm để biết ngay chỗ nào bất thường.
- 4Mở thẻ Đường đi để xem chuỗi Received theo chiều thời gian, chú ý chặng nào giữ thư lâu bất thường.
- 5Mở thẻ Xác thực đọc ba dòng SPF, DKIM, DMARC, rồi sang thẻ Danh tính đối chiếu From với Return-Path và Reply-To.
- 6Nếu thư có liên kết, chép liên kết đó sang công cụ chấm rủi ro URL, đừng bấm trực tiếp vào nó.
Chuỗi Received đọc từ dưới lên, và vì sao thứ tự đó quan trọng
Mỗi khi một máy chủ nhận được thư, nó chèn thêm một dòng Received lên đầu phần header rồi mới chuyển tiếp. Hệ quả là trong tệp gốc, dòng nằm trên cùng là chặng mới nhất, còn dòng dưới cùng là chặng đầu tiên. Công cụ đã đảo lại thứ tự này để bạn đọc xuôi theo thời gian, chặng số một là nơi thư xuất phát. Mỗi dòng thường có bốn phần đáng chú ý: from là tên máy mà bên gửi tự khai cùng địa chỉ IP thật mà máy chủ nhận quan sát được, by là máy chủ đang ghi dòng này, with là giao thức đã dùng, và phần sau dấu chấm phẩy cuối cùng là mốc thời gian. Điểm mấu chốt khi soi thư giả mạo là mức độ tin cậy giảm dần khi đi ngược về đầu chuỗi. Những dòng do hạ tầng của bạn hoặc của nhà cung cấp thư ghi thì đáng tin, vì kẻ gửi không can thiệp được. Nhưng những dòng ở phía đầu chuỗi hoàn toàn có thể do chính máy của kẻ tấn công bịa ra để tạo cảm giác thư đã đi qua nhiều chặng uy tín. Cách phân biệt là tìm dòng đầu tiên do một máy chủ bạn tin tưởng ghi, rồi coi mọi thứ nằm trước đó là lời khai chưa kiểm chứng. Địa chỉ IP nằm trong ngoặc ở dòng đó mới là nguồn phát thật sự.
Độ trễ từng chặng nói lên điều gì và khi nào nó đánh lừa bạn
Độ trễ hiển thị trên dòng thời gian là hiệu giữa mốc thời gian của hai chặng liền nhau. Trong luồng bình thường, thư đi từ máy chủ gửi tới máy chủ nhận trong vài giây, thậm chí dưới một giây, nên chuỗi Received của một thư khỏe mạnh gần như không có khoảng nghỉ nào đáng kể. Khi thấy một chặng giữ thư vài phút hoặc vài chục phút, có mấy nguyên nhân hay gặp. Thứ nhất là máy chủ nhận đang áp dụng biện pháp làm chậm có chủ đích với những nguồn gửi lạ, buộc bên gửi phải thử lại sau, đây là cơ chế chống thư rác rất phổ biến và bản thân nó đã là một tín hiệu đáng chú ý. Thứ hai là hàng đợi của một máy chủ trung gian bị ứ, thường gặp với thư đi qua danh sách thư hoặc dịch vụ chuyển tiếp. Thứ ba là thư bị đưa vào hàng đợi kiểm tra nội dung sâu. Nhưng phải nhớ rằng mốc thời gian do chính từng máy chủ tự ghi theo đồng hồ của nó. Một máy chủ đặt sai múi giờ hoặc lệch đồng hồ vài phút sẽ tạo ra độ trễ âm hoặc độ trễ khổng lồ hoàn toàn giả. Vì vậy hãy đọc con số này như manh mối để đặt câu hỏi, không phải như phép đo chính xác, và luôn kiểm tra xem phần lệch có nhất quán trên nhiều chặng hay không.
Ba cơ chế xác thực kiểm tra ba thứ khác nhau, đọc riêng lẻ là hiểu sai
SPF kiểm tra xem địa chỉ IP đang gửi có nằm trong danh sách máy chủ mà tên miền cho phép hay không, nhưng tên miền được đối chiếu là tên miền trong Return-Path, tức địa chỉ phong bì, chứ không phải địa chỉ From mà bạn nhìn thấy. Vì vậy một thư hoàn toàn có thể đạt SPF pass mà From vẫn là tên miền giả: kẻ gửi chỉ cần dùng tên miền của chính họ ở phong bì và ghi tên miền ngân hàng ở From. DKIM thì khác, nó dùng chữ ký số: máy chủ gửi ký một số trường header cùng phần thân thư bằng khóa riêng, máy chủ nhận lấy khóa công khai từ DNS của tên miền ký để xác minh. DKIM pass chứng minh nội dung chưa bị sửa và tên miền ký thật sự đứng sau chữ ký, nhưng tên miền ký ghi ở trường header.d có thể là một tên miền bất kỳ, chẳng liên quan gì tới From. Mảnh ghép cuối cùng là DMARC, cơ chế duy nhất bắt buộc tên miền trong From phải khớp với tên miền đã qua được SPF hoặc DKIM. Vì vậy khi ba dòng mâu thuẫn, DMARC là dòng phản ánh đúng nhất câu hỏi mà bạn thật sự quan tâm. Trường hợp hay gây bối rối nhất là spf pass, dkim pass mà dmarc fail, nghĩa là cả hai cơ chế đều đúng nhưng đúng cho một tên miền khác với tên miền hiện trên màn hình.
From, Return-Path, Reply-To và Message-ID: khi lệch nhau là bình thường, khi lệch nhau là bẫy
From là địa chỉ hiện cho người đọc. Return-Path là địa chỉ nhận thông báo khi thư không gửi được, thường gọi là địa chỉ phong bì. Reply-To là địa chỉ sẽ nhận thư khi bạn bấm trả lời. Message-ID là mã định danh duy nhất do máy chủ gửi sinh ra, phần sau dấu a còng thường là tên miền của máy chủ đó. Bốn trường này lệch nhau không phải lúc nào cũng xấu. Thư quảng cáo gửi qua nền tảng gửi hàng loạt gần như luôn có Return-Path thuộc tên miền của nền tảng để họ hứng thư lỗi và tự dọn danh sách, đó là cách làm chuẩn mực. Message-ID sinh từ tên miền của nền tảng cũng vì lý do tương tự. Danh sách thư nội bộ cũng viết lại phong bì khi phát tán cho từng thành viên. Nhưng có một trường hợp gần như luôn đáng ngại: Reply-To trỏ sang một tên miền không liên quan gì tới From và cũng không phải một nền tảng gửi thư quen thuộc. Kiểu này khiến thư gốc trông đúng thương hiệu, còn câu trả lời của bạn, thường chứa thông tin nội bộ hoặc số tài khoản, lại rơi thẳng vào hộp thư của kẻ giả mạo. Kết hợp thêm tên hiển thị được đặt trùng tên một người thật trong công ty, đây chính là khuôn mẫu của các vụ lừa chuyển tiền qua thư điện tử.
Điểm rủi ro chỉ là bộ lọc nhanh, không phải kết luận
Điểm hiển thị trên trang là tổng trọng số của những dấu hiệu mà bộ luật trong công cụ nhận ra, và những trọng số đó do chúng tôi tự đặt chứ không dựa trên chuẩn của tổ chức nào. Có hai giới hạn cần nói thẳng. Thứ nhất, điểm thấp không đồng nghĩa với an toàn. Một thư gửi từ hộp thư thật của đối tác vừa bị chiếm quyền sẽ qua đủ SPF, DKIM, DMARC, chuỗi Received hoàn toàn hợp lệ, Reply-To trùng khớp, và chấm ra điểm rất thấp, trong khi nội dung bên trong là một yêu cầu đổi số tài khoản nhận tiền. Đây là kiểu tấn công gây thiệt hại nhiều nhất và header không giúp gì được. Thứ hai, điểm cao không đồng nghĩa với thư độc. Thư đi qua danh sách thư, qua dịch vụ chuyển tiếp hoặc qua bộ lọc rác của bên thứ ba thường làm hỏng chữ ký DKIM và làm lệch SPF, tạo ra một loạt dấu hiệu trông rất đáng ngờ trên một thư hoàn toàn lương thiện. Vì vậy hãy dùng điểm số như một cái chuông báo để dừng lại đọc kỹ, rồi ra quyết định dựa trên ngữ cảnh: bạn có đang chờ thư này không, yêu cầu bên trong có bất thường không, và nếu là chuyện tiền bạc thì có xác nhận lại bằng một kênh khác không. Gọi điện tới số điện thoại bạn đã biết từ trước vẫn là cách kiểm chứng đáng tin nhất.
Câu hỏi thường gặp (FAQ)
Header email là gì và nó khác gì phần nội dung thư?
Header là phần siêu dữ liệu nằm ở đầu mỗi bức thư, ghi ai gửi, gửi cho ai, đi qua những máy chủ nào, lúc mấy giờ và kết quả kiểm tra xác thực ra sao. Nội dung thư là phần bạn đọc, nằm sau dòng trống đầu tiên. Ứng dụng thư chỉ hiện vài dòng header chọn lọc, phần còn lại phải mở bản gốc mới thấy. Công cụ này chỉ đọc header, không đọc nội dung thư và không mở tệp đính kèm.
Lấy header đầy đủ trong Gmail thế nào?
Mở thư, bấm biểu tượng ba chấm dọc ở góc phải khung thư rồi chọn Hiển thị bản gốc, tiếng Anh là Show original. Một tab mới hiện ra với toàn bộ nội dung thô, trên đó có nút sao chép vào bảng nhớ tạm. Bấm nút đó rồi dán vào ô nhập trên trang. Trên ứng dụng Gmail cho điện thoại không có chức năng này, phải mở bằng trình duyệt ở chế độ máy tính.
Vì sao chuỗi Received trong tệp gốc lại đọc từ dưới lên?
Vì mỗi máy chủ chèn dòng Received mới lên trên cùng trước khi chuyển tiếp thư. Chặng cuối cùng ghi sau nên nằm trên đầu, chặng đầu tiên ghi sớm nhất nên bị đẩy xuống dưới. Công cụ đã đảo lại giúp bạn, chặng số một trong danh sách là nơi thư xuất phát và chặng cuối là hộp thư của bạn.
SPF pass rồi thì thư có phải là thật không?
Không nhất thiết. SPF chỉ đối chiếu địa chỉ IP gửi với danh sách máy chủ được phép của tên miền trong Return-Path, tức địa chỉ phong bì. Kẻ tấn công dùng tên miền của chính họ ở phong bì và ghi tên miền ngân hàng ở From vẫn đạt SPF pass. Cơ chế duy nhất buộc tên miền ở From phải khớp là DMARC, nên hãy đọc dòng DMARC trước.
DMARC fail nghĩa là chắc chắn thư giả mạo?
Là dấu hiệu nặng nhất trong ba cơ chế nhưng chưa phải bằng chứng tuyệt đối. Thư đi qua danh sách thư nội bộ hoặc dịch vụ chuyển tiếp thường bị sửa tiêu đề hoặc thêm chân thư, làm hỏng chữ ký DKIM và làm lệch SPF, kết quả là DMARC fail trên một thư hoàn toàn hợp lệ. Hãy xem chuỗi Received có đi qua chặng chuyển tiếp nào không trước khi kết luận.
Từ khóa softfail trong kết quả SPF nghĩa là gì?
Nghĩa là bản ghi SPF của tên miền kết thúc bằng dấu ngã kèm chữ all, và máy chủ gửi không nằm trong danh sách cho phép. Chủ tên miền đang nói máy chủ này có lẽ không phải của chúng tôi nhưng đừng chặn hẳn. Đây là mức trung gian, thường dùng khi tên miền chưa rà hết các nguồn gửi hợp lệ, nên cần soi thêm DKIM và DMARC để kết luận.
From và Return-Path khác tên miền có phải luôn là dấu hiệu xấu?
Không. Thư gửi qua nền tảng gửi hàng loạt gần như luôn có Return-Path thuộc tên miền của nền tảng để họ hứng thư lỗi và tự dọn danh sách, đó là cách làm chuẩn mực. Điều đáng ngại hơn nhiều là Reply-To trỏ sang một tên miền lạ, vì khi đó câu trả lời của bạn rơi vào hộp thư của người khác trong khi thư gốc trông vẫn đúng thương hiệu.
Địa chỉ IP nào trong chuỗi Received mới là nguồn gửi thật?
Là địa chỉ ghi ở dòng Received đầu tiên do một máy chủ bạn tin tưởng ghi lại, thường là máy chủ biên của nhà cung cấp thư. Mọi dòng nằm trước đó do máy của bên gửi tự khai và hoàn toàn có thể bịa. Các địa chỉ thuộc dải nội bộ như mười chấm hoặc một trăm chín hai chấm một sáu tám chỉ phản ánh mạng bên trong một tổ chức, tra vị trí của chúng không có ý nghĩa.
Không thấy header X-Spam nào thì có nghĩa thư sạch không?
Không. Các nhà cung cấp thư lớn chấm điểm thư rác bên trong hệ thống và không ghi kết quả ra header cho người nhận đọc. Chỉ máy chủ tự dựng, thường chạy SpamAssassin hoặc Rspamd, mới để lại các dòng này. Vắng dòng X-Spam chỉ nghĩa là hệ thống không công bố điểm, không nói gì về chất lượng thư.
Header của tôi dán vào có bị lưu lại ở đâu không?
Không. Toàn bộ việc bóc tách và chấm điểm chạy bằng JavaScript trong trình duyệt của bạn. Trang không gửi header lên máy chủ nào, không ghi log, không lưu vào cơ sở dữ liệu và mất sạch khi bạn đóng tab. Đây là lý do công cụ được viết theo hướng chạy tại chỗ, vì header lộ địa chỉ người nhận, tên máy chủ nội bộ và địa chỉ IP hạ tầng.
Điểm rủi ro bằng không thì thư chắc chắn an toàn chứ?
Không. Điểm không nghĩa là không dấu hiệu nào trong bộ luật bị kích hoạt, tức header trông bình thường. Thư gửi từ hộp thư thật của đối tác vừa bị chiếm quyền sẽ qua đủ ba cơ chế xác thực và chấm ra điểm rất thấp, trong khi nội dung bên trong là yêu cầu đổi số tài khoản nhận tiền. Với chuyện tiền bạc, hãy luôn xác nhận lại bằng điện thoại theo số bạn đã biết từ trước.
Thang điểm rủi ro này dựa trên chuẩn nào?
Không dựa trên chuẩn nào cả. Không tổ chức nào ban hành thang điểm chính thức cho việc đọc header, nên toàn bộ trọng số do chúng tôi tự đặt theo mức nghiêm trọng thường thấy và được gom về một hằng số duy nhất trong mã nguồn để dễ rà lại. Hãy coi điểm số như cái chuông báo để dừng lại đọc kỹ, không phải phán quyết.
Message-ID sinh từ tên miền khác với From thì sao?
Thường là bình thường. Message-ID do máy chủ gửi sinh ra, nên thư đi qua nền tảng gửi hàng loạt sẽ mang tên miền của nền tảng đó. Trường hợp đáng chú ý hơn là hoàn toàn thiếu Message-ID, vì máy chủ thư thật gần như luôn sinh trường này, còn kịch bản bắn thư hàng loạt viết vội thì hay quên.
Công cụ có đọc được thư định dạng .eml tải về không?
Tệp .eml là thư thô, phần đầu của nó chính là header. Bạn mở tệp bằng trình soạn thảo văn bản, chép đoạn từ dòng đầu tiên tới dòng trống đầu tiên rồi dán vào đây. Công cụ không nhận tệp tải lên, cũng không đọc phần thân thư nằm sau dòng trống đó, nên bạn chỉ cần chép đúng phần header.
Từ khóa liên quan
- phân tích header email
- email header analyzer
- cách xem header email gmail
- hiển thị bản gốc gmail
- đọc chuỗi received trong email
- kiểm tra email giả mạo
- email lừa đảo mạo danh ngân hàng
- spf dkim dmarc là gì
- dmarc fail nghĩa là gì
- spf softfail là gì
- authentication results header
- return path khác from
- reply to trỏ tên miền lạ
- message id trong email
- x-spam-status là gì
- tra ip gửi email
- internet headers outlook
- nguồn thô apple mail
- kiểm tra email có bị giả mạo không
- phân tích email đáng ngờ online
- công cụ đọc header email miễn phí
