Cách đọc tiêu đề đã nhận và theo dõi đường dẫn gửi email

Một email có thể đi qua máy chủ ứng dụng, bộ chuyển tiếp thư đi, dịch vụ lọc và bộ trao đổi thư của người nhận trước khi đến hộp thư đến. Mỗi máy chủ SMTP nhận thường thêm trường Received. Việc đọc các trường đó có thể giúp xác định độ trễ, xác định máy chủ đã gửi thư cho nhà cung cấp của bạn và xây dựng lịch trình gửi.

Các trường này là bằng chứng chẩn đoán, không phải là một chuỗi hành trình hoàn chỉnh. Người gửi có thể thêm các đường giả trước khi truyền, đồng hồ có thể không đồng ý và cơ sở hạ tầng riêng có thể ẩn hoặc viết lại chi tiết. Sử dụng dấu vết cùng với nhật ký nhà cung cấp, kết quả xác thực và ngữ cảnh của thư.

Bản ghi trường đã nhận là gì

RFC 5321 phần 4.4 yêu cầu máy chủ SMTP nhận tin nhắn để gửi hoặc xử lý thêm để thêm thông tin theo dõi vào trước. Một trường điển hình trông như thế này:

Received: from outbound.example.com (outbound.example.com [192.0.2.10])
        by mx.example.net with ESMTPS id ABC123
        for <[email protected]>;
        Mon, 03 Aug 2026 10:30:04 +0000

Mệnh đề chung trả lời các câu hỏi khác nhau:

• from mô tả máy chủ do bên gửi đưa ra và có thể bao gồm địa chỉ được quan sát trên kết nối mạng;
• by xác định máy chủ đã chấp nhận bước nhảy này và ghi trường;
• with mô tả biến thể vận chuyển hoặc giao thức, chẳng hạn như ESMTP hoặc SMTP được mã hóa;
• id là hàng đợi hoặc số nhận dạng giao dịch hữu ích khi quản trị viên có thể tìm kiếm nhật ký của máy chủ đó;
• for có thể xác định một người nhận phong bì, mặc dù đó là tùy chọn và có thể xóa để bảo mật;
• ngày sau dấu chấm phẩy ghi lại thời điểm máy chủ nhận chấp nhận tin nhắn, bao gồm cả phần bù múi giờ bằng số.

Không phải mọi trường đều chứa mọi mệnh đề. Cổng và hệ thống không phải SMTP có thể tạo ra các định dạng không quen thuộc. RFC 5321 yêu cầu rõ ràng các hệ thống nhận phải hoạt động mạnh mẽ với định dạng dấu vết không mong muốn thay vì từ chối thư chỉ vì đường dấu vết trông bất thường.

Đọc lộ trình từ dưới lên

Máy chủ SMTP thêm các trường Received mới lên trên các trường hiện có. Do đó bước nhận mới nhất nằm ở đầu khối tiêu đề; bước nhảy được ghi sớm nhất thường ở phía dưới.

Hãy xem xét dấu vết đơn giản hóa này:

Received: from filter.example.net by mx.recipient.example;
        Mon, 03 Aug 2026 10:30:07 +0000
Received: from outbound.sender.example by filter.example.net;
        Mon, 03 Aug 2026 10:30:04 +0000
Received: from app.internal.example by outbound.sender.example;
        Mon, 03 Aug 2026 10:29:59 +0000

Đọc nó như:

1. app.internal.example đã chuyển tin nhắn cho outbound.sender.example.
2. Máy chủ gửi đi đã chuyển nó cho filter.example.net.
3. Bộ lọc đã chuyển nó đến máy chủ mx.recipient.example của người nhận.

Không sắp xếp các trường theo dấu thời gian hiển thị của chúng. Thứ tự trường do giao thức xác định sẽ hữu ích hơn vì đồng hồ máy chủ có thể sai hoặc không đồng bộ. Chỉ chuyển đổi từng dấu thời gian thành một múi giờ khi ước tính độ trễ và giữ nguyên giá trị ban đầu trong bất kỳ bản ghi bằng chứng nào.

Tính toán độ trễ cẩn thận

Đối với mỗi cặp liền kề, hãy trừ thời gian nhận sớm hơn cho thời gian nhận sau sau khi áp dụng độ lệch số. Khoảng cách dương lớn có thể biểu thị việc xếp hàng, giới hạn tốc độ, lỗi mạng tạm thời hoặc đang xử lý ở dịch vụ tiếp theo. Nó không tự xác định được nguyên nhân.

Khoảng cách âm thường dẫn đến độ lệch đồng hồ, lỗi phân tích cú pháp hoặc trường không đáng tin cậy—không phải do du hành thời gian và không phải bằng chứng tự động về sự giả mạo. Kiểm tra xem các giá trị chênh lệch có được xử lý chính xác hay không và liệu hai dòng đó có được ghi bởi hệ thống mà bạn kiểm soát hay không.

Khi điều tra ứng dụng của riêng bạn, hãy đối chiếu dấu vết với:

