Tiêu đề email: cách đọc, và nó chứng minh được gì

Khối tiêu đề thực sự là gì

Mỗi thư đều gồm hai phần cách nhau bởi một dòng trống: một khối các dòng dạng Tên: giá trị, và phần văn bản bạn đọc. RFC 5322 gọi phần đầu là tiêu đề (header) và mỗi dòng trong đó là một trường, và nó không đặt giới hạn nào về số lượng trường có thể có. Ứng dụng thư của bạn chỉ hiện ra bốn hoặc năm trường. Một thư đã đi qua ba máy chủ thường mang theo từ ba mươi đến sáu mươi trường.

Return-Path: <bounces+2841@mail.example.com>
Delivered-To: signup-2026@example.org
Received: by mx.example.org (Postfix) with LMTP id 4c8f21
        for <signup-2026@example.org>; Fri, 5 Sep 2026 09:14:22 +0000 (UTC)
Received: from out-17.mail.example.com (out-17.mail.example.com [198.51.100.17])
        by mx.example.org (Postfix) with ESMTPS id 9a31b0
        for <signup-2026@example.org>; Fri, 5 Sep 2026 09:14:21 +0000 (UTC)
Authentication-Results: mx.example.org;
        spf=pass smtp.mailfrom=mail.example.com;
        dkim=pass header.d=example.com;
        dmarc=pass header.from=example.com
From: "Example Support" <support@example.com>
To: signup-2026@example.org
Subject: Confirm your email address
Date: Fri, 5 Sep 2026 09:14:19 +0000
Message-ID: <20260905091419.9a31b0@mail.example.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="b1_4c8f21"

Đọc từ trên xuống, nó trông như nhiễu do máy tạo ra, và phần lớn đúng là vậy. Bốn trường mang gần như toàn bộ thông tin, và đó chính là bốn trường mà hướng dẫn này nói đến: Received, From, Return-Path và Authentication-Results.

Tiêu đề đầy đủ đang ẩn ở đâu

Không điều gì dưới đây cần đến một công cụ, một tiện ích mở rộng hay một tài khoản. Mọi ứng dụng thư đều giữ thư ở dạng thô đằng sau một mục trong menu, và từ cần tìm luôn là một biến thể nào đó của nguồn, bản gốc hoặc thô.

Những đường dẫn menu đó là vị trí của chúng vào ngày 5 tháng 9 năm 2026, và chúng thường dịch chuyển khoảng một lần mỗi năm — đó là lý do vì sao câu ở trên quan trọng hơn cả cái bảng: dù mùa này mục đó được gọi là gì, nó cũng sẽ chứa nguồn, bản gốc hoặc thô trong tên gọi.

Chuỗi Received, đọc từ dưới lên

Mỗi máy chủ chấp nhận thư đều viết một dòng Received: và đặt nó lên trên cùng của khối, phía trên mọi thứ đã có sẵn ở đó. Chỉ riêng thói quen đó tạo ra sự thật hữu ích nhất có thể có về tiêu đề: chặng cuối cùng là dòng đầu tiên bạn nhìn thấy, và hành trình của thư được viết lại theo chiều ngược.

Received: by mx.example.org (Postfix) with LMTP id 4c8f21
        for <signup-2026@example.org>; Fri, 5 Sep 2026 09:14:22 +0000 (UTC)
Received: from out-17.mail.example.com (out-17.mail.example.com [198.51.100.17])
        by mx.example.org (Postfix) with ESMTPS id 9a31b0
        for <signup-2026@example.org>; Fri, 5 Sep 2026 09:14:21 +0000 (UTC)
Received: from app-3.internal (app-3.internal [192.0.2.53])
        by out-17.mail.example.com (Postfix) with ESMTP id 771c4e
        for <signup-2026@example.org>; Fri, 5 Sep 2026 09:11:58 +0000 (UTC)

Mỗi dòng đều được dựng từ cùng một nhúm từ, và một khi bạn gọi tên được chúng, chuỗi đó thôi không còn là hình nền vô nghĩa nữa.

from

