Email bisnis tidak hanya perlu terlindungi dari pemalsuan pengirim. Jalur pengiriman antarpeladen email juga perlu dijaga agar pesan tidak mudah dialihkan ke koneksi yang lebih lemah. SMTP secara historis dapat memakai STARTTLS untuk mengenkripsi koneksi, tetapi enkripsi oportunistis saja belum selalu mencegah penyerang mengganggu negosiasi TLS. Dua standar yang membantu mengatasi celah ini adalah MTA-STS dan TLS Reporting (TLS-RPT).
Keduanya bekerja pada sisi pengiriman email antarpeladen, bukan untuk mengenkripsi isi pesan dari ujung ke ujung. MTA-STS menerbitkan kebijakan tentang koneksi TLS yang harus dipenuhi pengirim, sedangkan TLS-RPT menyediakan laporan agregat mengenai keberhasilan dan kegagalan koneksi. Spesifikasi resminya dijelaskan dalam RFC 8461 dan RFC 8460.
Mengapa STARTTLS saja belum cukup?
STARTTLS memungkinkan dua server SMTP beralih dari koneksi biasa ke koneksi TLS. Namun, pada model oportunistis, pengirim bisa saja melanjutkan pengiriman tanpa TLS jika kemampuan STARTTLS tidak terlihat atau negosiasi gagal. Kondisi ini dapat terjadi akibat salah konfigurasi, gangguan jaringan, atau serangan downgrade yang mencoba menghilangkan tawaran STARTTLS.
Akibatnya, administrator domain penerima belum tentu mengetahui bahwa koneksi pernah gagal diamankan. MTA-STS menambahkan kebijakan yang dapat diperiksa pengirim untuk menentukan server penerima mana yang sah dan apakah koneksi TLS harus diwajibkan. TLS-RPT melengkapi kebijakan tersebut dengan laporan yang membantu menemukan masalah.
Apa yang dilakukan MTA-STS?
MTA-STS (SMTP MTA Strict Transport Security) memungkinkan domain penerima menyatakan bahwa server emailnya mendukung TLS dengan sertifikat yang valid. Kebijakan dipublikasikan melalui DNS TXT dan sebuah berkas teks yang diambil melalui HTTPS. Pengirim yang mendukung MTA-STS dapat memeriksa kebijakan tersebut dan menolak mengirim ke server MX yang tidak memenuhi ketentuannya saat mode kebijakan mewajibkan TLS.
Secara umum, implementasi melibatkan dua bagian. Pertama, buat TXT record bernama _mta-sts.example.com, misalnya:
v=STSv1; id=20261018aGanti example.com dengan domain sendiri. Nilai id merupakan penanda versi kebijakan; ubah nilainya ketika kebijakan diperbarui agar pengirim dapat mengetahui bahwa kebijakan baru tersedia.
Kedua, sajikan berkas kebijakan melalui HTTPS pada host mta-sts.example.com di jalur /.well-known/mta-sts.txt. Contoh isi sederhana:
version: STSv1
mode: testing
mx: mail.example.com
max_age: 604800Nama host pada baris mx harus sesuai dengan server MX yang benar-benar digunakan dan sertifikat TLS-nya perlu valid. Jika domain memiliki beberapa server MX, cantumkan setiap pola host yang memang diperlukan. Nilai max_age menyatakan masa berlaku kebijakan dalam detik.
Mulai dari mode testing sebelum enforce
MTA-STS memiliki mode testing, enforce, dan none. Mode testing membantu mengamati kegagalan tanpa langsung meminta pengirim menolak koneksi yang tidak memenuhi kebijakan. Setelah semua MX, DNS, sertifikat, dan endpoint HTTPS teruji, administrator dapat mempertimbangkan mode enforce. Dalam mode tersebut, pengirim yang mematuhi kebijakan harus menolak pengiriman ke MX yang melanggar persyaratan TLS.
Jangan langsung mengaktifkan enforce hanya karena sertifikat halaman web utama terlihat valid. Periksa setiap host MX, rantai sertifikat, masa berlaku sertifikat, konfigurasi TLS, serta perilaku saat pergantian sertifikat atau pemindahan layanan email. Kesalahan kebijakan dapat membuat email tertunda atau tidak terkirim dari pengirim yang menerapkan MTA-STS.
Bagaimana TLS-RPT membantu pemantauan?
TLS-RPT memberi domain penerima cara untuk menerima laporan agregat dari sistem pengirim yang mendukung standar ini. Laporan dapat menunjukkan kegagalan resolusi DNS, masalah koneksi ke MX, negosiasi STARTTLS, validasi kebijakan MTA-STS, atau validasi DANE. Informasi tersebut membantu membedakan gangguan konfigurasi biasa dari pola yang patut diselidiki.
Untuk mengaktifkannya, publikasikan TXT record di _smtp._tls.example.com. Contoh yang mengirim laporan ke kotak khusus:
v=TLSRPTv1; rua=mailto:[email protected]Pastikan alamat laporan benar-benar tersedia, memiliki kapasitas memadai, dan dipantau. Sebagian layanan juga mendukung URI HTTPS untuk menerima laporan. Laporan biasanya berbentuk agregat dan dapat memuat detail teknis tentang server serta jenis kegagalan, sehingga akses dan retensinya tetap perlu dikelola.
Checklist penerapan yang aman
- Inventarisasi semua MX dan pastikan setiap host mendukung STARTTLS dengan sertifikat tepercaya.
- Pasang endpoint kebijakan MTA-STS melalui HTTPS dengan sertifikat yang valid dan konten yang dapat diakses publik.
- Mulai dari mode testing, periksa laporan kegagalan, lalu perbaiki ketidaksesuaian sebelum beralih ke enforce.
- Publikasikan record TLS-RPT dan pantau laporan secara rutin, terutama setelah perubahan DNS atau penyedia email.
- Uji pembaruan ID kebijakan, pergantian sertifikat, dan perubahan host MX agar cache kebijakan tidak menimbulkan kejutan.
MTA-STS bukan pengganti SPF, DKIM, atau DMARC
MTA-STS melindungi kebijakan transportasi email antarpeladen, bukan membuktikan bahwa pengirim pesan berhak menggunakan alamat From tertentu. Untuk autentikasi domain dan mengurangi pemalsuan pengirim, tetap gunakan SPF, DKIM, serta DMARC. Baca juga panduan Nazuaf tentang SPF, DKIM, dan DMARC serta artikel perbedaan PGP, S/MIME, dan TLS pada email.
Standar-standar ini menangani masalah yang berbeda dan saling melengkapi. MTA-STS tidak menjamin semua email terenkripsi dari pengirim hingga penerima, tidak menggantikan enkripsi isi pesan, dan hanya membantu ketika pihak pengirim menerapkan dukungan yang sesuai. DNSSEC dan DANE juga dapat menjadi bagian dari strategi keamanan transportasi, tetapi memiliki prasyarat dan model validasi tersendiri.
Kesimpulan
MTA-STS membantu domain menerbitkan persyaratan TLS yang lebih tegas untuk pengiriman SMTP, sedangkan TLS-RPT memberi visibilitas atas kegagalan dan anomali koneksi. Penerapan terbaik dimulai dari inventarisasi MX, pengujian mode testing, pemeriksaan laporan, dan baru kemudian penegakan kebijakan. Dengan pemantauan berkala dan autentikasi email yang tepat, administrator dapat mengurangi risiko downgrade sekaligus menjaga agar email tetap terkirim secara andal.