Protokol Simple Mail Transfer Protocol (SMTP) dirancang tanpa mekanisme otentikasi identitas pengirim secara terintegrasi. Ketiadaan validasi bawaan ini memungkinkan pihak ketiga memalsukan alamat pengirim pada tajuk pesan—praktik yang dikenal sebagai pemalsuan surel (email spoofing). Teknik manipulasi ini lazim dimanfaatkan untuk serangan rekayasa sosial, penipuan identitas bisnis, dan distribusi perangkat perusak yang mengeksploitasi nama domain sah.

Pengamanan reputasi pengiriman menuntut pemilik domain membangun benteng pertahanan berbasis catatan Domain Name System (DNS). Tiga mekanisme standar industri yang saling melengkapi dalam menangani masalah ini adalah SPF, DKIM, dan DMARC. Ketiganya bekerja sama mengontrol izin infrastruktur, menjamin keaslian data pesan, dan menegakkan kebijakan mitigasi ketika validasi pengirim tidak terpenuhi.

Penerapan konfigurasi DNS ini harus dilakukan secara bertanggung jawab pada domain dan server milik pribadi atau infrastruktur yang pengelolaannya telah diberikan secara sah kepada Anda. Melakukan pengujian penetrasi atau pengiriman surel tiruan ke sistem pihak lain tanpa izin tertulis merupakan tindakan ilegal. Penguasaan ketiga catatan DNS ini ditujukan semata-mata untuk memperkuat postur pertahanan infrastruktur sendiri.

Sender Policy Framework (SPF) untuk Otorisasi Server Pengirim

SPF mendaftar server yang berhak mengirim surel atas nama domain. Standar ini bekerja pada tingkat protokol komunikasi SMTP dengan memeriksa alamat IP pengirim terhadap daftar resmi yang dipublikasikan pemilik domain pada catatan DNS bertipe TXT.

Ketika server penerima menerima pesan, server membaca alamat domain dari parameter MAIL FROM (juga disebut envelope sender atau jalur kembali). Server penerima kemudian melakukan kueri DNS untuk mengambil catatan SPF dari domain tersebut. Jika alamat IP server pengirim tercantum dalam catatan SPF, pemeriksaan dinyatakan berhasil (pass). Jika IP tidak terdaftar, pemeriksaan menghasilkan status gagal (fail atau softfail).

Catatan SPF didefinisikan sebagai string teks dengan awalan versi tertentu dan diikuti serangkaian mekanisme otorisasi:

v=spf1 ip4:198.51.100.1 include:_spf.layananemail.com -all

Komponen dari catatan tersebut mencakup parameter berikut:

  1. v=spf1: Mengidentifikasi bahwa catatan TXT ini merupakan catatan SPF versi 1.
  2. ip4: atau ip6:: Menyatakan alamat IP tunggal atau rentang subnet (CIDR) server surat milik sendiri yang berhak mengirim surel.
  3. include:: Mengotorisasi infrastruktur pihak ketiga—seperti penyedia layanan surel transaksi atau pemasaran berbasis komputasi awan—untuk mengirim surel atas nama domain Anda. Mekanisme ini membaca catatan SPF milik penyedia tersebut.
  4. mx: Mengizinkan seluruh server yang tercantum pada catatan MX (Mail Exchange) domain Anda untuk mengirim surel.
  5. a: Mengizinkan alamat IP yang terkait dengan catatan A domain untuk mengirim pesan.
  6. Kualifikasi akhir (all): Menentukan tindakan terhadap server di luar daftar. Awalan -all (hard fail) menginstruksikan server penerima bahwa pengirim tidak sah harus ditolak. Awalan ~all (soft fail) menandakan pesan mencurigakan namun masih dapat diterima dengan penandaan khusus. Awalan ?all (neutral) tidak memberikan perlakuan khusus.