Tên mà máy kết nối tự xưng là gì, theo sau, trong ngoặc đơn, là nó thực sự là gì — tên DNS ngược và địa chỉ IP mà máy chủ nhận đã thấy trên kết nối đó. Cái tên đứng trước ngoặc đơn là một lời tự nhận. Địa chỉ bên trong ngoặc đơn là điều đã được quan sát trực tiếp.

by

Máy chủ đã viết ra dòng này. Đó là bên duy nhất trong dòng mà bạn có thể quy trách nhiệm cho bất cứ điều gì trong đó.

with

Chặng đó được thực hiện bằng cách nào: ESMTP, ESMTPS khi kết nối được mã hóa, LMTP cho bước bàn giao cuối cùng vào một hộp thư. Một chặng ghi ESMTP mà không có S đã truyền thư ở dạng không mã hóa.

for

Người nhận trong envelope ở chặng đó — thư thực sự được gửi đến địa chỉ nào trong số các địa chỉ của bạn, trước khi bất kỳ quy tắc chuyển tiếp nào viết lại bất cứ điều gì. Trên một tên miền catch-all hoặc với một thẻ cộng, đây là trường nêu tên chính địa chỉ đã bị lộ.

dấu thời gian ở cuối dòng

Thời điểm máy chủ đó hoàn tất việc nhận thư. Lấy thời gian của một dòng trừ đi thời gian của dòng phía trên nó, bạn sẽ có độ trễ tại chặng đó — đây là cách để biết chính xác một thư chậm đã bị kẹt ở đâu, thay vì phải đoán mò.

Trong ví dụ ở trên, thư rời khỏi ứng dụng lúc 09:11:58 và đến được máy chủ gửi đi của nhà cung cấp hai phút hai mươi ba giây sau đó; hai chặng tiếp theo sau đó chỉ mất một giây giữa chúng với nhau. Một thư đến trễ một tiếng gần như luôn có một dòng chứa nguyên một tiếng đồng hồ ở bên trong, và đó hiếm khi là dòng cuối cùng.

Bốn trường đều tự nhận là người gửi

“Ai đã gửi cái này” có bốn câu trả lời trong một tiêu đề, và chúng được phép không khớp nhau. Phần lớn thời gian, chúng không khớp vì những lý do rất tầm thường — một danh sách gửi thư, một nền tảng marketing, một quy tắc chuyển tiếp chính bạn đã thiết lập. Một sự không khớp không chứng minh được điều gì. Biết bạn đang nhìn vào trường nào trong bốn trường ấy thì có.

From:

Địa chỉ mà người gửi muốn hiển thị, cộng với một tên hiển thị vốn là văn bản tự do. Không có gì xác minh một trong hai điều đó cả. Đây là trường mà ứng dụng thư của bạn đặt vào danh sách thư, và trên điện thoại, địa chỉ thường bị giấu hoàn toàn phía sau cái tên.

Return-Path:

Người gửi trong envelope, được máy chủ đã chấp nhận thư ghi vào tiêu đề, dựa trên những gì thực sự đã được nói ra trong phiên trao đổi SMTP. Đây là nơi một thư bị trả lại (bounce) sẽ đi đến, và đây cũng là địa chỉ mà SPF dùng để kiểm tra — chính vì vậy mà một thư có thể vượt qua SPF trong khi mang một From: chẳng liên quan gì đến nó.

Reply-To:

Nơi thư trả lời của bạn sẽ được gửi đến, và nơi đó không nhất thiết phải là nơi thư đã xuất phát. Những người gửi bình thường dùng trường này cho các bộ phận hỗ trợ và các địa chỉ no-reply. Đây cũng là chiêu trò lâu đời nhất trong nghề, vì một người đọc cẩn thận kiểm tra người gửi, thấy ổn, rồi nhấn Trả lời.

Delivered-To: và X-Original-To:

Địa chỉ nào trong số các địa chỉ của bạn đã được dùng. Trên một tên miền catch-all hoặc với một thẻ cộng, đây là trường nêu tên chính địa chỉ bạn đã đưa ra — địa chỉ giúp xác định ai là bên đã để lộ nó.

From: "Example Support <support@example.com>" <billing@example.net>
         ^-- the display name, which is free text and is all a phone shows
                                              ^-- the address, which is not

