Kenali peran SPF, DKIM, dan DMARC, petakan pengirim email yang sah, lalu tingkatkan kebijakan secara bertahap agar domain usaha lebih sulit dipalsukan.
Mengapa autentikasi domain penting bagi operasional usaha
Email perusahaan dipakai untuk mengirim penawaran, faktur, pemberitahuan HR, perubahan jadwal, dan jawaban kepada pelanggan. Karena pelanggan melihat nama domain sebagai tanda identitas, penyerang dapat mencoba meniru alamat tersebut untuk meminta pembayaran atau mengarahkan penerima ke tautan palsu. SPF, DKIM, dan DMARC adalah mekanisme autentikasi pada tingkat domain yang membantu server penerima menilai pesan yang mengaku berasal dari domain perusahaan. Mekanisme ini memperkuat satu bagian dari pertahanan email, tetapi tidak menggantikan kehati-hatian pengguna, pengamanan akun, atau verifikasi instruksi bernilai tinggi.
CISA menjelaskan DMARC sebagai kebijakan yang membantu penerima menentukan apakah pesan benar berasal dari pengirim yang dinyatakan dan memberi arahan untuk menangani pesan yang gagal pemeriksaan. Email authentication tidak dapat mencegah semua penipuan: akun pegawai yang sudah dibajak dapat mengirim pesan dari alamat sah, dan pelaku masih dapat mendaftarkan domain mirip. Karena itu, tujuan proyek bukan menjanjikan “email anti-penipuan”, melainkan mengurangi pemalsuan domain sendiri dan membangun proses yang membuat masalah pengiriman terlihat sebelum kebijakan diperketat.
Pahami fungsi SPF, DKIM, dan DMARC tanpa menyamakannya
SPF adalah catatan DNS yang menyatakan sistem mana yang diizinkan mengirim email untuk domain. Daftar tersebut harus sesuai dengan layanan yang benar-benar digunakan. DKIM menambahkan tanda tangan digital pada pesan sehingga penerima dapat memeriksa bahwa pesan ditandatangani oleh domain dan isi tertentu tidak berubah di perjalanan. DMARC memakai hasil SPF dan DKIM serta pemeriksaan keselarasan domain untuk memberi instruksi penanganan dan menyediakan alamat laporan. Ketiganya bekerja saling melengkapi, tetapi tidak mengonfirmasi bahwa isi pesan jujur atau bahwa pengirim yang terlihat memang pegawai tertentu.
Batas konsep itu penting. SPF yang terlalu luas mengizinkan terlalu banyak pengirim; DKIM yang belum dipasang pada satu layanan dapat membuat pesan sah gagal; kebijakan DMARC yang langsung menolak tanpa memahami alur bisa mengganggu notifikasi dari aplikasi lama. Pengaturan DNS juga bukan pengganti autentikasi multifaktor, proteksi endpoint, pemantauan aktivitas, atau prosedur konfirmasi perubahan rekening. Jelaskan kepada tim bahwa tanda lolos autentikasi menunjukkan kepatuhan terhadap aturan domain, bukan verifikasi bisnis atas setiap permintaan dalam email.
Petakan seluruh pengirim sah sebelum mengubah DNS
Mulailah dengan inventaris pengirim. Catat layanan email utama, sistem faktur, platform newsletter, formulir situs, aplikasi rekrutmen, dan vendor yang mengirim atas nama domain. Untuk setiap layanan, tentukan pemilik proses, siapa yang dapat mengubah konfigurasi, alamat pengirim yang digunakan, dan apakah pengiriman harus tetap berjalan. Tanyakan juga apakah ada subdomain terpisah untuk kampanye, transaksi, atau sistem internal. Tanpa peta ini, tim teknis dapat mengira bahwa sebuah sistem sudah tidak dipakai padahal masih mengirim bukti transaksi atau pengingat penting.
Buat lembar inventaris sederhana dengan kolom nama layanan, tujuan, pemilik, domain pengirim, konfigurasi yang diminta vendor, tanggal uji, dan status penghentian. Cocokkan daftar dengan tagihan perangkat lunak dan alamat “From” yang ditemukan di kotak surat, lalu konfirmasikan kepada pemilik bisnis. Catat pula domain yang tidak pernah mengirim agar tidak salah menafsirkan dashboard. Tahap ini bukan audit keamanan penuh; ini cara menghindari perubahan yang mengacaukan alur sah dan mengidentifikasi akun atau vendor yang perlu ditinjau sebelum kebijakan diterapkan.
Terapkan bertahap: dari pemantauan menuju penegakan
Urutan yang lebih aman adalah menerapkan SPF dan DKIM pada pengirim yang telah disetujui, memeriksa alignment, lalu menerbitkan kebijakan DMARC pemantauan. CISA menyarankan organisasi menelaah laporan terlebih dahulu, memperbaiki pengirim sah yang belum terdaftar, dan baru mengubah kebijakan ke karantina atau penolakan ketika pemahaman atas arus email memadai. Kebijakan pemantauan tidak memblokir pesan gagal autentikasi, tetapi dapat membantu melihat sumber yang mengaku memakai domain. Jangan langsung menyalin konfigurasi contoh tanpa menyesuaikannya dengan DNS dan layanan domain Anda.
Tetapkan satu pemilik teknis dan satu pemilik operasional untuk masa uji. Minta tiap unit melaporkan notifikasi yang berhenti, cek laporan per layanan, lalu uji pesan dari alur berbeda seperti faktur dan reset kata sandi. Ubah satu komponen pada satu waktu agar penyebab kegagalan mudah ditemukan. Jika sebuah layanan tidak mendukung autentikasi domain dengan baik, eskalasi ke vendor atau gunakan subdomain khusus yang dikendalikan organisasi. Setiap perubahan record sebaiknya mencatat nilai sebelumnya, waktu penerapan, hasil pengecekan, dan langkah rollback yang telah disepakati.
Baca laporan dan uji dampaknya pada email penting
Laporan DMARC dapat berisi informasi agregat tentang sumber pengiriman, hasil SPF dan DKIM, serta kebijakan yang diterapkan. Tunjuk orang yang mampu menafsirkan sumber tersebut dan jangan membagikan data mentah tanpa kebutuhan. Bandingkan alamat pengirim dengan inventaris, tandai sumber yang belum dikenal, dan tanyakan kepada pemilik proses sebelum memblokirnya. Google menyarankan domain menyiapkan DMARC dan menyediakan dashboard Postmaster Tools untuk memeriksa autentikasi serta indikator pengiriman. Nilai dashboard bergantung pada data yang tersedia dan tidak membuktikan bahwa seluruh email perusahaan telah aman.
Buat kasus uji untuk pesan pelanggan, pembayaran, penggajian, dan pemulihan akses. Minta penerima memeriksa apakah pesan masuk ke kotak masuk, spam, atau tertolak; bandingkan header autentikasi jika petugas teknis memerlukannya. Simpan hasil uji sebagai baseline. Jika ada pesan sah gagal, periksa layanan pengirim, jalur penerusan, perubahan konten, dan record DNS sebelum menurunkan kebijakan. Hindari mengirim data rahasia melalui email uji, dan jangan meminta pegawai memberikan kata sandi atau kode keamanan untuk membantu pemeriksaan.
Gabungkan autentikasi domain dengan kontrol proses pembayaran
Perubahan nomor rekening, permintaan pembayaran mendesak, pembelian gift card, atau permintaan data pegawai tidak boleh disetujui hanya karena email memakai alamat perusahaan. Tetapkan prosedur verifikasi melalui kanal yang sudah terdaftar, misalnya nomor telepon vendor yang ada di master pemasok, dan minta persetujuan kedua untuk transaksi melewati ambang yang ditetapkan perusahaan. Pisahkan alamat notifikasi otomatis dari komunikasi manusia bila memungkinkan. Kebiasaan ini melindungi proses dari pembajakan akun dan penipuan yang memakai domain serupa, dua kasus yang tidak selesai hanya dengan SPF, DKIM, dan DMARC.
Kantor Kita memiliki panduan untuk [memetakan alur kerja sebelum digitalisasi](https://www.kantorkita.co.id/peta-alur-kerja-sebelum-digitalisasi-bisnis/), yang dapat dipakai sebagai titik awal ketika tim menetapkan siapa menerima, memeriksa, dan menyetujui notifikasi operasional. Layanan [Kantor Kita](https://www.kantorkita.co.id/) menjadi contoh bagaimana proses kantor kian bertumpu pada aplikasi, sehingga identitas domain dan prosedur verifikasi perlu diperhatikan bersama. Tautan ini bukan klaim bahwa aplikasi tersebut menyediakan fitur autentikasi email atau perlindungan anti-phishing; kontrol domain harus ditangani oleh administrator email organisasi.
Susun pemeliharaan dan tanggung jawab setelah kebijakan aktif
Autentikasi domain memerlukan perawatan ketika vendor berganti, layanan baru diluncurkan, subdomain ditambahkan, atau akun lama dihapus. Terapkan proses perubahan: pemilik layanan mengajukan kebutuhan, administrator mengecek dokumentasi vendor, perubahan diuji, dan inventaris diperbarui setelah hasil diverifikasi. Jadwalkan tinjauan berkala yang sesuai dengan ukuran organisasi, misalnya ketika kontrak email diperbarui atau setelah migrasi sistem. Catat pengecualian dan tanggal kedaluwarsanya agar record sementara tidak menjadi izin permanen bagi pengirim yang sudah tidak digunakan.
Bagi usaha yang tidak memiliki tim TI besar, tugas dapat dibagi antara pemilik domain, penyedia email, konsultan DNS, dan manajer operasional. Pastikan setiap pihak mengetahui batas akses dan jalur eskalasi. Pilih metrik yang dapat ditafsirkan, seperti sumber sah yang telah dikonfirmasi, kegagalan dari sistem internal, dan jumlah perubahan yang masih menunggu pemilik. Angka mentah tanpa konteks tidak cukup untuk menyatakan keberhasilan. Tinjau pula backup konfigurasi DNS, akses ke registrar, dan kontak pemulihan, karena keamanan domain bergantung pada penguasaan akun registrar dan kanal pemulihan.
Checklist peluncuran yang realistis
Sebelum memulai, pastikan domain dan akun registrar berada di bawah kendali organisasi, daftar layanan pengirim sudah diperiksa, pemilik teknis telah ditunjuk, dan vendor memberi instruksi autentikasi resmi. Sesudah tahap pemantauan, tinjau setiap sumber yang muncul, perbaiki konfigurasi yang keliru, dan pastikan pesan penting berfungsi. Hanya setelah bukti cukup, pertimbangkan kebijakan yang lebih tegas sesuai toleransi risiko serta kapasitas pemantauan. Jika organisasi tidak memahami laporan, mintalah bantuan administrator yang kompeten daripada beralih ke penolakan agresif tanpa rencana pemulihan.
SPF, DKIM, dan DMARC memberi sinyal teknis yang membantu penerima membedakan sebagian pemalsuan domain. Hasil yang tahan lama muncul ketika konfigurasi didukung inventaris layanan, pengendalian perubahan, verifikasi transaksi melalui kanal kedua, dan edukasi pegawai. Tinjau kebijakan ketika metode pengiriman berubah dan dokumentasikan keputusan agar tim berikutnya memahami alasannya. Pendekatan bertahap membuat pemilik usaha dapat meningkatkan perlindungan tanpa mengorbankan komunikasi pelanggan yang sah, sambil tetap jujur mengenai risiko yang tidak diselesaikan oleh autentikasi domain.
Bacaan terkait
Pelajari informasi terkait untuk menyesuaikan langkah di atas dengan kebutuhan tim Anda:
