MTA-STS là gì? Bắt buộc mã hoá email khi truyền

MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) là chuẩn cho phép tên miền của bạn tuyên bố với các máy chủ thư khác: "chỉ giao thư cho tôi qua TLS, tới đúng các máy chủ MX này, với chứng chỉ hợp lệ". Bạn chỉ cần một bản ghi TXT và một tệp chính sách nhỏ phục vụ qua HTTPS. Máy chủ gửi có hỗ trợ MTA-STS sẽ không chịu lùi về kết nối không mã hoá hay bị giả mạo.

MTA-STS giải quyết vấn đề gì

Thư giữa các máy chủ đi qua giao thức SMTP. Lúc SMTP ra đời, nó không có mã hoá. Về sau người ta thêm lệnh STARTTLS: máy gửi hỏi "bạn có hỗ trợ TLS không?" và nâng cấp kết nối nếu câu trả lời là có.

Vấn đề là STARTTLS chỉ mang tính tuỳ cơ (opportunistic). Nếu bên kia không trả lời "có", hoặc bắt tay TLS thất bại, phần lớn máy chủ vẫn gửi thư dạng văn bản thường. Chúng cũng thường không kiểm tra chứng chỉ có đúng tên máy chủ hay không. Kẻ gian đứng giữa đường truyền vì thế có hai cách tấn công:

• Hạ cấp (bóc STARTTLS): xoá dòng "tôi hỗ trợ TLS" khỏi cuộc hội thoại để thư đi không mã hoá.
• Giả MX: can thiệp vào câu trả lời DNS để thư chạy tới máy chủ của kẻ gian, với chứng chỉ bất kỳ.

MTA-STS bịt cả hai lỗ hổng này cho thư gửi tới tên miền của bạn. Máy chủ gửi biết qua kênh HTTPS đã xác thực rằng tên miền yêu cầu TLS, với chứng chỉ khớp một trong các MX đã liệt kê.

MTA-STS hoạt động thế nào

1. Một máy chủ cần gửi thư tới hoa@congty.vn.
2. Nó tra bản ghi TXT _mta-sts.congty.vn và thấy một giá trị id.
3. Nó tải chính sách qua HTTPS tại https://mta-sts.congty.vn/.well-known/mta-sts.txt. Chứng chỉ của trang web phải hợp lệ, nên chính sách rất khó bị làm giả.
4. Chính sách liệt kê các MX được phép và chế độ hoạt động. Máy gửi lưu đệm chính sách trong max_age giây.
5. Ở chế độ enforce, máy gửi chỉ giao thư khi kết nối được TLS với chứng chỉ hợp lệ tới một MX khớp chính sách. Nếu không, thư nằm lại trong hàng đợi để thử lại, không bao giờ lùi về văn bản thường.

Mỗi khi bạn sửa chính sách, hãy đổi giá trị id để máy gửi biết cần tải lại.

Các bản ghi cần tạo

Ví dụ cho tên miền congty.vn. Bản ghi TXT:

_mta-sts.congty.vn.   TXT   "v=STSv1; id=20261008T120000"

Tệp chính sách tại https://mta-sts.congty.vn/.well-known/mta-sts.txt:

version: STSv1
mode: enforce
mx: mx.nhacungcap-vidu.com
max_age: 604800

Bản ghi báo cáo TLS (TLS-RPT, RFC 8460):

_smtp._tls.congty.vn. TXT   "v=TLSRPTv1; rua=mailto:baocao-tls@congty.vn"

Những lỗi hay gặp:

• mta-sts.congty.vn phải có chứng chỉ HTTPS hợp lệ. Thiếu chứng chỉ thì chính sách bị bỏ qua.
• Mọi MX bạn thật sự dùng phải khớp một dòng mx:. Được phép dùng ký tự đại diện như *.nhacungcap-vidu.com.
• Khi đổi MX, hãy sửa chính sách và id trước khi chuyển.

Ba chế độ và lộ trình triển khai

Lộ trình gợi ý:

1. Khai báo bản ghi TLS-RPT trước để có báo cáo ngay từ đầu.
2. Tạo tên miền phụ mta-sts, cài chứng chỉ HTTPS, đặt tệp chính sách ở chế độ testing với max_age ngắn (ví dụ một ngày).
3. Khai báo bản ghi _mta-sts với một id mới.
4. Đọc báo cáo trong vài tuần: lỗi chứng chỉ, sai tên máy chủ, MX bị quên.
5. Chuyển sang enforce, tăng max_age (một đến vài tuần là phổ biến) và đổi id.