RFC 7208 membatasi proses pencarian DNS (DNS lookup) pada catatan SPF maksimal sepuluh kali per evaluasi. Pelanggaran batasan ini menyebabkan kesalahan fatal (PermError), yang mengakibatkan kegagalan validasi di sisi penerima.

DomainKeys Identified Mail (DKIM) untuk Otentikasi dan Integritas Pesan

DKIM menandatangani surel secara kriptografis agar keasliannya bisa diperiksa. Berbeda dari SPF yang memverifikasi alamat IP transmisi pada lapisan jaringan, DKIM memvalidasi keutuhan pesan menggunakan pasangan kunci publik dan kunci privat berbasis algoritma asimetris (umumnya RSA atau Ed25519).

Proses kerja DKIM terbagi dalam dua tahap: penandatanganan di server asal dan verifikasi di server tujuan. Saat surel keluar dari server pengirim, Mail Transfer Agent (MTA) membuat nilai hash dari tajuk pesan tertentu (seperti From, To, Subject, Date) beserta isi badan surel (body). Nilai hash tersebut kemudian dienkripsi menggunakan kunci privat yang tersimpan aman di server pengirim. Hasil enkripsi dicantumkan ke dalam tajuk surel sebagai bidang DKIM-Signature.

Server penerima yang mendeteksi tajuk tersebut akan mengekstrak informasi pemilih (selector) dan domain dari parameter tanda tangan. Server kemudian mengambil kunci publik yang dipublikasikan pada catatan DNS TXT milik domain pengirim. Alamat catatan DNS untuk kunci publik DKIM menggunakan format penamaan terstruktur:

selector_khusus._domainkey.domainanda.com

Nilai catatan TXT DKIM berisi deklarasi versi dan kunci publik yang dienkode dengan format Base64:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0Y...IDAQAB

Penjelasan tag dalam catatan DKIM:

  1. v=DKIM1: Mendefinisikan versi protokol DKIM yang digunakan.
  2. k=rsa: Menentukan algoritma enkripsi kunci publik. Nilai bawaan adalah RSA.
  3. p=: Berisi deretan kunci publik. Kunci ini digunakan server penerima untuk mendekripsi tanda tangan digital pada tajuk DKIM-Signature.

Server penerima menghitung ulang hash dari tajuk dan badan surel yang masuk, lalu membandingkannya dengan hash hasil dekripsi kunci publik. Jika kedua nilai cocok, server memastikan pesan dikirim oleh entitas yang memegang kunci privat dan isi surel belum mengalami manipulasi data selama transit. Pemalsu surel tidak dapat memalsukan tanda tangan digital yang valid tanpa memiliki akses ke kunci privat pengirim.

DMARC sebagai Pengendali Kebijakan dan Pelaporan

SPF dan DKIM beroperasi secara independen tanpa saling berbagi status. SPF hanya memvalidasi domain MAIL FROM yang tersembunyi pada amplop teknis, bukan alamat From: yang terlihat oleh pengguna di aplikasi pembaca surel. Kondisi ini memungkinkan penyerang melewati SPF menggunakan domain mereka sendiri, sembari tetap memalsukan domain korban pada tajuk From:.

DMARC menyatukan keduanya dan menentukan tindakan bila pemeriksaan gagal. DMARC memperkenalkan konsep penyelarasan (alignment). Domain yang tertera pada alamat From: (RFC 5322) harus cocok dengan domain yang divalidasi oleh SPF (MAIL FROM), domain yang divalidasi oleh DKIM (tag d= pada tanda tangan), atau keduanya.

Catatan DMARC dipublikasikan pada subdomain khusus _dmarc.domainanda.com sebagai catatan TXT. Struktur catatan DMARC memuat parameter kebijakan dan alamat pelaporan:

_dmarc.domainanda.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100; aspf=r; adkim=r"

