Cara Setup SPF, DKIM, dan DMARC untuk Domain Pengirim Email Aplikasi

Pengirim email aplikasi jarang mati karena spam filter yang aneh. Lebih sering ia mati karena tiga baris DNS yang tidak pernah dipasang. Pola keluhannya selalu sama: domain sudah dipasang ke layanan pengiriman, pesan tes dikirim, hasilnya masuk folder spam, atau Gmail menolak balik dengan kode 550 5.7.26 yang menyebut pengirim tidak terautentikasi. Tiga komponen yang menyelesaikan ini adalah SPF, DKIM, dan DMARC, dan ketiganya bukan fitur provider email, melainkan record DNS yang dibaca server penerima.

Tiga Pertanyaan yang Diajukan Server Penerima

Saat sebuah message masuk, server penerima sebenarnya menanyakan tiga hal berbeda, dan setiap record menjawab satu pertanyaan. SPF menanyakan apakah server yang mengantarkan pesan ini boleh mengirim atas nama domain tersebut. DKIM menanyakan apakah pesan ini benar datang dari domain itu dan datang tanpa diubah. DMARC menanyakan apakah jawaban dua cek sebelumnya berlaku untuk alamat yang dilihat penerima di baris From, dan kalau tidak, apa yang harus dilakukan pada pesan itu.

Yang membuat pemasangan record ini sering salah adalah fakta sederhana: setiap cek membaca domain yang berbeda dari pesan yang sama. SPF memakai Return-Path, DKIM memakai domain pada field d= di dalam tanda tangan, dan DMARC memakai alamat From. Mayoritas kegagalan setup muncul karena salah satu dari tiga domain itu bukan domain yang dikira sebelumnya.

Record	Bentuk DNS	Nama yang dibaca	Fungsi
SPF	TXT di domain pengirim	Envelope sender, yaitu MAIL FROM atau Return-Path	Daftar server yang diizinkan mengirim untuk domain itu
DKIM	Record di nama selector._domainkey.domain	Domain pada field d= di header tanda tangan	Bukti bahwa pesan ditandatangani pemilik kunci dan tidak berubah dalam perjalanan
DMARC	TXT di _dmarc.domain	Domain pada header From	Aturan alignment sekaligus kebijakan untuk pesan yang gagal

SPF: Daftar Server, Bukan Identitas Pengirim

SPF adalah daftar server yang diizinkan mengirim untuk sebuah domain, diterbitkan sebagai record TXT. Saat pesan datang, server penerima membandingkan alamat IP yang mengantarkan pesan terhadap daftar itu. Cocok berarti lolos, tidak cocok berarti gagal atau softfail, tergantung bagaimana record ditutup.

Contoh record yang benar untuk domain yang mengirim lewat Google Workspace terlihat seperti ini.

v=spf1 include:_spf.google.com ~all

Dua hal yang paling sering terlewat. Pertama, nama domain yang diperiksa. SPF tidak melihat From yang dibaca penerima. SPF memeriksa envelope sender, alamat yang dipakai di balik layar supaya pesan gagal punya tujuan kembali. Penerima normal tidak melihatnya kecuali membuka source mentah, dan banyak provider email justru mengarahkan envelope ke domain milik mereka sendiri, bukan ke domain pengirim.

Kedua, SPF terikat pada server yang menyerahkan pesan, sehingga forwarding sering merusaknya. Saat pesan diteruskan, server penerus yang menjadi pengirim, dan ia hampir tidak pernah ada di daftar, sehingga SPF gagal setelah forwarding meski isinya sama persis.

Ada juga batas teknis yang jadi sumber masalah nyata: evaluasi SPF punya plafon 10 lookup DNS, termasuk lookup dari include: bersarang. Mendaftarkan banyak layanan sekaligus bisa membuat record gagal dievaluasi bahkan kalau isinya benar. Aturan praktisnya, satu record yang ramping dan akurat mengalahkan record yang berisi semua layanan yang pernah dipakai tim.

Dua jebakan lain yang jarang dibahas. SPF tidak diwarisi subdomain, jadi record yang dipasang di domain utama tidak berlaku untuk subdomain pengiriman. Dan kalau tanpa sengaja ada dua record TXT yang sama-sama diawali v=spf1 pada nama yang sama, penerima mengembalikan permerror, artinya seluruh evaluasi mati, bukan salah satunya dipakai.

DKIM: Tanda Tangan yang Terbukti dari Kunci Publik