Tên hiển thị là văn bản tùy ý, nên nó có thể chứa trọn vẹn một địa chỉ thuộc về người khác. Mọi ứng dụng thư trên thế giới đều hiển thị phần trong dấu ngoặc kép và giấu đi phần trong dấu ngoặc nhọn, và đó chính là toàn bộ đòn tấn công: viết ra nó không tốn gì cả, và nó có tác dụng đúng vào trường duy nhất mà một người đọc chắc chắn sẽ nhìn vào.

SPF, DKIM và DMARC, trong một dòng

Có một trường khác hẳn mọi trường còn lại trong khối tiêu đề. Authentication-Results: do chính máy chủ đã chấp nhận thư viết ra — máy chủ của bạn — và bất cứ thứ gì đến với cùng tên trường đó đều bị loại bỏ hoặc đổi tên trước khi bạn nhìn thấy nó. Đó là dòng duy nhất trong một tiêu đề mà một kẻ mạo danh không thể viết ra được.

Authentication-Results: mx.example.org;
        spf=pass (sender IP is 198.51.100.17) smtp.mailfrom=mail.example.com;
        dkim=pass header.d=example.com header.s=s1 header.b=Qk3vR2mA;
        dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com

Ba lượt kiểm tra nằm trong dòng đó, và chúng trả lời ba câu hỏi khác nhau. Cột thứ tư mới là cột đáng đọc đến hai lần.

Cột cuối cùng đó chính là toàn bộ trọng tâm, và đó cũng là chỗ hầu hết việc đọc tiêu đề đi sai hướng. dmarc=pass chứng minh rằng tên miền in trong From: đã cho phép thư này. Nó không nói gì hết về việc tên miền đó có xứng đáng nhận được gì từ bạn hay không — và tự mình công bố các bản ghi đó chỉ mất khoảng mười phút, với bất kỳ ai.

Năm điều một tiêu đề không thể cho bạn biết

• Người gửi đang ở đâu. Địa chỉ của chiếc máy mà ai đó đã soạn thư trên đó thường không hề có trong khối tiêu đề. Các nhà cung cấp webmail lớn đã ngừng công bố nó từ nhiều năm trước, và thứ còn lại chỉ là máy chủ gửi đi của riêng họ, vốn đặt trong một trung tâm dữ liệu và chỉ cho bạn biết tên của một công ty hosting.
• Người gửi là ai. Một tên miền không phải là một con người. dmarc=pass cho một tên miền vừa được mua bốn mươi phút trước vẫn là một kết quả pass hoàn toàn xác thực.
• Liệu có điều gì trong đó là thật hay không. Xác thực chỉ nói về envelope, chứ không bao giờ nói về nội dung lời tự nhận bên trong nó. Một hóa đơn hoàn toàn có thể được ký đúng, căn chỉnh đúng, và hoàn toàn là bịa đặt.
• Liệu có ai đã đọc thư hay chưa. Không có gì trong một tiêu đề ghi lại điều đó cả. Thứ cố gắng làm việc đó là một pixel theo dõi trong nội dung thư, một cơ chế hoàn toàn khác với những cách phòng vệ khác.
• Thư được viết lúc nào. Date: lấy từ chính máy của người gửi và chính đồng hồ của người gửi. Một thư mang dấu thời gian vượt trước hiện tại ba tiếng đồng hồ hầu như luôn chỉ là một chiếc máy tính cấu hình sai, hiếm khi là điều gì thú vị hơn thế; những dấu thời gian bạn có thể tin cậy là những dấu nằm trong các dòng Received mà nhà cung cấp của bạn đã viết ra.

Và có nguyên một họ trường vốn dĩ không chứng minh được gì cả, ngay từ cách chúng được thiết kế. Bất cứ thứ gì bắt đầu bằng X- là một phần mở rộng riêng do bất kỳ ai viết ra nó tự nghĩ ra, và người gửi có thể viết bất cứ điều gì họ muốn: X-Spam-Status: No trong một thư chỉ có nghĩa là thư đó tự khai là nó không phải thư rác.

Khi thư đến một địa chỉ dùng một lần

Cần rõ ràng về việc dịch vụ này trả lại những gì và không trả lại những gì. Một thư đọc ở đây đến dưới dạng đã được phân tích thành từng trường, chứ không phải ở dạng thô: người gửi, chủ đề, ngày gửi, text, HTML và danh sách tệp đính kèm — những trường mà một đoạn script cần đến — chứ không phải khối tiêu đề. Cách đọc ở trên là việc bạn làm trong hộp thư vẫn giữ thư thật của mình.

