SMTP dirancang untuk memindahkan email di antara sistem yang dikelola secara independen, sedangkan STARTTLS oportunistik ditambahkan kemudian. Peningkatan ini memperbaiki kerahasiaan saat kedua sisi mendukungnya, tetapi perilaku oportunistik memiliki kelemahan struktural: jika negosiasi TLS gagal, pengirim dapat tetap mengirim melalui koneksi plaintext. Penyerang aktif di jaringan yang dapat mengganggu trafik SMTP dapat memanfaatkan fallback tersebut dengan menekan STARTTLS atau mengarahkan pengiriman ke host yang tidak semestinya.
MTA-STS, yang distandardisasi dalam RFC 8461, memberi domain penerima cara untuk menyatakan kebijakan yang lebih ketat. Pengirim yang mendukungnya mengambil kebijakan melalui HTTPS, menyimpannya dalam cache, lalu menerapkannya pada pengiriman SMTP berikutnya. Dalam mode enforcement, pengirim mewajibkan host MX yang diotorisasi dan koneksi TLS yang valid sebelum mengirim pesan.
Mekanismenya sengaja dipisahkan antara DNS dan HTTPS. DNS memberi sinyal bahwa kebijakan tersedia sekaligus membawa identifier kebijakan. HTTPS membawa kebijakan itu sendiri melalui kanal yang terautentikasi.
DNS mengumumkan identifier kebijakan saat ini
Domain menerbitkan record TXT MTA-STS pada _mta-sts:
_mta-sts.example.com. IN TXT "v=STSv1; id=20260924T2300;"v=STSv1 menandai versi protokol. Nilai id adalah string opaque yang dipilih penerbit kebijakan. Peran operasional utamanya adalah invalidasi cache: ketika kebijakan berubah, domain mengubah identifier agar pengirim mengetahui bahwa salinan dalam cache mungkin sudah tidak mutakhir.
Record TXT tidak memuat aturan otorisasi MX. Record tersebut mengarahkan pengirim ke proses pengambilan kebijakan HTTPS yang terpisah. Pemisahan ini juga berarti perubahan identifier TXT tanpa kebijakan valid yang sesuai dapat mengganggu pengiriman bagi pengirim yang segera melakukan refresh.
MTA-STS tidak mewajibkan DNSSEC untuk record discovery ini. Kanal kebijakannya yang terautentikasi adalah HTTPS. DNSSEC tetap dapat melindungi data DNS pada deployment yang menggunakannya, tetapi DNSSEC bukan trust anchor yang ditetapkan oleh MTA-STS.
HTTPS membawa kebijakan
Kebijakan diambil dari lokasi HTTPS tetap:
https://mta-sts.example.com/.well-known/mta-sts.txtServer HTTPS harus menyajikan sertifikat yang diterima pengirim untuk mta-sts.example.com. Isi kebijakan menggunakan field berbasis baris. Kebijakan enforcement yang umum berbentuk:
version: STSv1
mode: enforce
mx: mail.example.com
mx: *.mail.example.com
max_age: 604800version menandai format kebijakan. mode mengendalikan perilaku pengirim. Setiap baris mx menentukan pola hostname MX yang diizinkan, sedangkan max_age memberi tahu pengirim berapa lama kebijakan boleh disimpan dalam cache.
Host kebijakan dan mail exchanger memiliki peran berbeda. mta-sts.example.com mendistribusikan kebijakan melalui HTTPS; entri mx membatasi tujuan SMTP yang dapat diterima berdasarkan kebijakan tersebut.
Pola MX membatasi tujuan pengiriman
Pengirim MTA-STS terlebih dahulu melakukan lookup MX normal untuk domain penerima. Pengirim kemudian membandingkan hostname MX yang diperoleh dengan pola mx dalam kebijakan.
Entri literal cocok dengan hostname tersebut. Entri wildcard yang diawali *. dapat cocok dengan host di bawah suffix yang disebutkan sesuai aturan pencocokan RFC. Pola yang luas perlu digunakan secara sengaja karena setiap host yang cocok menjadi tujuan yang memenuhi syarat berdasarkan kebijakan.
Kebijakan tidak menggantikan record MX. DNS tetap menentukan kandidat mail exchanger beserta preferensinya. MTA-STS menambahkan pemeriksaan kebijakan terhadap kandidat tersebut. Host yang muncul di DNS tetapi tidak cocok dengan kebijakan MTA-STS aktif bukan tujuan yang dapat diterima ketika enforcement berlaku.
Perbedaan ini penting saat migrasi penyedia email. Record MX, entri mx MTA-STS, sertifikat, dan cache kebijakan perlu dikoordinasikan. Menghapus penyedia lama dari kebijakan sebelum DNS dan trafik yang masih antre selaras dapat menyebabkan kegagalan pengiriman sementara.
Enforcement mewajibkan TLS terautentikasi
mode: enforce mengubah penanganan kegagalan. Untuk host MX yang valid menurut kebijakan, pengirim harus membentuk TLS dan memvalidasi sertifikat server sesuai aturan MTA-STS sebelum mengirim pesan. Jika pemeriksaan tersebut gagal, pengirim memperlakukan kondisi itu sebagai kegagalan pengiriman dan tidak diam-diam beralih ke plaintext.
Di sinilah perubahan keamanan utamanya. STARTTLS oportunistik menyatakan bahwa enkripsi lebih disukai ketika tersedia. Kebijakan MTA-STS yang diterapkan menyatakan kepada pengirim pendukung bahwa pengiriman plaintext bukan pengganti yang dapat diterima untuk kumpulan tujuan yang telah diterbitkan.
MTA-STS tidak menyediakan enkripsi pesan end-to-end. TLS melindungi hop SMTP di antara mail transfer agent yang berpartisipasi. Pesan masih dapat diproses, disimpan, diteruskan, atau terekspos di tempat lain sesuai properti keamanan sistem email yang lebih luas.
MTA-STS juga tidak mengautentikasi manusia yang mengirim pesan. SPF, DKIM, dan DMARC menangani bagian lain dari autentikasi email dan kebijakan domain. Ketiganya tidak menggantikan enforcement kebijakan transport.
Mode testing memisahkan observasi dari pemblokiran
Kebijakan dapat menggunakan:
mode: testingDalam mode testing, kegagalan kebijakan tidak semestinya memblokir pengiriman hanya karena MTA-STS. Mode ini memberi operator ruang untuk menerbitkan batasan MX yang dituju dan memeriksa laporan kegagalan sebelum berpindah ke enforcement.
Pemisahan tersebut berguna karena infrastruktur SMTP sering memiliki lebih banyak jalur pengiriman daripada yang tampak pada satu layar konfigurasi. Host MX cadangan, endpoint regional, layanan filtering pihak ketiga, jalur pembaruan sertifikat, dan sisa migrasi dapat memengaruhi rute yang terlihat.
Testing tidak setara dengan enforcement. Domain yang terus berada dalam mode testing belum menginstruksikan pengirim pendukung untuk menolak percobaan pengiriman yang melanggar kebijakan.
Cache kebijakan menciptakan jendela persistensi yang disengaja
max_age dinyatakan dalam detik. Setelah pengirim mengambil kebijakan yang valid, kebijakan tersebut dapat disimpan dalam cache selama interval itu. Cache merupakan bagian penting dari ketahanan MTA-STS terhadap downgrade: kegagalan sementara saat mengambil kebijakan tidak otomatis menghapus status enforcement yang telah terbentuk sebelumnya.
Persistensi tersebut juga berdampak pada operasi. Kebijakan enforcement yang keliru dapat tetap berpengaruh sampai pengirim memperbaruinya atau masa cache berakhir. Mengurangi max_age sebelum migrasi terencana dapat memperpendek jendela persistensi, tetapi hanya setelah pengirim mengambil kebijakan yang membawa nilai lebih pendek itu.
Dengan demikian, id di DNS dan max_age dalam kebijakan HTTPS menangani persoalan berbeda. Identifier memberi sinyal bahwa kebijakan mungkin berubah. Masa cache membatasi berapa lama kebijakan yang sudah diambil tetap dapat digunakan.
Validitas sertifikat menjadi bagian dari batas pengiriman
Hostname MX yang diotorisasi saja belum cukup dalam mode enforcement. Sertifikat TLS yang disajikan server SMTP juga harus lolos pemeriksaan validasi yang berlaku.
Hal ini mencegah pengalihan sederhana menjadi tepercaya hanya karena penyerang dapat membuat trafik DNS atau jaringan mengarah ke server yang mendukung SMTP dan TLS. Pengirim memerlukan tujuan yang diotorisasi kebijakan serta sesi TLS yang terautentikasi.
Operasi sertifikat akibatnya menjadi bagian dari operasi pengiriman email. Sertifikat kedaluwarsa, hostname yang tidak cocok, deployment yang belum lengkap pada seluruh node MX, atau kegagalan validasi lain dapat menunda email saat enforcement aktif. Pemantauan rollout sertifikat pada setiap endpoint yang diotorisasi kebijakan menjadi bagian dari pemeliharaan kebijakan transport.
MTA-STS dan DANE melindungi SMTP melalui jalur trust yang berbeda
DANE untuk SMTP dapat mengikat autentikasi layanan email ke record TLSA yang dilindungi DNSSEC. MTA-STS menggunakan kebijakan HTTPS yang diautentikasi melalui Web PKI. Keduanya dapat mengurangi paparan terhadap serangan downgrade atau pengalihan, tetapi model trust dan kebutuhan deployment keduanya berbeda.
MTA-STS dirancang bagi domain yang dapat mengoperasikan hosting kebijakan HTTPS tanpa mewajibkan deployment DNSSEC. DANE bergantung pada validasi DNSSEC dan pemrosesan TLSA yang spesifik terhadap protokol. Operator email dapat menjumpai kedua mekanisme dalam ekosistem, sehingga perilaku pengirim harus mengikuti spesifikasi yang berlaku bagi setiap sumber kebijakan tervalidasi, bukan memperlakukannya sebagai record yang dapat saling menggantikan.
TLS reporting membuat kegagalan kebijakan terlihat
SMTP TLS Reporting, yang didefinisikan terpisah dalam RFC 8460, melengkapi kebijakan transport dengan memberikan informasi agregat kepada domain penerima mengenai keberhasilan dan kegagalan pengiriman TLS. Domain dapat menerbitkan record TXT _smtp._tls yang menentukan tujuan laporan.
MTA-STS tidak bergantung pada TLS reporting untuk enforcement, tetapi reporting dapat menampilkan kegagalan sertifikat, ketidakcocokan kebijakan, dan masalah transport lain sebelum atau setelah kebijakan berpindah ke enforcement. Laporan adalah bukti operasional, bukan pengganti pemeriksaan kebijakan di sisi pengirim.
Deployment yang aman bergantung pada state yang terkoordinasi
Deployment MTA-STS yang stabil menjaga empat bagian tetap selaras: record DNS MX, kebijakan HTTPS, sertifikat pada setiap mail exchanger yang diotorisasi, dan identifier kebijakan DNS. Perubahan perlu memperhitungkan cache pengirim dan tidak mengasumsikan setiap MTA jarak jauh melihat state baru pada saat yang sama.
Kebijakan yang paling berguna bukan sekadar kebijakan dengan masa cache terpanjang atau daftar host tersempit. Kebijakan harus secara akurat mewakili infrastruktur penerima dan tetap valid selama rotasi sertifikat, failover, serta migrasi terencana.
MTA-STS menambahkan aturan transport yang persisten pada SMTP: pengirim pendukung dapat mempertahankan pernyataan terautentikasi bahwa email untuk suatu domain harus dikirim ke kumpulan host tertentu yang mendukung TLS. Dengan demikian, peningkatan enkripsi best-effort berubah menjadi kondisi pengiriman yang dapat diterapkan tanpa mengubah SMTP menjadi protokol enkripsi end-to-end.