RFC 5322 – Định dạng Thư Internet

Current Standard Core SMTP & Message Format Obsoletes RFC 2822 Published March 2026

ELI5: Nếu [RFC 5321](5321) (SMTP) là chiếc xe tải bưu điện chở thư của bạn, thì RFC 5322 là định dạng của chính bức thư đó — nơi bạn viết địa chỉ trả lời, địa chỉ người nhận, ngày tháng, dòng tiêu đề, và sau đó là nội dung thực tế bên dưới. Mỗi email bạn mở trong hộp thư đến của mình đều được cấu trúc theo spec này.

Tại Sao RFC Này Tồn Tại

RFC 5322 định nghĩa cú pháp của một tin nhắn email — văn bản chảy qua SMTP trong giai đoạn DATA. Tiền thân của nó, RFC 822 (1982), là một trong những tiêu chuẩn internet sớm nhất. RFC 5322 cập nhật định dạng với các quy tắc cú pháp nghiêm ngặt hơn, xử lý cú pháp lỗi thời rõ ràng hơn, và sự liên kết với các thực hành hiện đại.

RFC này hoàn toàn về định dạng tin nhắn — nó không nói gì về cách tin nhắn được truyền tải (đó là RFC 5321) hoặc cách các tệp đính kèm hoạt động (đó là RFC 2045 và gia đình MIME). Nó định nghĩa các trường tiêu đề, phần thân và các quy tắc cho địa chỉ, ngày tháng và định danh tin nhắn.

Cách Nó Hoạt Động

Một tin nhắn email được chia thành hai phần được phân tách bằng một dòng trống:

Phần tiêu đề: Một chuỗi các trường tiêu đề, mỗi trường là Tên: giá trị, kết thúc bằng CRLF.
Phần thân: Nội dung tin nhắn, đơn giản là văn bản không có cấu trúc (MIME thêm cấu trúc vào đó).

Cấu Trúc Tin Nhắn

# Phần tiêu đề From: Alice Smith <alice@example.com> To: Bob Jones <bob@example.net>, Carol White <carol@example.org> Cc: Dave <dave@example.com> Subject: Báo cáo Quý Date: Wed, 11 Mar 2026 15:30:00 -0500 Message-ID: <unique-id-12345@example.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" # Dòng trống phân tách tiêu đề từ phần thân Xin chào Bob và Carol, Vui lòng tìm báo cáo quý được đính kèm.

Các Trường Tiêu Đề Bắt Buộc

RFC 5322 yêu cầu bắt buộc rằng mỗi tin nhắn PHẢI chứa các trường này:

Trường	Mô Tả	Ví Dụ
`From:`	Tác giả của tin nhắn	`From: Alice <alice@example.com>`
`Date:`	Khi tin nhắn được soạn	`Date: Wed, 11 Mar 2026 15:30:00 -0500`

Ngoài ra, mỗi tin nhắn NÊN chứa một trường Message-ID — một định danh duy nhất trên toàn cầu. Các tin nhắn không có Message-ID gây ra các vấn đề với luồng thảo luận, khử trùng lặp và ký DKIM.

Các Trường Tiêu Đề Phổ Biến

Trường	Mục Đích
`To:`	Người nhận chính
`Cc:`	Người nhận sao chép
`Bcc:`	Sao chép mù (được xóa trước khi gửi)
`Subject:`	Chủ đề của tin nhắn
`Reply-To:`	Địa chỉ để trả lời (ghi đè From:)
`Sender:`	Người gửi thực tế khi From: chứa nhiều tác giả hoặc khác với tác nhân truyền
`In-Reply-To:`	Message-ID của tin nhắn đang được trả lời
`References:`	Chuỗi Message-ID để luồng thảo luận
`Message-ID:`	Định danh duy nhất trên toàn cầu cho tin nhắn này
`Return-Path:`	Được thêm vào bởi hệ thống phân phối cuối cùng từ MAIL FROM
`Received:`	Tiêu đề dấu vết được thêm vào bởi mỗi máy chủ xử lý tin nhắn

Các Chi Tiết Kỹ Thuật Chính

Định Dạng Địa Chỉ

RFC 5322 định nghĩa hai định dạng địa chỉ hợp lệ:

Addr-spec: alice@example.com — chỉ hộp thư.
Name-addr: Alice Smith <alice@example.com> — tên hiển thị cộng với địa chỉ trong dấu ngoặc nhọn.

Tên hiển thị chứa các ký tự đặc biệt phải được trích dẫn: "O'Brien, Alice" <alice@example.com>. Phần cục bộ (trước @) phân biệt chữ hoa chữ thường theo thông số kỹ thuật nhưng được xử lý không phân biệt chữ hoa chữ thường bởi hầu hết các hệ thống thư trong thực tế.

Định Dạng Ngày

Định dạng ngày cụ thể và không khoan dung:

Date: Thu, 11 Mar 2026 15:30:00 -0500

