MTA-STS — Bảo mật Vận chuyển Thư Nghiêm ngặt của Tác nhân Truyền tải Thư

Standards Track Transport Security Published March 2026

ELI5: Hãy tưởng tượng gửi một lá thư qua hộp thư khóa, nhưng ai đó có thể thay thế khóa bằng một khóa giả và đọc thư của bạn. MTA-STS giống như công bố một biển báo nói "Tôi luôn sử dụng khóa thật — nếu khóa trông sai, đừng giao." Nó ngăn chặn những kẻ tấn công lừa các máy chủ thư gửi email mà không mã hóa.

Tại Sao Nó Tồn Tại

SMTP được thiết kế trong thời đại khi email đi qua dạng cleartext. STARTTLS (RFC 3207) đã thêm mã hóa tùy chọn, nhưng nó có một lỗi tồn tại lâu dài: nó là opportunistic. Một máy chủ gửi hỏi "bạn có hỗ trợ TLS không?" và một kẻ tấn công mạng hoạt động có thể đơn giản xóa phản hồi đó, buộc một quá trình hạ cấp plaintext. Máy chủ gửi không có cách nào để biết sự khác biệt giữa "máy chủ này không hỗ trợ TLS" và "một kẻ tấn công đã loại bỏ lời đề nghị TLS."

MTA-STS giải quyết vấn đề này bằng cách cho phép chủ sở hữu tên miền xuất bản một chính sách — qua HTTPS, không phải DNS — tuyên bố: "Các máy chủ thư của tôi luôn hỗ trợ TLS với chứng chỉ hợp lệ. Nếu bạn không thể thiết lập kết nối an toàn, từ chối gửi." Vì chính sách được lấy qua HTTPS (có chuỗi tin tưởng chứng chỉ riêng của nó), một kẻ tấn công hoạt động không thể giả mạo hoặc triệt tiêu nó.

Nó Hoạt Động Như Thế Nào

MTA-STS yêu cầu hai điều từ tên miền nhận:

Một bản ghi DNS TXT tại _mta-sts.example.com tín hiệu chính sách tồn tại và bao gồm một mã định danh phiên bản để busting bộ nhớ cache.
Một tệp chính sách phục vụ HTTPS tại https://mta-sts.example.com/.well-known/mta-sts.txt tuyên bố chính sách thực tế.

Bước 1: Bản Ghi DNS

Xuất bản một bản ghi TXT để quảng bá chính sách MTA-STS của bạn:

_mta-sts.example.com. IN TXT "v=STSv1; id=20240101T000000Z"

Trường id là một chuỗi opaque. Các máy chủ gửi lưu bộ nhớ cache chính sách và tải lại nó khi id thay đổi. Sử dụng một dấu thời gian hoặc bộ đếm tăng dần.

Bước 2: Tệp Chính Sách

Lưu trữ chính sách tại https://mta-sts.example.com/.well-known/mta-sts.txt. Chứng chỉ HTTPS phải hợp lệ cho mta-sts.example.com.

version: STSv1
mode: enforce
mx: mail.example.com
mx: backup.example.com
mx: *.example.net
max_age: 604800

Các Trường Chính Sách

Trường	Mô Tả
`version`	Phải là `STSv1`.
`mode`	`enforce` (từ chối khi thất bại), `testing` (gửi nhưng báo cáo), hoặc `none` (vô hiệu hóa).
`mx`	Tên máy chủ MX được phép. Ký tự đại diện được cho phép cho nhãn leftmost chỉ (ví dụ: `*.example.com`).
`max_age`	Bao lâu (tính bằng giây) người gửi nên lưu trữ chính sách này. Được khuyến nghị: 604800 (1 tuần) hoặc cao hơn.

Máy Chủ Gửi Làm Gì

Tìm kiếm bản ghi MX cho tên miền người nhận.
Kiểm tra xem có chính sách MTA-STS được lưu bộ nhớ cache, hoặc tải một chính sách nếu bản ghi DNS _mta-sts TXT là mới hoặc đã thay đổi.
Kết nối đến máy chủ MX và bắt đầu STARTTLS.
Xác thực chứng chỉ TLS của máy chủ MX so với các mẫu mx trong chính sách.
Nếu chế độ là enforce và TLS thất bại hoặc chứng chỉ không khớp: không gửi. Xếp hàng đợi thư và thử lại sau.

Chi Tiết Kỹ Thuật Chính

Tại Sao HTTPS Thay Vì DNSSEC?

Triển khai DNSSEC vẫn còn hạn chế. HTTPS tận dụng Web PKI được triển khai rộng rãi (cơ sở hạ tầng Tổ chức cấp chứng chỉ). Bất kỳ tên miền nào có thể nhận được chứng chỉ web đều có thể sử dụng MTA-STS — không cần DNSSEC. Đây là sự khác biệt chính giữa MTA-STS và DANE (RFC 7672), yêu cầu DNSSEC.

