Beranda › Panduan

Cara Setting SPF, DKIM, dan DMARC: Record, Jebakan, dan Pengecekan

Diterbitkan 2026-11-03 ／ Diperbarui 2026-11-03 ／ Oleh Yuki Nakazawa

Pengaturan SPF, DKIM, dan DMARC tidak lagi opsional jika Anda mengirim email dari domain sendiri. Lakukan dengan urutan berikut: publikasikan satu record SPF, aktifkan penandatanganan DKIM dengan kunci 2048-bit, lalu publikasikan record DMARC yang dimulai dari p=none dengan pelaporan aktif. Sekalian, pastikan alamat IP yang mengirim email Anda memiliki reverse DNS (PTR) yang cocok.

Panduan ini berlaku baik Anda mengirim dari shared hosting, VPS sendiri, Google Workspace, Microsoft 365, maupun layanan email massal. Di sini tersedia record yang dapat Anda sesuaikan, kesalahan yang paling sering merusak autentikasi, dan cara memastikan semuanya berfungsi dari header pesan yang sebenarnya.

Fakta di bawah ini telah diperiksa berdasarkan RFC serta halaman resmi Google, Yahoo, dan Microsoft per November 2026. Persyaratan penyedia kotak surat dapat berubah, jadi jadikan halaman mereka sebagai acuan akhir.

Apa yang dibuktikan SPF, DKIM, dan DMARC, serta urutan pengaturannya

SPF (Sender Policy Framework) memungkinkan domain mencantumkan, di DNS, server mana saja yang boleh mengirim email atas namanya. Server penerima melihat envelope sender (alamat SMTP MAIL FROM, yang nantinya muncul sebagai Return-Path), mengambil record SPF domain tersebut, lalu memeriksa apakah alamat IP yang terhubung ada di daftar. SPF saja tidak mengatakan apa pun tentang alamat From yang dilihat pembaca.

DKIM (DomainKeys Identified Mail) menambahkan tanda tangan kriptografis pada setiap pesan. Sistem pengirim menandatangani dengan kunci privat, dan penerima memverifikasi tanda tangan dengan kunci publik yang dipublikasikan di DNS. Tanda tangan yang valid membuktikan bahwa domain penanda tangan (nilai d=) bertanggung jawab atas pesan tersebut dan bahwa header serta isi yang ditandatangani tidak diubah selama perjalanan.

DMARC (Domain-based Message Authentication, Reporting and Conformance) menghubungkan keduanya dengan domain From yang terlihat. Pesan lolos DMARC hanya jika SPF atau DKIM lolos dan domain yang diautentikasi selaras (aligned) dengan domain From. Record DMARC juga memberi tahu penerima apa yang Anda inginkan terhadap pesan yang gagal (tidak ada tindakan, karantina, atau tolak) dan ke mana laporan agregat dikirim, yang menjadi cara Anda menemukan sumber pengiriman yang terlupakan.

Urutan pengaturan

1. Daftar semua sistem yang mengirim email atas nama domain Anda: server sendiri, Google Workspace atau Microsoft 365, layanan newsletter dan email transaksional, formulir web, serta alat penagihan dan help desk.
2. Publikasikan satu record SPF yang mencakup semuanya.
3. Aktifkan DKIM di setiap sistem pengirim dan publikasikan kunci publiknya.
4. Publikasikan DMARC dengan p=none dan alamat pelaporan rua. Google menyarankan menunggu 48 jam setelah menyiapkan SPF dan DKIM sebelum menambahkan DMARC.
5. Baca laporannya, perbaiki sumber yang gagal, lalu beralih ke p=quarantine dan akhirnya p=reject.

Pengaturan SPF: satu record, sepuluh lookup

SPF adalah record TXT pada domain itu sendiri. Berikut contoh domain yang mengirim dari servernya sendiri melalui IPv4 dan IPv6 serta menggunakan Google Workspace:

example.com.  3600  IN  TXT  "v=spf1 ip4:203.0.113.10 ip6:2001:db8::10 include:_spf.google.com ~all"

Di sebagian besar panel kontrol DNS, Anda mengosongkan kolom host (atau mengisi @), memilih TXT, lalu menempelkan nilai yang dimulai dengan v=spf1. Komponen yang umum:

Jebakan SPF