DKIM bekerja seperti segel yang menolak dibuka diam-diam. Saat provider mengirim, ia menandatangani pesan dengan kunci privat yang hanya dia pegang, lalu menempelkan tanda tangan sebagai header. Kunci publik pasangannya diterbitkan di DNS, jadi server penerima mana pun bisa mengambilnya dan memeriksa tanda tangan itu.

Record publiknya tinggal di nama yang menyertakan selector.

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu3Xk

Kalau tanda tangan valid, penerima menyimpulkan dua hal: yang menandatangani menguasai kunci untuk domain tersebut, dan bagian yang ditandatangani tidak berubah di jalan. Bagian yang ditandatangani adalah body plus sekumpulan header, dan kumpulan itu selalu memasukkan From serta biasanya Subject. Salah satunya berubah, cek gagal.

Satu pesan boleh membawa beberapa tanda tangan DKIM sekaligus, masing-masing untuk domain berbeda. Ini penting untuk layanan yang menambahkan tanda tangan sendiri di atas tanda tangan pengirim asal. Field d= di dalam tanda tangan itulah yang menentukan domain mana yang divalidasi, dan DMARC nanti membandingkan domain itu dengan From.

Banyak provider kini memberi record DKIM dalam bentuk CNAME ke kunci yang mereka hosting sendiri. Keuntungannya nyata: rotasi kunci tidak perlu menunggu suntingan DNS baru di sisi pengirim. Konsekuensinya, satu kesalahan penamaan langsung fatal, karena CNAME yang tersimpan dengan nama berlebih tidak akan pernah dibaca server penerima.

DMARC: Mengikat Semua ke Alamat From

DMARC menutup celah yang ditinggalkan SPF dan DKIM dengan menempelkan hasil cek ke domain yang tampil di From. Supaya sebuah pesan lolos DMARC, minimal salah satu dari SPF atau DKIM harus lolos dan memakai domain yang cocok dengan domain From. Kecocokan ini disebut alignment.

Contoh record DMARC yang agresif:

v=DMARC1; p=quarantine; rua=mailto:[email protected]; adkim=s; aspf=r; pct=100

Alignment tidak berarti harus identik. Pada mode default yang relaxed, dua domain dianggap align kalau berbagi organizational domain yang sama, yaitu bagian yang dibeli dari registrar. Jadi mail.example.com dan send.mail.example.com saling align, tapi tidak dengan example.net. Mode strict bisa diminta lewat adkim=s atau aspf=r untuk salah satu mekanisme.

Inilah penjelasan dari hasil yang terlihat kontradiktif: SPF tertulis pass, DKIM tertulis pass, tapi DMARC tertulis fail. Keduanya lolos untuk domain yang salah. Tanda tangan valid dari provider yang tidak berhubungan, atau SPF yang lolos di domain milik provider, tidak mengautentikasi alamat From milik pengirim untuk keperluan DMARC.

DMARC juga memberi instruksi tentang nasib pesan yang gagal, lewat p=none, p=quarantine, atau p=reject, dan bisa meminta laporan. Perlu digarisbawahi bahwa nilai ini bukan perintah tanpa syarat untuk membuang atau masuk spam: penerima tetap menimbang DMARC bersama aturan filter miliknya sendiri.

Urutan Pemasangan yang Aman

Kesalahan paling mahal adalah memasang kebijakan keras sebelum tahu siapa saja yang mengirim atas nama domain. Urutan yang lebih aman dimulai dari domain mana yang dipakai mengirim, dan untuk email aplikasi, subdomain khusus seperti mail.example.com biasanya pilihan paling sehat karena isolasi konfigurasinya dari email staf. Kalau memakai subdomain, cek dulu apakah policy induknya sudah menetapkan sp= untuk subdomain, supaya tidak malah melemahkan aturan yang sudah ada.

Tahap	Record DMARC	Tujuan
1. Observasi	v=DMARC1; p=none; rua=mailto:[email protected]	Mengumpulkan laporan tanpa dampak ke pengiriman. Buat mailbox atau alias untuk alamat itu sebelum menerbitkan record
2. Perbaikan	p=none dipertahankan	Membaca laporan, menemukan pengirim liar atau pengirim sah yang terlupakan, merapikan SPF dan DKIM sampai lolos
3. Eskalasi	p=quarantine	Menandai pesan gagal supaya masuk spam, setelah yakin semua pengirim sah sudah tercakup
4. Penutupan	p=reject	Meminta penerima menolak pesan gagal, tingkatan paling kuat melawan pemalsuan domain