Tin Tưởng Lần Đầu Sử Dụng (TOFU)

MTA-STS theo mô hình TOFU. Lần đầu tiên một người gửi gặp phải chính sách của bạn, nó phải tin tưởng vào các phản hồi DNS và HTTPS. Sau đó, chính sách được lưu bộ nhớ cache bảo vệ chống lại các quá trình hạ cấp cho đến khi max_age hết hạn. Một kẻ tấn công sẽ cần phải xâm phạm cả HTTPS và DNS đồng thời trong khi tải lần đầu — một cuộc tấn công khó hơn đáng kể.

Chế Độ Thử Nghiệm

Bắt đầu với mode: testing. Trong chế độ này, các máy chủ gửi gửi thư ngay cả khi xác thực TLS thất bại, nhưng tạo ra các báo cáo TLS-RPT (RFC 8460) để bạn có thể xác định các vấn đề trước khi chuyển sang enforce.

Ví Dụ Triển Khai

Một thiết lập MTA-STS hoàn chỉnh cho example.com:

Bản Ghi DNS

; Tín hiệu chính sách MTA-STS _mta-sts.example.com. 300 IN TXT "v=STSv1; id=2024061501" ; Điểm cuối báo cáo TLS (RFC 8460) _smtp._tls.example.com. 300 IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com" ; Bản ghi MX (phải khớp với dòng mx của chính sách) example.com. 300 IN MX 10 mail.example.com. example.com. 300 IN MX 20 backup.example.com.

Tệp Chính Sách

# Phục vụ tại https://mta-sts.example.com/.well-known/mta-sts.txt
version: STSv1
mode: testing
mx: mail.example.com
mx: backup.example.com
max_age: 86400

Khi các báo cáo TLS-RPT xác nhận không có vấn đề, hãy thay đổi mode thành enforce và tăng max_age lên 604800 hoặc cao hơn.

Những Sai Lầm Thường Gặp

Không khớp chứng chỉ. Tên máy chủ MX trong chính sách của bạn phải khớp với chứng chỉ TLS trên máy chủ đó. Nếu MX của bạn là mail.example.com nhưng chứng chỉ là cho *.mailprovider.com, việc thực thi sẽ gây ra lỗi gửi.
Quên cập nhật id DNS. Các máy chủ gửi lưu bộ nhớ cache chính sách được khóa bằng id. Nếu bạn thay đổi tệp chính sách nhưng không thay đổi id, người gửi sẽ không tải lại cho đến khi max_age hết hạn.
Chứng chỉ HTTPS không hợp lệ trên mta-sts.example.com. Trang web lưu trữ chính sách phải có chứng chỉ hợp lệ, được tin tưởng công khai. Các chứng chỉ tự ký hoặc hết hạn sẽ khiến người gửi bỏ qua chính sách.
Nhảy thẳng đến enforce. Luôn bắt đầu với testing và giám sát báo cáo TLS-RPT trong ít nhất hai tuần. Các máy chủ MX được cấu hình sai sẽ âm thầm mất thư ở chế độ enforce.
max_age ngắn ở chế độ enforce. Một TTL ngắn có nghĩa là người gửi tải lại thường xuyên, mở rộng cửa sổ TOFU. Sử dụng ít nhất 604800 giây (1 tuần) trong sản xuất.
Sử dụng ký tự đại diện MX sai cách. mx: * không hợp lệ. Ký tự đại diện áp dụng cho nhãn DNS leftmost chỉ: mx: *.example.com khớp với a.example.com nhưng không phải a.b.example.com.

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

MTA-STS không trực tiếp cải thiện việc đặt vào hộp thư — nó bảo vệ thư của người nhận của bạn khỏi bị đánh chặn. Tuy nhiên, nó có những lợi ích khả năng gửi gián tiếp:

Xây dựng lòng tin tên miền. Google, Microsoft và Yahoo đều hỗ trợ MTA-STS. Xuất bản một chính sách cho thấy bạn coi trọng bảo mật và vận hành một tên miền được bảo trì tốt.
Cần thiết để tuân thủ. Các ngành xử lý dữ liệu nhạy cảm (tài chính, chăm sóc sức khỏe) ngày càng yêu cầu thực thi TLS cho email. MTA-STS là cơ chế tiêu chuẩn.
Ngăn chặn quá trình hạ cấp âm thầm. Nếu không có MTA-STS, một kẻ tấn công trên đường đi mạng có thể xóa STARTTLS và đánh chặn thư mà không bên nào biết. Đây là một cuộc tấn công được ghi lại trong thế giới thực.
Ghép với TLS-RPT. Báo cáo RFC 8460 cung cấp cho bạn khả năng hiển thị các lỗi TLS trên tất cả người gửi — vô giá để chẩn đoán các vấn đề chứng chỉ hoặc cấu hình trước khi chúng ảnh hưởng đến gửi.