# Làm sao thiết lập MTA-STS và TLS-RPT cho tên miền của tôi?

> MTA-STS cần một bản ghi TXT tại _mta-sts, một tệp chính sách được phục vụ qua HTTPS tại mta-sts.yourdomain, và một bản ghi TXT TLS-RPT để nhận báo cáo.

- URL: https://postelva.com/vi/guides/mta-sts-setup/
- Cập nhật lần cuối: 2026-11-12
- Đơn vị phát hành: Postelva (https://postelva.com)

MTA-STS cho biết các máy chủ thư khác chỉ nên gửi đến bạn qua TLS đã được xác minh. Nó cần hai bản ghi DNS và một tệp nhỏ trên một máy chủ web.

**Trả lời nhanh — Làm sao thiết lập MTA-STS và TLS-RPT?**

Công bố một bản ghi TXT tại _mta-sts.yourdomain với v=STSv1 và một id, phục vụ tệp chính sách tại https://mta-sts.yourdomain/.well-known/mta-sts.txt với chứng chỉ hợp lệ, và thêm một bản ghi TXT tại _smtp._tls cho báo cáo TLS-RPT (RFC 8461 và RFC 8460). **Postelva** lưu trữ các bản ghi DNS; tệp chính sách cần một máy chủ web HTTPS.

## Bốn thành phần của thiết lập MTA-STS và TLS-RPT

*Tên và định dạng theo RFC 8461 và RFC 8460, đọc ngày 12 tháng 11 năm 2026.*

| Thành phần | Ở đâu | Nội dung | Lưu ở đâu |
| --- | --- | --- | --- |
| Bản ghi MTA-STS | TXT tại _mta-sts.example.com | v=STSv1; id=20261112T000000Z | DNS của bạn (DNS miễn phí tại Postelva) |
| Tên máy chủ web | A, AAAA hoặc CNAME tại mta-sts.example.com | Trỏ tới một máy chủ web | DNS của bạn |
| Tệp chính sách | https://mta-sts.example.com/.well-known/mta-sts.txt | version, mode, các dòng mx, max_age | Một máy chủ web có HTTPS và chứng chỉ hợp lệ |
| Bản ghi TLS-RPT | TXT tại _smtp._tls.example.com | v=TLSRPTv1; rua=mailto:tlsrpt@example.com | DNS của bạn |

## Thiết lập MTA-STS trong sáu bước

1. **Liệt kê các máy chủ MX của bạn** — Chính sách phải nêu tên các máy chủ thư của nhà cung cấp. Proton Mail dùng mail.protonmail.ch và mailsec.protonmail.ch, Mailbox.org dùng mxext1 đến mxext4.mailbox.org.
2. **Thiết lập tên máy chủ web** — Trong trình chỉnh sửa DNS, thêm một bản ghi cho mta-sts trỏ tới một máy chủ web bạn kiểm soát, và xin một chứng chỉ hợp lệ cho mta-sts.yourdomain.
3. **Công bố tệp chính sách ở chế độ thử nghiệm** — Tạo tệp mta-sts.txt trong thư mục .well-known, với mode: testing và một max_age ngắn.
4. **Thêm bản ghi TXT _mta-sts** — Công bố v=STSv1; id= kèm một giá trị duy nhất, chẳng hạn ngày và giờ.
5. **Thêm bản ghi TLS-RPT** — Công bố bản ghi TXT tại _smtp._tls với một địa chỉ mailto trong rua, và đọc báo cáo hằng ngày.
6. **Chuyển sang enforce** — Khi báo cáo không cho thấy lỗi nào với các máy chủ MX của chính bạn, hãy đổi mode thành enforce, tăng max_age, và cập nhật id.

*Bản ghi DNS và tệp chính sách (mode testing)*

```dns
; DNS records
_mta-sts.example.com.      IN  TXT    "v=STSv1; id=20261112T000000Z"
_smtp._tls.example.com.    IN  TXT    "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"
mta-sts.example.com.       IN  CNAME  webhost.example.net.

; File served at https://mta-sts.example.com/.well-known/mta-sts.txt
version: STSv1
mode: testing
mx: mail.protonmail.ch
mx: mailsec.protonmail.ch
max_age: 86400
```

## MTA-STS bảo vệ điều gì?

**MTA-STS cho phép một tên miền thư khai báo rằng nó hỗ trợ TLS và người gửi phải từ chối gửi đến bất kỳ máy chủ MX nào không thể trình chứng chỉ hợp lệ.** RFC 8461, một Đề xuất chuẩn tháng 9 năm 2018, định nghĩa điều này. Không có nó, mã hóa giữa các máy chủ chỉ là tùy cơ hội: người gửi thử STARTTLS và, nếu kẻ tấn công gỡ bỏ nó, sẽ gửi thư dưới dạng văn bản rõ.

Với chính sách ở chế độ enforce, người gửi hỗ trợ MTA-STS sẽ tải chính sách của bạn, kiểm tra máy chủ MX có nằm trong danh sách mx không, và yêu cầu một kết nối TLS hợp lệ với chứng chỉ khớp. Nếu bất kỳ kiểm tra nào thất bại, thư sẽ chờ và không được gửi qua kênh yếu hơn. Nó chỉ bảo vệ thư đến, và chỉ hoạt động với những người gửi triển khai nó. Nó không xác thực thư: việc đó thuộc về các bản ghi trong [SPF, DKIM và DMARC](https://postelva.com/vi/spf-vs-dkim-vs-dmarc/ "SPF vs DKIM vs DMARC: what is the difference?").

## Tệp chính sách chứa gì?

**Tệp chính sách là một tệp văn bản thuần gồm các dòng khóa: giá trị, với phiên bản, chế độ, các mẫu MX được phép và thời gian tồn tại tính bằng giây.** RFC 8461 định nghĩa các trường này. version phải là STSv1. mode là enforce (người gửi không được gửi đến các máy chủ không qua được kiểm tra), testing (việc gửi có thể tiến hành, và người gửi hỗ trợ TLS-RPT sẽ gửi báo cáo lỗi) hoặc none (như thể không có chính sách). Mỗi dòng mx nêu đầy đủ một máy chủ, ví dụ mail.protonmail.ch, hoặc dùng ký tự đại diện ở nhãn ngoài cùng bên trái, như *.example.net. max_age là một số giây, tối đa 31,557,600, và RFC nói giá trị này thường nên là vài tuần trở lên. Ví dụ của RFC dùng 604800, tức một tuần.

Tệp phải được phục vụ qua HTTPS tại mta-sts.yourdomain với chứng chỉ hợp lệ cho tên đó. Chỉ câu trả lời HTTP 200 mới được tính, và không được theo chuyển hướng, điều này loại trừ chuyển tiếp URL, tức một dịch vụ trả lời bằng chuyển hướng. Tệp nên được gửi dưới dạng text/plain. Hãy dùng một máy chủ web nhỏ hoặc một dịch vụ lưu trữ trang tĩnh mà bạn kiểm soát. Các dòng mx phải khớp với bản ghi của nhà cung cấp như được liệt kê trong [MX record là gì](https://postelva.com/vi/what-is-an-mx-record/ "What is an MX record?").

## id và thứ tự cập nhật là gì?

**id trong bản ghi TXT là một nhãn gồm 1 đến 32 chữ cái và chữ số, phải đổi mỗi khi chính sách thay đổi, để người gửi biết cần tải lại tệp.** RFC 8461 nói rằng nó xác định một phiên bản của chính sách và không có thứ tự giữa các id, nên dấu thời gian theo ngày giờ hoạt động tốt.

Cập nhật theo thứ tự này: công bố tệp chính sách mới trước, rồi mới đổi id. Một người gửi thấy id mới trước khi có tệp mới sẽ lưu lại chính sách cũ. Khi đổi nhà cung cấp thư, các máy chủ MX cũng đổi, nên hãy sửa các dòng mx trước khi đổi các bản ghi MX, giữ các máy chủ cũ trong danh sách trong lúc chuyển, và tăng id. Một dòng mx bị quên ở chế độ enforce sẽ khiến thư không đến, và hướng dẫn [cách chuyển email sang nhà cung cấp mới](https://postelva.com/vi/guides/move-email-provider-without-downtime/ "How to move email to a new provider without losing mail") đưa ra thứ tự an toàn cho phần còn lại.

## TLS-RPT là gì và báo cáo chứa những gì?

**TLS-RPT là một định dạng báo cáo, RFC 8460, trong đó các máy chủ gửi cho bạn biết mỗi ngày có bao nhiêu kết nối TLS tới tên miền của bạn thành công hoặc thất bại.** Bạn công bố một bản ghi TXT tại _smtp._tls.yourdomain với v=TLSRPTv1 và một trường rua chứa địa chỉ mailto: hoặc https:. Báo cáo mailto phải mang chữ ký DKIM hợp lệ từ tên miền báo cáo.

Mỗi báo cáo là một tài liệu JSON bao quát một ngày UTC. Nó nêu chính sách được áp dụng (MTA-STS, DANE hoặc none), đếm số phiên thành công và thất bại, và đưa ra loại lỗi, như certificate-expired hoặc starttls-not-supported, cùng địa chỉ IP gửi và nhận. Nhờ đó bạn biết được chứng chỉ đã hết hạn hoặc một dòng mx bị gõ sai, trước khi chuyển sang enforce. Hãy coi vài tuần đầu là giai đoạn chạy thử như được khuyến nghị cho [DMARC](https://postelva.com/vi/guides/dmarc-setup/ "How to set up DMARC: p=none to p=reject").

## Tôi có cần MTA-STS cho tên miền email cá nhân không?

**Không: MTA-STS là biện pháp tăng cường tùy chọn, và các quy tắc cho người gửi lớn không yêu cầu nó.** Google, Yahoo và Microsoft yêu cầu người gửi hàng loạt có SPF, DKIM và DMARC, và không liệt kê MTA-STS. Với một tên miền cá nhân tại Proton Mail, Fastmail hoặc Mailbox.org, thiết lập này chỉ đáng làm nếu bạn chấp nhận việc duy trì một máy chủ web và một chứng chỉ.

Các nhà cung cấp khác nhau. Theo cách đọc của Postelva ngày 12 tháng 11 năm 2026 về danh sách thiết lập DNS của 4 nhà cung cấp (Proton Mail, Tuta, Mailbox.org và Fastmail), 1 nhà cung cấp liệt kê một bản ghi MTA-STS trong thiết lập của chính họ (Tuta, dạng CNAME), còn các trang trợ giúp của ba nhà kia không ghi gì. Toàn bộ thiết lập gồm 3 bản ghi DNS và 1 tệp. Kiểm tra từng cái bằng các lệnh trong [cách kiểm tra bản ghi MX, SPF, DKIM và DMARC](https://postelva.com/vi/guides/check-email-dns-records/ "How to check MX, SPF, DKIM and DMARC records"): dig TXT _mta-sts.example.com +short và dig TXT _smtp._tls.example.com +short.

Và một định nghĩa có thể trích dẫn: MTA-STS là chính sách làm cho TLS trở thành bắt buộc khi các máy chủ khác gửi thư đến tên miền của bạn, còn TLS-RPT là báo cáo hằng ngày cho bạn biết khi nào điều đó thất bại.

## Câu hỏi về MTA-STS và TLS-RPT

### Tôi có thể lưu tệp chính sách MTA-STS tại nhà cung cấp DNS không?

Không, nếu chỉ có DNS: tệp cần một máy chủ web trả lời qua HTTPS tại mta-sts.yourdomain. Chuyển tiếp URL không hoạt động, vì không được theo chuyển hướng.

### Tôi nên dùng max_age bao nhiêu?

RFC 8461 nói giá trị thường dao động từ vài tuần trở lên, với 604800 giây (một tuần) trong ví dụ của nó. Hãy bắt đầu bằng một giá trị ngắn ở chế độ testing và tăng khi báo cáo đã sạch.

### MTA-STS có giống DANE không?

Không. Cả hai đều bảo vệ TLS giữa các máy chủ, nhưng DANE dựa vào DNSSEC và bản ghi TLSA, còn MTA-STS dựa vào một tệp chính sách HTTPS. TLS-RPT báo cáo về cả hai.

### Điều gì xảy ra nếu chứng chỉ của tôi hết hạn ở chế độ enforce?

Người gửi hỗ trợ MTA-STS sẽ ngừng gửi đến các máy chủ của bạn khi chứng chỉ của một máy chủ MX thất bại, và thư sẽ chờ trong hàng đợi của họ. Điều tương tự áp dụng cho một dòng mx bị thiếu, nên hãy theo dõi TLS-RPT.

### Tôi có phải dùng chế độ enforce không?

Không. Chế độ testing đã cho bạn báo cáo, và mode none tắt chính sách.

**Tóm lại**

- MTA-STS (RFC 8461) làm cho TLS trở thành bắt buộc đối với thư gửi đến tên miền của bạn.
- Thiết lập: một bản ghi TXT tại _mta-sts, một tệp chính sách HTTPS tại mta-sts.yourdomain/.well-known/mta-sts.txt và một bản ghi TXT tại _smtp._tls cho TLS-RPT (RFC 8460).
- Chính sách liệt kê mode (enforce, testing, none), các máy chủ mx và max_age, tối đa 31,557,600 giây.
- Không được theo chuyển hướng, nên chuyển tiếp URL không thể phục vụ tệp.
- Đổi id mỗi khi chính sách thay đổi; cập nhật tệp trước, rồi bản ghi TXT.
- Bắt đầu ở chế độ testing và đọc báo cáo TLS-RPT trước khi chuyển sang enforce.
- Postelva lưu trữ các bản ghi DNS miễn phí; một .com có giá 12,49 US$/năm mỗi năm.

## Nguồn

1. [RFC 8461, SMTP MTA Strict Transport Security (MTA-STS)](https://www.rfc-editor.org/rfc/rfc8461.html) — RFC Editor (đọc 2026-11-12)
2. [RFC 8460, SMTP TLS Reporting](https://www.rfc-editor.org/rfc/rfc8460.html) — RFC Editor (đọc 2026-11-12)
3. [Hướng dẫn cho người gửi email](https://support.google.com/a/answer/81126) — Google Workspace Admin Help (đọc 2026-11-12)
4. [Tên miền riêng và chống giả mạo](https://proton.me/support/anti-spoofing-custom-domain) — Proton (đọc 2026-11-12)

---

Postelva: Postelva đăng ký tên miền cho email riêng — địa chỉ bạn giữ khi đổi nhà cung cấp — thanh toán bằng tiền mã hóa, không KYC: không giấy tờ tùy thân, chỉ một email đã xác minh cho mỗi tên miền. Dịch vụ do DomaineGoat LLC vận hành, một công ty đăng ký tại Panama; tên miền được đăng ký qua đối tác nhà đăng ký được ICANN công nhận. Một .com có giá 12,49 US$/năm, cùng một mức mỗi năm.