• Satu record SPF per nama. RFC 7208 melarang beberapa record SPF untuk domain yang sama; penerima akan mengembalikan permerror dan SPF gagal untuk semua pesan. Saat menambahkan layanan, edit record yang sudah ada dan tambahkan include:-nya, alih-alih membuat record v=spf1 kedua.
• Batas 10 lookup. Mekanisme include, a, mx, ptr, dan exists serta modifier redirect masing-masing memicu lookup DNS, dan totalnya selama seluruh evaluasi, termasuk lookup di dalam include bersarang, tidak boleh melebihi 10. Jika melebihi, hasilnya permerror. ip4:, ip6:, dan all tidak memakan lookup. RFC 7208 juga menyebutkan bahwa penerima semestinya berhenti setelah dua lookup yang tidak mengembalikan jawaban, jadi hapus include untuk layanan yang sudah tidak Anda gunakan.
• ~all versus -all. -all berarti sumber yang tidak tercantum tidak diizinkan (fail); ~all berarti sumber tersebut kemungkinan tidak diizinkan (softfail). Google menyarankan ~all untuk domain Workspace; Microsoft menyarankan -all untuk domain Microsoft 365 yang juga menggunakan DKIM dan DMARC. Jika Anda belum yakin telah menemukan semua pengirim, mulailah dengan ~all dan biarkan DMARC yang melakukan penegakan.
• Subdomain memerlukan record sendiri. Record SPF di example.com tidak mencakup news.example.com. Menempatkan layanan email massal di subdomain tersendiri juga memberinya jatah 10 lookup terpisah dan memisahkan reputasinya dari email staf Anda.
• Kesalahan sintaks. Microsoft mencantumkan yang umum: include= alih-alih include:, spasi setelah titik dua, dan titik di akhir domain yang di-include.

Untuk domain yang tidak pernah mengirim email, publikasikan v=spf1 -all agar domain tersebut lebih sulit dipalsukan.

Pengaturan DKIM: kunci 2048-bit dan selector

DKIM terdiri dari dua bagian: sistem pengirim menandatangani dengan kunci privat, dan DNS memublikasikan kunci publik yang sesuai. Dengan Google Workspace, Microsoft 365, sebagian besar panel kontrol hosting, dan sebagian besar layanan email, Anda membuat kunci di konsol admin lalu menyalin nilai DNS yang ditampilkan.

Panjang kunci dan selector

Gunakan kunci RSA 2048-bit. RFC 8301 menetapkan 1024 bit sebagai batas minimum dan menyatakan bahwa penanda tangan semestinya menggunakan setidaknya 2048 bit; RFC ini juga melarang rsa-sha1. Panduan Google sejalan: pilih 2048 bit jika host DNS Anda mendukungnya, dan gunakan 1024 hanya jika tidak.

Selector adalah label yang menunjukkan kunci mana yang menandatangani pesan, sehingga satu domain dapat memiliki beberapa kunci sekaligus, satu per layanan pengirim atau satu per periode rotasi. Kunci publik berada di selector._domainkey.yourdomain. Google Workspace menggunakan google sebagai selector default. Microsoft 365 menggunakan dua record CNAME, selector1._domainkey dan selector2._domainkey, yang mengarah ke kunci yang di-host Microsoft; ambil target persisnya dari portal Defender atau Get-DkimSigningConfig, karena formatnya berbeda-beda per tenant.

Memublikasikan kunci publik yang panjang

Kunci publik 2048-bit lebih panjang dari 255 karakter yang diizinkan dalam satu character-string DNS, sehingga dalam format zone file kunci tersebut ditulis sebagai beberapa string berkutip dalam satu record TXT:

selector1._domainkey.example.com.  3600  IN  TXT  ( "v=DKIM1; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA(first part of your key)"
    "(rest of your key)IDAQAB" )

Ganti bagian dalam tanda kurung dengan kunci Anda yang sebenarnya. Penerima menggabungkan string-string tersebut tanpa spasi di antaranya, jadi Anda boleh memotong di mana saja di dalam kunci. Banyak panel kontrol memotong nilai panjang secara otomatis: tempelkan seluruh nilai terlebih dahulu dan potong sendiri hanya jika panel menolaknya. Pastikan tidak ada yang hilang saat menyalin; p= yang kosong berarti kunci telah dicabut.

Di VPS sendiri yang menjalankan Postfix atau MTA serupa, milter penandatanganan seperti OpenDKIM dapat membuat pasangan kunci, misalnya opendkim-genkey -b 2048 -s selector1 -d example.com. Publikasikan isi file kunci publik yang dihasilkan seperti contoh di atas.

Pastikan pesan benar-benar ditandatangani

Buka pesan yang Anda kirim dan cari header DKIM-Signature:. Tag d=-nya seharusnya domain Anda dan s= adalah selector yang Anda publikasikan. Banyak layanan email secara default menandatangani dengan domain mereka sendiri; hal itu lolos DKIM tetapi tidak selaras dengan domain From Anda, sehingga tidak membantu DMARC. Aktifkan fitur autentikasi domain kustom di layanan tersebut agar d= menjadi domain Anda.

Pengaturan DMARC: mulai dari p=none, lalu tegakkan