TLS-RPT: vì sao cần báo cáo

TLS-RPT cho bạn biết khi máy gửi không thiết lập được kết nối an toàn tới máy chủ của bạn, ví dụ vì chứng chỉ hết hạn, sai tên máy chủ hoặc MX chưa có trong chính sách. Các nhà cung cấp hộp thư lớn gửi báo cáo JSON hằng ngày tới địa chỉ trong rua. Không có TLS-RPT, một chính sách enforce bị sai có thể âm thầm làm chậm thư đến mà bạn không hay biết.

So sánh MTA-STS và DANE

DANE cho SMTP (RFC 7672) giải cùng bài toán theo cách khác: khai báo thông tin chứng chỉ trong DNS bằng bản ghi TLSA, được DNSSEC bảo vệ.

Hai chuẩn này không loại trừ nhau, và nhiều đơn vị dùng cả hai. MTA-STS dễ triển khai hơn nếu nhà cung cấp DNS của bạn không hỗ trợ DNSSEC.

Những gì MTA-STS không làm

• Nó bảo vệ đường truyền giữa các máy chủ cho thư gửi tới tên miền của bạn. Nó không mã hoá thư khi lưu trữ, và không phải mã hoá đầu cuối.
• Nó chỉ có tác dụng với máy gửi có hỗ trợ. Phần lớn nhà cung cấp lớn đã hỗ trợ, nhưng không phải mọi máy chủ.
• Thư bạn gửi đi được bảo vệ bởi MTA-STS hoặc DANE của bên nhận, nếu nhà cung cấp của bạn tôn trọng chúng.

Để thấy bức tranh đầy đủ, hãy đọc bảo mật email doanh nghiệp. Vì MTA-STS liệt kê MX, bạn cũng nên xem bản ghi MX là gì.

Zomail xử lý MTA-STS thế nào

Trang DNS có hướng dẫn của Zomail có sẵn MTA-STS và TLS-RPT bên cạnh MX, SPF, DKIM, DMARC, và kiểm tra từng bản ghi để bạn biết còn thiếu gì. Tên miền vẫn ở nhà đăng ký của bạn. Bạn có thể thêm bản ghi bằng tay, tải tệp zone để nhập vào Cloudflare, hoặc dùng Domain Connect thiết lập một cú bấm nếu nhà cung cấp DNS hỗ trợ. Xem hướng dẫn bắt đầu.

Ngoài các bản ghi DNS, Zomail mã hoá thư khi truyền bằng TLS, áp dụng MTA-STS ở chế độ bắt buộc và kiểm tra DANE khi gửi thư đi. Thư tới đối tác có khai báo DANE sẽ đi qua kết nối đã xác minh thay vì kết nối tuỳ cơ.

Nếu bạn muốn bảo mật đường truyền được thiết lập theo hướng dẫn thay vì tự viết tệp chính sách, Zomail Cloud tính phí theo hộp thư mỗi tháng. Xem giá cập nhật trên trang bảng giá, hoặc hỏi bộ phận hỗ trợ về nhà cung cấp DNS cụ thể của bạn.

FAQ

MTA-STS có phải là mã hoá email không?

MTA-STS bắt buộc mã hoá khi truyền giữa các máy chủ thư. Nhà cung cấp gửi và nhận vẫn đọc được nội dung. Đây không phải mã hoá đầu cuối như S/MIME hay PGP.

Đã có SPF, DKIM, DMARC thì có cần MTA-STS không?

Có, vì chúng giải quyết hai việc khác nhau. SPF, DKIM, DMARC chứng minh ai là người gửi thư. MTA-STS bảo vệ đường truyền của thư. Một tên miền được bảo vệ tốt nên dùng cả hai nhóm, kèm TLS-RPT để phát hiện sự cố.

Chính sách MTA-STS sai thì sao?

Ở chế độ enforce, máy gửi có hỗ trợ sẽ giữ thư không giao an toàn được và thử lại sau, nên thư đến có thể bị chậm. Vì vậy hãy bắt đầu ở testing, đọc báo cáo TLS-RPT và luôn giữ các dòng mx: khớp với MX thật.

Kiểm tra MTA-STS của tên miền thế nào?

Hãy kiểm tra bản ghi TXT _mta-sts đã có chưa. Sau đó mở https://mta-sts.tenmiencuaban/.well-known/mta-sts.txt trên trình duyệt, xem trang có tải được mà không lỗi chứng chỉ và có liệt kê đúng MX không. Cuối cùng, theo dõi báo cáo TLS-RPT.