Keamanan Siber

Autentikasi Email untuk Domain Pribadi — Cara SPF, DKIM, dan DMARC Bekerja Bersama

Ditulis oleh Adam Muiz 21 Aug 2026 Diperbarui: 21 Aug 2026 9 menit baca

Satu domain pribadi bisa mengirim reset password melalui web host, balasan contact form melalui penyedia mailbox, dan newsletter melalui layanan ketiga. Bagi pembaca, ketiga pesan itu dapat menampilkan domain yang sama setelah From:. Namun, bagi mail server penerima, masing-masing datang melalui sistem dan identitas teknis yang berbeda.

Di celah itulah SPF, DKIM, dan DMARC berperan. Ketiganya sering diperkenalkan sebagai tiga DNS record yang tinggal disalin, padahal penjelasan itu menyembunyikan pertanyaan yang lebih sulit: identitas mana yang sebenarnya diperiksa oleh tiap mekanisme? Sebuah record bisa valid secara sintaks, tetapi email yang sah tetap gagal diautentikasi. Sebuah pesan juga bisa lolos SPF atau DKIM tanpa membuktikan hal yang mungkin disimpulkan orang dari alamat pengirim yang terlihat.

Panduan ini membangun gambaran mental yang praktis untuk domain pribadi, lalu mengubahnya menjadi urutan deployment yang hati-hati. Ini bukan resep untuk penyedia tertentu. Nilai yang benar bergantung pada semua layanan yang diizinkan mengirim email untuk domain tersebut.

Satu pesan dapat membawa beberapa identitas pengirim

Kata “pengirim” bersifat ambigu dalam email. Ada tiga identitas domain yang sangat relevan:

Header From: alamat penulis yang biasanya ditampilkan aplikasi email kepada pembaca, misalnya [email protected].
Envelope sender: alamat yang diberikan melalui SMTP MAIL FROM, dan sering terlihat kemudian sebagai Return-Path. Kegagalan pengiriman memakai identitas transport ini, sementara domainnya bisa berbeda dari domain From yang terlihat.
DKIM signing domain: domain pada tag d= dari tanda tangan DKIM yang valid. Sebuah layanan dapat menandatangani dengan domainnya sendiri atau, jika custom-domain signing dikonfigurasi, dengan domain pelanggan.

Perbedaan ini bukan sekadar catatan teknis. SPF mengevaluasi identitas SMTP, sementara DKIM memvalidasi signing domain. DMARC menanyakan apakah setidaknya satu hasil yang sukses juga berhubungan, atau aligned, dengan domain pada alamat From yang terlihat.

SPF menjawab pertanyaan tentang otorisasi jalur

Sender Policy Framework memungkinkan sebuah domain memublikasikan host mana yang boleh memakai domain tersebut dalam SMTP MAIL FROM atau HELO/EHLO. Mail server penerima membandingkan alamat IP yang terhubung dengan policy di DNS. Secara sederhana, SPF bertanya: “Apakah server ini diizinkan mengirim memakai domain SMTP ini?”

Contoh record ilustratif dapat terlihat seperti ini:

example.com. TXT "v=spf1 include:spf.mail-provider.example -all"

Hostname tersebut sengaja dibuat fiktif. Record nyata harus memakai mekanisme persis yang diberikan oleh penyedia sebenarnya. Sebuah domain seharusnya hanya memublikasikan satu SPF record pada nama yang sama; membuat beberapa record v=spf1 terpisah akan menghasilkan error, bukan menggabungkannya. Evaluasi SPF juga memiliki batas sepuluh term yang menyebabkan DNS lookup, sehingga menambahkan entri include: terus-menerus bukan strategi tanpa batas.

Apa yang tidak dinyatakan oleh SPF pass

SPF biasanya tidak mengautentikasi alamat yang dilihat orang pada field From. Sebuah layanan dapat lolos SPF untuk bounce.service.example sementara pesan menampilkan [email protected]. Hasil itu memberi informasi berguna tentang jalur transport, tetapi belum menghubungkan domain layanan tersebut dengan example.com.

Forwarding menambah keterbatasan lain. Forwarder mengirim ulang pesan dari server baru. Server itu biasanya tidak tercantum dalam SPF policy pengirim awal. Jika forwarder mengubah envelope sender menjadi domain yang dikuasainya, SPF mungkin lolos untuk domain forwarder, tetapi tidak lagi aligned dengan domain From awal yang terlihat. Inilah sebabnya SPF saja merupakan dasar yang rapuh untuk mengevaluasi indirect mail.

DKIM menempelkan tanda tangan domain pada pesan