DMARC adalah record TXT di _dmarc di bawah domain Anda. Mulailah dalam mode pemantauan, yang meminta penerima untuk tidak mengubah cara mereka menangani email Anda, dan minta laporan agregat:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Laporan agregat adalah ringkasan yang dapat dibaca mesin tentang alamat IP mana yang mengirim email atas nama domain Anda dan apakah email itu lolos; Google menyarankan kotak surat atau grup khusus untuk menerimanya. Setelah laporan menunjukkan bahwa semua sumber yang sah lolos dengan alignment, perketat kebijakan dengan mengedit record yang sama, bukan menambahkan record kedua:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

Alignment, dalam bahasa sederhana

Untuk lolos DMARC, setidaknya salah satu dari SPF atau DKIM harus lolos untuk domain yang cocok dengan domain From. Dalam mode relaxed, domain organisasinya harus sama, sehingga tanda tangan DKIM dengan d=example.com selaras dengan email dari alerts@news.example.com. Mode strict mengharuskan kecocokan persis. Layanan email sering menggunakan domain mereka sendiri di Return-Path, sehingga SPF tidak akan selaras meskipun lolos; DKIM yang selaras adalah cara praktis agar pesan-pesan tersebut lolos DMARC.

Jika Anda menginginkan kebijakan berbeda untuk subdomain, tambahkan sp=. Misalnya, p=reject; sp=quarantine menolak email yang gagal dari domain utama dan hanya mengarantina kegagalan dari subdomain.

Catatan tentang standar yang diperbarui

Pada Mei 2026, DMARC diterbitkan ulang sebagai RFC 9989, yang menggantikan RFC 7489. Record yang sudah ada tetap berfungsi dan tetap diawali dengan v=DMARC1. Standar baru ini menghapus tag pct, yang jarang diterapkan secara akurat kecuali pada nilai 0 atau 100, dan menambahkan tag seperti t=y (mode uji) dan np (kebijakan untuk subdomain yang tidak ada). Sebagian halaman bantuan penyedia masih menampilkan pct, jadi cara yang paling tidak ambigu untuk menerapkan penegakan adalah dengan menaikkan nilai p= secara bertahap.

Reverse DNS (PTR) untuk IP pengirim Anda

Reverse DNS memetakan alamat IP kembali ke nama host. Google mewajibkan semua pengirim ke akun Gmail pribadi memiliki record PTR yang nama host-nya mengarah kembali ke IP pengirim yang sama, dan Yahoo mewajibkan forward DNS dan reverse DNS yang valid untuk IP pengirim serta menyarankan record PTR yang bermakna dan tidak generik.

203.0.113.10       PTR  mail.example.com.
mail.example.com.  A    203.0.113.10

Record PTR tidak berada di zona domain Anda. Pemilik alamat IP-lah yang mengendalikannya, jadi di VPS Anda mengaturnya di panel kontrol penyedia (sering disebut reverse DNS atau rDNS), lalu membuat record A yang sesuai (AAAA untuk IPv6) di DNS Anda sendiri. Jika Anda mengirim melalui IPv6, alamat IPv6 juga memerlukan perlakuan yang sama. Dengan Google Workspace, Microsoft 365, layanan email, dan sebagian besar shared hosting, penyedia yang mengelola IP pengirim beserta reverse DNS-nya untuk Anda.

Cara memverifikasi pengaturan Anda

Baca Authentication-Results

Kirim pesan uji ke kotak surat eksternal dan lihat header lengkapnya. Di Gmail, buka pesan lalu pilih Tampilkan yang asli. Bantuan DKIM Google mencatat bahwa Anda sebaiknya mengirim ke pengguna lain, bukan ke diri sendiri. Cari header seperti ini:

Authentication-Results: mx.example.net;
       dkim=pass header.i=@example.com header.s=selector1;
       spf=pass smtp.mailfrom=example.com;
       dmarc=pass header.from=example.com

Tata letak persisnya berbeda-beda menurut penerima. Yang penting adalah spf=pass, dkim=pass, dan dmarc=pass, dengan domain Anda sendiri di header.i atau header.d dan di header.from. Jika SPF lolos untuk domain milik layanan tetapi DKIM menunjukkan domain lain, DMARC akan gagal: perbaiki alignment DKIM terlebih dahulu.

Kueri DNS secara langsung

dig +short TXT example.com
dig +short TXT selector1._domainkey.example.com
dig +short TXT _dmarc.example.com
dig +short -x 203.0.113.10

Di Windows, nslookup -type=TXT _dmarc.example.com melakukan hal yang sama. Perubahan DNS dapat memerlukan waktu untuk menyebar; Google menyebutkan bahwa SPF dan DKIM masing-masing dapat memerlukan waktu hingga 48 jam untuk mulai berfungsi. Pemeriksa online gratis juga dapat mengurai record Anda dan menghitung lookup SPF untuk Anda.