• thời gian UTC mà ứng dụng yêu cầu tin nhắn;
• ID hàng đợi và nhật ký gửi của người gửi;
• trường Received đầu tiên được viết bởi cơ sở hạ tầng mà bạn tin tưởng;
• thời gian nhà cung cấp dịch vụ nhận báo cáo chấp nhận hoặc hiển thị nó;
• bất kỳ trạng thái thử lại hoặc phản hồi SMTP nào được hệ thống gửi ghi lại.

Danh sách kiểm tra email dành cho nhà phát triển giải thích cách ghi lại dòng thời gian yêu cầu đến mà không coi một quan sát hộp thư đến là toàn bộ hệ thống phân phối.

Quyết định bước nhảy nào bạn có thể tin tưởng

Trường Received trên cùng đã được thêm bởi máy chủ gần hộp thư bạn đang xem nhất. Nếu nhà cung cấp hộp thư đó đáng tin cậy thì trường này thường là điểm khởi đầu mạnh nhất: nó có thể báo cáo địa chỉ mạng mà nhà cung cấp thực sự đã chấp nhận thư từ đó.

Chỉ làm việc đi xuống khi các trường vẫn nhất quán với cơ sở hạ tầng mà bạn nhận ra. Các dòng được cho là đã tạo trước khi tin nhắn được gửi đến một nhà cung cấp đáng tin cậy có thể bị người gửi giả mạo. Thông thường, người gửi độc hại không thể viết lại các trường đã được hệ thống của người nhận thêm vào sau này, nhưng nó có thể đặt văn bản theo dõi trông có vẻ hợp lý vào thư trước khi các hệ thống đó nhìn thấy nó.

Tên máy chủ cũng yêu cầu ngữ cảnh. Tên from có thể đến từ lời chào SMTP, DNS đảo ngược hoặc cấu hình cục bộ. Một địa chỉ riêng như 10.0.0.0/8 có thể mô tả một bước nhảy nội bộ nhưng không thể truy tìm trực tiếp trên Internet công cộng. Kết quả định vị địa lý IP mang tính tương đối và không xác định danh tính hoặc vị trí thực tế của tác giả.

Các trường đã nhận không thay thế xác thực

Các trường Received mô tả các bước nhảy truyền tải. SPF, DKIM và DMARC đánh giá các bằng chứng khác nhau về ủy quyền, chữ ký và căn chỉnh tên miền. Một tuyến đường trông có vẻ bình thường có thể mang một tin nhắn độc hại và một tin nhắn được chuyển tiếp hợp pháp có thể có một tuyến đường phức tạp.

Sử dụng hướng dẫn SPF, DKIM và DMARC để diễn giải các kết quả xác thực riêng biệt. Đừng suy luận rằng địa chỉ From hiển thị đã kiểm soát mọi máy chủ trong tuyến hoặc việc chuyển tiếp quen thuộc giúp nội dung trở nên an toàn.

Sử dụng trình phân tích tiêu đề cục bộ mà không chia sẻ quá mức

Once Email bộ phân tích tiêu đề email trích xuất các bước nhảy Received, kết quả xác thực và các trường lặp lại trong trình duyệt. Chỉ dán các trường tiêu đề—không bao giờ dán mật khẩu, mã xác minh, nội dung thư hoặc tệp đính kèm. Công cụ này không liên hệ với các máy chủ được liệt kê, xác minh nhật ký của chúng hoặc chứng minh rằng trường đó là chính hãng.

Trước khi chia sẻ kết quả, hãy thay thế địa chỉ cá nhân, địa chỉ IP công cộng, ID hàng đợi và tên máy chủ nội bộ trong khi vẫn giữ nguyên thứ tự và khoảng thời gian cần thiết để tái tạo sự cố. Hướng dẫn biên tập bằng chứng thử nghiệm cung cấp mẫu báo cáo an toàn hơn.

Danh sách kiểm tra phiên dịch đáng tin cậy

Bắt đầu từ trên cùng để xác định hệ thống nhận cuối cùng, sau đó xây dựng lại đường dẫn từ dưới lên. Tin tưởng vào thứ tự trường trước đồng hồ. Bình thường hóa các múi giờ, gắn cờ các khoảng thời gian âm hoặc dài bất thường, đồng thời đánh dấu ranh giới giữa cơ sở hạ tầng đáng tin cậy và cơ sở hạ tầng do người gửi kiểm soát. Tương quan ID hàng đợi với nhật ký máy chủ được ủy quyền khi có sẵn.

Quan trọng nhất là nêu rõ giới hạn của kết luận. Một dấu vết có thể hỗ trợ “nhà cung cấp dịch vụ người nhận đã chấp nhận kết nối này từ rơle này vào thời điểm này”. Nó thường không thể chứng minh được ai đã viết tin nhắn, liệu mọi bước nhảy trước đó có phải là chính hãng hay không hoặc liệu các liên kết và tệp đính kèm của nó có an toàn hay không.