Tag konfigurasi DMARC meliputi:

  1. v=DMARC1: Versi protokol DMARC.
  2. p=: Kebijakan penanganan (policy) saat evaluasi gagal. Terdapat tiga tingkat kebijakan:
    • none: Mode pemantauan. Surel tetap dikirimkan ke kotak masuk penerima tanpa tindakan pembatasan. Digunakan untuk mengumpulkan data lalu lintas pengirim.
    • quarantine: Surel yang gagal validasi dipindahkan ke folder spam atau dikarantina sementara oleh server penerima.
    • reject: Surel yang gagal diselaraskan ditolak sepenuhnya pada tingkat transmisi SMTP sehingga tidak pernah mencapai pengguna.
  3. rua=: Alamat surel penampung laporan agregat (Aggregate Reports). Server penerima secara berkala mengirimkan laporan berkas XML berisi ringkasan IP pengirim, volume pesan, serta status SPF dan DKIM.
  4. ruf=: Alamat surel penampung laporan forensik (Forensic Reports) yang dikirim sesaat setelah terjadi kegagalan validasi spesifik.
  5. pct=: Persentase pesan yang dikenai penegakan kebijakan DMARC (nilai 1 hingga 100).
  6. aspf= dan adkim=: Mode penyelarasan SPF dan DKIM. Nilai r (relaxed) mengizinkan kecocokan pada tingkat subdomain, sedangkan s (strict) mewajibkan kecocokan nama domain secara persis.

Verifikasi dan Pengujian Konfigurasi pada Infrastruktur Sendiri

Penerapan konfigurasi DNS memerlukan tahapan validasi lokal untuk memastikan data telah terpropagasi dengan benar tanpa kesalahan sintaks. Kesalahan tanda baca atau spasi pada catatan DNS dapat menggagalkan verifikasi surel keluar.

Untuk memeriksa ketersediaan catatan SPF pada sistem operasi berbasis Linux, gunakan utilitas baris perintah dig:

dig TXT domainanda.com +short

Keluaran perintah harus menampilkan string v=spf1 beserta parameter IP dan mekanisme yang telah didefinisikan. Untuk memverifikasi catatan kunci publik DKIM, cantumkan selector yang digunakan server Anda:

dig TXT selector_khusus._domainkey.domainanda.com +short

Periksa keberadaan kebijakan DMARC menggunakan sintaks serupa:

dig TXT _dmarc.domainanda.com +short

Selain pemeriksaan DNS langsung, verifikasi fungsional dilakukan dengan mengirimkan surel uji dari server sendiri ke alamat surel pengujian eksternal. Periksa sumber pesan asli (raw message header) pada surel yang diterima. Header harus memuat blok Authentication-Results dengan parameter status:

Authentication-Results: mx.penerima.com;
       spf=pass (penerima.com: domain of [email protected] designates 198.51.100.1 as permitted sender) [email protected];
       dkim=pass [email protected] header.s=selector_khusus;
       dmarc=pass (p=quarantine sp=quarantine dis=none) header.from=domainanda.com

Jika salah satu parameter menampilkan status fail, periksa log transaksi surat pada MTA server lokal (/var/log/mail.log atau setara) untuk menelusuri ketidaksesuaian kunci kriptografi atau ketidakcocokan konfigurasi alamat asal. Untuk mendalami analisis lalu lintas data dan protokol keamanan jaringan tingkat lanjut di lingkungan uji mandiri, Anda dapat mengkaji dokumentasi keamanan sistem melalui kalilinux.net atau kalilinux.info sebagai rujukan teknis audit jaringan.

Implementasi ketiga catatan DNS ini harus dilakukan secara bertahap—dimulai dari SPF yang ketat, penandatanganan DKIM yang konsisten, penerapan kebijakan DMARC pada mode p=none untuk mengumpulkan laporan agregat, hingga pengetatan ke tingkat p=reject. Integrasi SPF, DKIM, dan DMARC secara komprehensif mengamankan identitas domain Anda dari pemalsuan surel, melindungi penerima dari penipuan digital, dan memastikan surel transaksi yang sah terkirim ke tujuan tanpa kendala reputasi.