DomainKeys Identified Mail memakai pendekatan berbeda. Sistem pengirim menghitung hash atas header dan konten pesan yang dipilih, menandatanganinya dengan private key, lalu menambahkan header DKIM-Signature. Penerima mengambil public key yang sesuai dari DNS dan memverifikasi tanda tangan tersebut.

Key record dipublikasikan di bawah sebuah selector:

selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=PUBLIC_KEY_FROM_PROVIDER"

Selector memungkinkan sebuah domain memiliki lebih dari satu key, sehingga mendukung delegasi dan rotasi key. Private key harus tetap berada di sistem penanda tangan; DNS hanya memuat public key. Dalam setup hosted, penyedia biasanya membuat nilai TXT atau CNAME yang diperlukan dan menjelaskan cara mengaktifkan signing untuk custom domain.

Apa yang tidak dinyatakan oleh tanda tangan DKIM valid

Tanda tangan yang valid menunjukkan bahwa bagian yang ditandatangani tetap utuh sejak pemegang private key domain tersebut menandatanganinya. DKIM tidak mengenkripsi pesan. DKIM tidak membuktikan bahwa isinya benar atau aman. DKIM juga mengizinkan signing domain yang berbeda dari domain penulis yang terlihat, sehingga “DKIM pass” tidak otomatis berarti “domain From ini terautentikasi.”

Perubahan pesan dapat membuat tanda tangan tidak valid. Mailing list mungkin menambahkan tag pada subject atau footer; security gateway mungkin menulis ulang link atau menghapus lampiran. Beberapa perubahan kecil dalam perjalanan dapat ditoleransi oleh DKIM canonicalization, tetapi perubahan substansial sering tidak. Keterbatasan ini menjadi penting ketika sebuah domain kemudian meminta penanganan DMARC yang ketat.

DMARC menghubungkan autentikasi dengan domain From yang terlihat

DMARC tidak menggantikan SPF atau DKIM. Mekanisme ini memakai hasil keduanya dan membandingkan domain yang terautentikasi dengan domain RFC5322.From, yaitu domain yang umumnya dilihat pembaca.

Sebuah pesan lolos DMARC ketika setidaknya satu jalur berikut berhasil:

SPF lolos, dan domain envelope sender yang terautentikasi aligned dengan domain From.
DKIM lolos, dan signing domain aligned dengan domain From.

Keduanya tidak wajib sama-sama lolos, meski mengonfigurasi keduanya memberi ketahanan lebih baik. Pada relaxed alignment bawaan DMARC, subdomain dapat aligned ketika memiliki organizational domain yang sama. Strict alignment mengharuskan domain cocok persis. “Relaxed” di sini menjelaskan hubungan domain; istilah ini terpisah dari setting canonicalization DKIM yang memiliki nama sama.

Policy adalah permintaan, bukan jaminan pengiriman

Sebuah domain memublikasikan DMARC di _dmarc.example.com. Record monitoring dapat berbentuk:

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:[email protected]"

Nilai p meminta cara penerima menangani pesan yang gagal DMARC:

none tidak meminta tindakan pengiriman tertentu dan berguna ketika mengamati report.
quarantine meminta penerima memperlakukan kegagalan sebagai hal mencurigakan, sering kali dengan menempatkannya di spam.
reject meminta penerima menolak kegagalan, idealnya selama transaksi SMTP.

Penerima tetap memiliki kebebasan policy lokal, dan autentikasi tidak menjamin pesan masuk inbox. Reputasi, persetujuan penerima, format pesan, complaint rate, dan aturan khusus penerima adalah persoalan terpisah. Persyaratan penerima juga berubah seiring waktu; misalnya, operator yang mengirim ke Gmail sebaiknya memeriksa email sender guidelines Google yang aktif, bukan mengandalkan checklist lama.

Pesan langsung dan pesan yang diteruskan dapat berperilaku berbeda

Bayangkan sebuah receipt dikirim langsung oleh penyedia yang telah dikonfigurasi:

Alamat yang terlihat adalah [email protected].
Penyedia memakai domain envelope sender yang aligned, sehingga SPF lolos dan aligned.
Penyedia juga menandatangani dengan d=example.com, sehingga DKIM lolos dan aligned.
DMARC lolos melalui salah satu jalur tersebut.

Sekarang bayangkan sebuah mailbox meneruskan receipt itu secara otomatis ke tempat lain. IP server forwarding tidak diizinkan oleh SPF policy awal, sehingga SPF mungkin gagal. Jika forwarder tidak mengubah konten yang ditandatangani, tanda tangan DKIM awal yang aligned mungkin tetap dapat diverifikasi dan DMARC dapat lolos. Jika perantara juga mengubah konten yang ditandatangani, DKIM mungkin ikut gagal.