Định dạng là: ngày-của-tuần, DD Tháng YYYY HH:MM:SS khu-vực. Ngày của tuần là tùy chọn nhưng quy ước. Múi giờ phải là một phần bù số (-0500), không phải tên như "EST". Mặc dù thông số kỹ thuật dung thứ cú pháp lỗi thời viết tắt múi giờ, việc tạo ra chúng không được khuyến nghị.

Định Dạng Message-ID

Message-ID phải duy nhất trên toàn cầu và tuân theo mẫu:

Message-ID: <unique-part@domain>

Thực hành tốt nhất là sử dụng một UUID hoặc phần duy nhất dựa trên dấu thời gian kết hợp với miền gửi của bạn: <20260311153000.a1b2c3@mail.example.com>.

Gập Tiêu Đề

Các giá trị tiêu đề dài có thể được "gập" bằng cách chèn CRLF theo sau bởi ít nhất một khoảng trắng hoặc tab (khoảng trắng). Đây là cách các danh sách người nhận dài hoặc dòng chủ đề dài lưu trong giới hạn dòng 998 ký tự:

To: Alice <alice@example.com>, Bob <bob@example.com>, Carol <carol@example.com>

Trình phân tích cú pháp phải "mở gập" những cái này bằng cách nối các dòng trong đó phần tiếp theo bắt đầu bằng khoảng trắng.

Tiêu Đề Dấu Vết

Mỗi máy chủ thư xử lý một tin nhắn thêm trước một tiêu đề Received:. Những cái này tạo thành một đường dẫn từ trên xuống dưới — tiêu đề Received: hàng đầu được thêm vào cuối cùng. Tiêu đề Return-Path: được thêm vào chỉ bởi hệ thống phân phối cuối cùng và chứa người gửi bao gồm từ MAIL FROM.

Những Lỗi Thường Gặp

Tiêu đề Date bị thiếu hoặc có định dạng sai. Một số bộ lọc spam phạt các tin nhắn không có tiêu đề Date thích hợp hoặc có ngày tháng xa trong tương lai/quá khứ. Luôn tạo nó tại thời điểm gửi.
Message-ID bị thiếu. Không có Message-ID duy nhất, các trả lời sẽ không luồng thảo luận đúng cách, chữ ký DKIM có thể không bao gồm trường, và một số bộ lọc spam gắn cờ tin nhắn.
Địa chỉ được trích dẫn không chính xác. Tên hiển thị có dấu phẩy, dấu chấm hoặc ký tự đặc biệt phải được trích dẫn. O'Brien, Alice <alice@example.com> không hợp lệ — nó phải là "O'Brien, Alice" <alice@example.com>.
Sử dụng BCC không chính xác. Tiêu đề BCC nên bị loại bỏ trước khi truyền. Nếu bạn đưa những người nhận BCC vào tiêu đề được gửi, bạn đã phá vỡ mục đích của sao chép mù.
Vượt quá độ dài dòng. Các dòng tiêu đề và dòng thân không được vượt quá 998 ký tự. Sử dụng gập tiêu đề cho các tiêu đề dài và mã hóa MIME thích hợp cho nội dung thân dài.
Nhầm lẫn From và Sender. Tiêu đề Sender: chỉ được yêu cầu khi thực thể truyền tải thực tế khác với tác giả From:. Đừng thêm tiêu đề Sender dự phòng khớp với From — nó là không cần thiết và có thể làm nhầm lẫn các bộ lọc.
Định dạng múi giờ sai. Sử dụng EST thay vì -0500 là cú pháp lỗi thời. Luôn sử dụng phần bù số.

Tác Động Khả Năng Gửi

Ký DKIM phụ thuộc vào tiêu đề. DKIM (RFC 6376) ký các trường tiêu đề cụ thể. Các tiêu đề bị thiếu hoặc có định dạng sai có nghĩa là chữ ký có thể không bao gồm những gì bạn mong đợi, hoặc tin nhắn có thể không xác minh được.
Kiểm tra liên kết DMARC tiêu đề From. DMARC (RFC 7489) so sánh miền trong tiêu đề From: với kết quả SPF và DKIM. Tiêu đề From không khớp hoặc bị thiếu có nghĩa là thất bại DMARC tự động.
Luồng thảo luận và trải nghiệm người dùng. Các tiêu đề Message-ID, In-Reply-To và References thích hợp đảm bảo tin nhắn của bạn luồng thảo luận đúng cách trong các ứng dụng thư của người nhận. Luồng thảo luận bị hỏng làm cho tin nhắn của bạn trông không chuyên nghiệp.
Heuristic bộ lọc spam. Các bộ lọc kiểm tra tuân thủ RFC 5322. Các tiêu đề bắt buộc bị thiếu, ngày tháng có định dạng sai và định dạng không chuẩn đều là tín hiệu tiêu cực làm tăng điểm spam của bạn.
Giả mạo tên hiển thị. Các nhà cung cấp hộp thư ngày càng tăng dường như hiển thị cảnh báo khi địa chỉ From trông đáng ngờ. Sử dụng tiêu đề From sạch, nhất quán với tên hiển thị được công nhận cải thiện tỷ lệ mở và niềm tin.