Jika autentikasi lolos tetapi email masih bounce atau masuk spam, periksa apakah IP atau domain pengirim Anda tercantum di DNSBL dengan pemeriksa blacklist kami, dan lihat email tidak terkirim karena blacklist untuk langkah selanjutnya.

Persyaratan pengirim Gmail, Yahoo, dan Outlook.com

Penyedia kotak surat besar kini menegakkan autentikasi. Per November 2026, halaman resmi mereka menyatakan hal berikut.

• Gmail (berlaku sejak 1 Februari 2024): semua pihak yang mengirim ke akun Gmail pribadi memerlukan SPF atau DKIM, forward DNS dan reverse DNS yang cocok, koneksi TLS, dan tingkat spam di bawah 0,3% di Postmaster Tools. Pengirim lebih dari 5.000 pesan per hari juga memerlukan SPF dan DKIM sekaligus, record DMARC (p=none dapat diterima), domain From yang selaras dengan SPF atau DKIM, serta berhenti berlangganan sekali klik untuk email pemasaran. Kunci DKIM harus minimal 1024 bit, dengan 2048 yang disarankan.
• Yahoo (penegakan sejak Februari 2024): semua pengirim memerlukan SPF atau DKIM, forward DNS dan reverse DNS yang valid, serta tingkat spam di bawah 0,3%. Pengirim massal memerlukan SPF dan DKIM sekaligus, kebijakan DMARC minimal p=none yang lolos, alignment From (relaxed sudah cukup), berhenti berlangganan sekali klik yang berfungsi, serta forward DNS dan reverse DNS yang valid untuk IP pengirim.
• Outlook.com (layanan konsumen di balik outlook.com, hotmail.com, dan live.com): domain yang mengirim lebih dari 5.000 email per hari harus lolos SPF dan DKIM serta memublikasikan DMARC minimal p=none, yang selaras dengan SPF atau DKIM. Microsoft menyatakan bahwa mulai 5 Mei 2025, pesan yang tidak patuh akan ditolak dengan error 550; 5.7.515.

Baca teks lengkapnya di panduan pengirim email Google, praktik terbaik pengirim Yahoo, dan pengumuman Outlook.com dari Microsoft. Meskipun Anda mengirim jauh lebih sedikit pesan, menyiapkan ketiganya sekarang berarti Anda tidak akan terkejut jika ambang batasnya diturunkan di kemudian hari. Untuk pemecahan masalah khusus Gmail, lihat Gmail tidak mengirimkan email Anda.

Kesalahan yang umum

• Record SPF kedua. Menambahkan record v=spf1 baru untuk setiap layanan membuat SPF tidak valid untuk seluruh domain. Gabungkan semuanya menjadi satu.
• Terlalu banyak include. Layanan lama yang tertinggal di SPF menghabiskan jatah 10 lookup. Hapus yang sudah tidak digunakan dan pindahkan email massal ke subdomain.
• Kunci sudah dipublikasikan, penandatanganan belum diaktifkan. Di Google Workspace, Anda tetap harus mengklik Mulai autentikasi setelah record DNS aktif; platform lain memiliki tombol serupa.
• Layanan menandatangani dengan domainnya sendiri. SPF dan DKIM sama-sama lolos, tetapi DMARC gagal. Aktifkan penandatanganan dengan domain kustom.
• Langsung melompat ke p=reject. Formulir web atau sistem penagihan yang terlupakan tiba-tiba berhenti mengirim email dalam semalam. Mulailah dari p=none dan baca laporannya.
• Kerusakan saat salin-tempel. Tanda kutip berlebih di dalam nilai, kunci yang terpotong, atau nama host yang menjadi _dmarc.example.com.example.com karena panel menambahkan domain secara otomatis. Pengecekan cepat dengan dig akan menemukan semua masalah ini.

Tanya jawab

Halaman resmi yang digunakan

Fakta dalam artikel ini telah diperiksa berdasarkan halaman resmi di bawah ini pada saat diterbitkan. Kebijakan dan perilaku layanan dapat berubah tanpa pemberitahuan, jadi periksa halaman resmi sebelum mengandalkan informasi yang penting.

• RFC 7208: Sender Policy Framework (SPF)
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
• RFC 8301: Cryptographic Algorithm and Key Usage Update to DKIM
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 9989: DMARC (obsoletes RFC 7489)
• Google: Email sender guidelines
• Google Workspace: Set up SPF
• Google Workspace: Set up DKIM
• Google Workspace: Set up DMARC
• Yahoo Sender Hub: Sender Best Practices
• Microsoft Community Hub: Outlook's New Requirements for High-Volume Senders
• Microsoft Learn: Set up SPF for your Microsoft 365 domain
• Microsoft Learn: How to use DKIM for email in your custom domain

Panduan terkait

Semua panduan →