Satu peringatan yang layak ditulis ulang: jangan menurunkan policy quarantine atau reject yang sudah ada menjadi none hanya karena mengikuti contoh tutorial. Kalau domain sudah berada di tahap tiga, tutorial ini dipakai untuk memperbaiki SPF dan DKIM, bukan untuk mematikan proteksi.

Verifikasi: Jangan Percaya Dashboard

Verifikasi berarti memeriksa dua hal, apakah record terbit benar, dan apakah pesan yang keluar benar-benar lolos. Untuk sisi DNS, query langsung ke sumbernya lebih jujur daripada menunggu tombol verify.

dig NS example.com +short
dig CNAME k7qz2._domainkey.mail.example.com +short

Jawaban record DKIM harus cocok dengan target yang diberikan provider. Kalau kosong, curigai dulu nama record dan tipenya sebelum menunggu propagasi. Kesalahan klasik: provider minta selector dipasang di mail.example.com, tapi panel DNS menambah suffix domain sehingga record benar-benar terbit di nama yang lebih panjang. Nama itu tetap valid sebagai tempat penerbitan, hanya saja tidak akan pernah dicari server penerima di sana.

Untuk sisi pesan, kirim message uji ke akun Gmail lalu buka source dan cari header yang ditambahkan Google.

Authentication-Results: mx.google.com;
       dkim=pass [email protected] header.s=k7qz2;
       spf=pass smtp.mailfrom=contoh.send.mail.example.com;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=mail.example.com

Baca domain-nya, bukan hanya kata pass. DKIM harus memakai domain pengiriman, dan smtp.mailfrom harus memakai domain yang sama atau domain yang align. Kombinasi pass pada domain yang salah tetap berarti DMARC tidak melindungi identitas yang dilihat penerima.

Enam Kesalahan yang Paling Sering Terjadi

Pertama, memasang SPF di domain utama sementara envelope sender diarahkan ke domain provider, sehingga hasil SPF tidak pernah relevan dengan domain pengirim. Kedua, menumpuk include sampai menyentuh plafon 10 lookup dan memicu kegagalan evaluasi. Ketiga, lupa bahwa SPF tidak diwarisi subdomain, jadi subdomain baru mengirim tanpa proteksi. Keempat, mendaftarkan dua record v=spf1 sekaligus dan menuai permerror. Kelima, menyimpan DKIM CNAME dengan nama yang salah tumpuk, yang tidak ketahuan sampai ada pesan gagal. Keenam, langsung memasang p=reject tanpa membaca laporan, lalu kaget karena newsletter internal atau sistem ticketing lama ikut terblokir.

Untuk DNS yang ditampung di Cloudflare, ada catatan khusus: record DKIM yang berbentuk CNAME perlu diset ke mode DNS only, bukan lewat proxy, supaya nilai yang ditanyakan penerima benar-benar CNAME dan bukan A hasil flattening. Sebagian provider juga menyediakan alur otomatis yang menulis record atas nama domain lewat sign-in, berguna untuk mengurangi salah ketik, meski tetap perlu diverifikasi manual setelahnya.

Kenapa Ini Mendesak Sekarang

Pedoman pengirim Gmail mensyaratkan SPF atau DKIM bahkan untuk pengirim kecil, dan ketiga mekanisme diminta untuk pengirim yang menyentuh sekitar lima ribu pesan per hari ke akun Gmail personal. Artinya ambang itu bukan wacana untuk perusahaan besar. Startup yang mengirim notifikasi order atau reset password dalam jumlah menengah sudah masuk wilayah wajib. Konteks lain yang bikin record email sensitif: domain adalah aset yang bisa jatuh, seperti yang terlihat ketika pencabutan level registrasi menghapus sekitar 22 ribu situs dan layanan email sekaligus, dijelaskan pada tulisan kasus pencabutan domain level tiga oleh ICANN. Kalau domain hilang, record DMARC yang rapi di domain itu juga hilang, jadi catatan tentang kepemilikan DNS tetap relevan.

Untuk yang membangun layanan pengiriman sendiri, sisi transport dan sisi identitas adalah dua pekerjaan berbeda. Artikel cara membuat REST API dengan Go dan PostgreSQL membahas sisi aplikasinya, sementara tulisan ini menutup sisi yang membuat pesan dari aplikasi itu dipercaya server penerima. Keduanya harus beres, karena API yang cepat tidak menolong kalau mailbox penerima menolak sejak handshake.