Masalah indirect flow ini didokumentasikan dalam RFC 7960; masalah tersebut bukan bukti bahwa setiap pesan gagal adalah palsu. ARC merupakan protokol eksperimental yang memungkinkan perantara membawa hasil autentikasi sebelumnya dalam rantai yang dapat diverifikasi. Penerima dapat memakai informasi itu dalam keputusan lokal, tetapi ARC bukan perbaikan universal atau jaminan penerimaan.

Rollout yang lebih aman dimulai dari inventaris

Jalan pintas yang berbahaya adalah memublikasikan p=reject sebelum menemukan semua pengirim yang sah. Sebuah website pribadi mungkin mengirim lebih sedikit email daripada organisasi besar, tetapi peta pengirimnya tetap dapat mencakup sistem yang terlupakan: hosting control panel, contact form CMS, uptime monitor, payment service, newsletter platform, support mailbox, atau automation job lama.

Inventaris semua mail stream. Catat domain From yang terlihat, envelope sender, DKIM signing domain, pemilik, serta apakah pesan dikirim langsung atau melalui perantara.
Satukan SPF. Pertahankan satu policy dan izinkan hanya pengirim yang masih digunakan. Periksa record resmi penyedia alih-alih menebak IP range atau include domain.
Aktifkan DKIM yang aligned. Pilih custom-domain signing jika didukung penyedia. Dokumentasikan kepemilikan selector dan rotasi key.
Kirim pengujian terkontrol. Uji setiap stream ke penerima yang dapat diperiksa. Lihat hasil SPF, DKIM, dan DMARC, termasuk domain yang dipakai untuk alignment.
Publikasikan DMARC dalam mode monitoring. Gunakan mailbox khusus aggregate report atau report processor yang sesuai. Report dapat berjumlah banyak dan berbentuk XML untuk mesin, bukan daftar serangan yang sederhana.
Perbaiki sumber yang tidak dikenal dan tidak aligned. Bedakan pengirim lama, layanan sah dengan setup custom domain yang belum lengkap, dan penggunaan yang benar-benar tidak diizinkan.
Pilih enforcement dengan sengaja. Beralih menuju quarantine atau reject hanya ketika alur yang sah telah dipahami dan dipantau. Waktu yang tepat bergantung pada jalur email domain dan toleransinya terhadap penolakan yang keliru.

Urutan observe-first ini juga tercermin dalam panduan setup DMARC Google saat ini. Ini adalah saran operasional, bukan aturan yang diterapkan sama persis oleh setiap penyedia.

Verifikasi hasil tanpa memercayai header yang salah

Sistem penerima umumnya menulis hasil ke header Authentication-Results. RFC 8601 mendefinisikan format yang dapat dibaca mesin, tetapi juga memberi peringatan penting: header tersebut hanya bermakna di dalam trust boundary penerima. Penyerang dapat menambahkan header yang tampak meyakinkan sebelum mengirim pesan. Percayai instance yang ditambahkan oleh infrastruktur penerima, bukan sembarang instance yang disalin dari luar.

Untuk setiap pengujian terkontrol, verifikasi:

domain mana yang dievaluasi SPF dan apakah hasilnya pass;
domain d= dan selector mana yang dipakai DKIM serta apakah tanda tangannya pass;
apakah DMARC pass dan mekanisme mana yang menghasilkan hasil aligned;
apakah jalur direct, forwarded, dan mailing list berperilaku berbeda;
apakah aggregate report mengungkap pengirim sah yang belum tercatat dalam inventaris.

Apa yang tetap tidak dapat diselesaikan kontrol ini

SPF, DKIM, dan DMARC mempersulit peniruan domain secara persis dan memberi bukti untuk policy penerima. Ketiganya tidak mengautentikasi orang di balik setiap mailbox, memeriksa apakah sebuah pesan jujur, atau mencegah penyerang mendaftarkan domain yang tampak mirip. DMARC juga tidak melindungi dari display name yang menyesatkan, mengenkripsi isi pesan, menghapus malware, atau menciptakan izin untuk mengirim email yang tidak diinginkan.

Kesimpulan yang berguna karena itu lebih sempit daripada “email sudah aman.” Pemilik domain dapat memublikasikan pihak yang boleh memakai identitas transport tertentu, menandatangani bagian pesan yang dipilih, menghubungkan hasil tersebut dengan domain From yang terlihat, mengamati kegagalan, dan meminta penanganan lebih ketat. Itu merupakan perlindungan yang berarti, tetapi tetap satu lapisan dalam sistem email yang lebih besar.

Deployment yang paling bertanggung jawab bukan yang memiliki record paling ketat pada hari pertama. Deployment yang bertanggung jawab adalah yang mengetahui pengirim sahnya, memverifikasi alignment, meninjau report, dan menerapkan enforcement sesuai bukti.