{
  "id":           "m_7Kq2fV3xTn",
  "from":         "support@example.com",
  "from_name":    "Example Support",
  "to":           "signup-2026@grabmail.io",
  "subject":      "Confirm your email address",
  "date":         "2026-09-05T09:14:22+00:00",
  "expires_at":   "2026-09-10T09:14:22+00:00",
  "text":         "Confirm your address: <https://example.com/confirm/9a31b0>",
  "text_derived": true,
  "html":         "<!doctype html><html>…",
  "attachments":  []
}

Điều một địa chỉ dùng một lần mang lại cho bạn thay vào đó là một tín hiệu mà không trường tiêu đề nào sánh được, và nó có tác dụng ngay cả trước khi bạn đọc một dòng nào: bạn chỉ đưa địa chỉ đó cho đúng một bên duy nhất. Một thư đến địa chỉ đó và tự nhận là đến từ ai khác thì hoặc đã được bên bạn đưa địa chỉ cho chuyển tiếp lại, hoặc do bất kỳ ai mà bên đó đã chuyển giao nó cho gửi đến. Không có cách giải thích thứ ba nào cả, và cũng không có gì cần phải xác minh.

Đó cũng chính là lập luận mà một thẻ cộng đưa ra, chỉ trừ đi phần mà cái thẻ có thể bị cắt bỏ chỉ trong một dòng code — ở đây, bản thân địa chỉ đã khác đi rồi, nên chẳng có gì để cắt bỏ cả. Đó cũng là lý do vì sao một catch-all trên một tên miền bạn sở hữu là phiên bản mạnh nhất của ý tưởng này: mỗi lượt đăng ký một địa chỉ, được giữ nguyên chừng nào bạn còn giữ tên miền, và Delivered-To: trong hộp thư của chính bạn nêu tên chính địa chỉ đã bị lộ.

Điều bạn vẫn có thể kiểm tra được

Hãy nhìn vào nơi liên kết dẫn tới, không phải vào những gì nó nói. Trường text hoặc là phần văn bản thuần do chính người gửi soạn, hoặc là bản dựng lại từ HTML — text_derived cho biết đó là trường hợp nào — và bản dựng đó giữ nguyên mọi địa chỉ đích của liên kết trong dấu ngoặc nhọn. Vậy nên địa chỉ mà một nút bấm lẽ ra sẽ đưa bạn đến đang nằm sẵn trong phản hồi, lộ thiên, mà không cần tải trang, hình ảnh, hay pixel theo dõi đó.

Confirm your address: <https://example.com/confirm/9a31b0>

Not you? Ignore this message. <https://example.com/help>

Phiên bản sáu mươi giây

1. Mở nguồn thư. Hiển thị bản gốc, View message source hoặc Raw source, tùy vào ứng dụng thư bạn đang dùng.
2. Trước tiên, hãy tìm Authentication-Results. Một dòng duy nhất, do chính nhà cung cấp của bạn viết ra, và là dòng duy nhất không ai khác có thể ngụy tạo được. dmarc=pass nghĩa là tên miền trong From: thực sự đã cho phép thư này; dmarc=fail nghĩa là không.
3. So sánh From: với Return-Path: và Reply-To:. Suốt ngày chúng không khớp nhau vì những lý do tầm thường. Nhưng chúng cũng không khớp nhau vì lý do đáng chú ý kia.
4. Đọc các dòng Received từ dưới lên, và ngừng tin chúng ngay tại máy đầu tiên không thuộc về nhà cung cấp của bạn.
5. Sau đó hãy xem các liên kết trỏ đến đâu, đây mới là phần quyết định điều thực sự xảy đến với bạn.

Tất cả những điều ở trên chỉ trả lời một câu hỏi hẹp: tên miền trong From: có cho phép thư này hay không? Đó là một câu hỏi nhỏ hơn nhiều so với “thư này có an toàn không”, nhưng vẫn đáng để trả lời — vì đó là câu duy nhất mà một tiêu đề có thể trả lời được.

Câu hỏi