SPF DKIM DMARC: Cara Setting agar Email Tidak Masuk Spam

Q: Pilih ~all atau -all?

Keduanya dapat diterima. Banyak administrator memakai ~all selama masa transisi, lalu mengandalkan DMARC untuk penegakan. Gunakan -all jika Anda yakin semua sumber pengirim sudah tercantum, dan selalu gunakan -all untuk domain yang tidak pernah mengirim email.

Q: Apakah record DMARC lama dengan pct masih berfungsi?

Record tetap valid karena versinya tetap v=DMARC1. RFC 9989 menghapus tag pct, sehingga penerima yang mengikuti standar baru akan mengabaikannya; jangan mengandalkan pct untuk penerapan bertahap.

Oleh Tim Clouder · 8 November 2026

Email penawaran, invoice, atau reset password dari domain Anda masuk folder spam, atau malah ditolak dengan pesan bahwa pengirim tidak terautentikasi. Penyebab paling umum bukan isi email, melainkan domain Anda belum membuktikan bahwa email itu benar-benar dikirim olehnya. Tiga record DNS yang melakukan pembuktian itu adalah SPF, DKIM, dan DMARC.

Sejak Gmail dan Yahoo memberlakukan aturan pengirim pada 2024, dan Microsoft Outlook menyusul pada 2025, autentikasi SPF DKIM DMARC bukan lagi praktik tambahan. Artikel ini menjelaskan cara kerja ketiganya dengan bahasa sederhana, contoh record yang bisa Anda salin, batas 10 DNS lookup pada SPF yang sering membuat setting gagal, konsep alignment, cara menaikkan kebijakan DMARC secara bertahap, dan perubahan standar DMARC terbaru tahun 2026.

Kenapa email dari domain Anda masuk spam

Protokol email (SMTP) dirancang tanpa verifikasi pengirim. Siapa pun bisa mengirim email yang mengaku dari admin@tokoanda.id. Inilah yang dimanfaatkan phishing. Penyedia email besar akhirnya menilai: email yang tidak bisa dibuktikan asalnya patut dicurigai.

Ketiga mekanisme bekerja saling melengkapi:

SPF menjawab: apakah server yang mengirim email ini diizinkan oleh domain tersebut?
DKIM menjawab: apakah isi email ini benar-benar ditandatangani oleh domain tersebut dan tidak diubah di perjalanan?
DMARC menjawab: apakah domain di alamat From yang dilihat penerima cocok dengan domain yang lolos SPF atau DKIM, dan apa yang harus dilakukan jika tidak?

Semuanya disimpan sebagai record TXT di DNS domain Anda. Jika Anda belum familier dengan record TXT, baca dulu panduan lengkap DNS record.

SPF: daftar server yang boleh mengirim email

SPF (Sender Policy Framework, RFC 7208) adalah satu record TXT di domain Anda yang berisi daftar server yang sah. Server penerima mengecek alamat IP pengirim terhadap daftar itu.

tokoanda.id.  3600  IN  TXT  "v=spf1 a mx include:_spf.google.com ~all"

Artinya: email sah jika dikirim dari IP di record A domain, dari IP server MX, atau dari server Google Workspace. Selain itu, tandai sebagai softfail.

Komponen record SPF

v=spf1 wajib di awal.
ip4:203.0.113.20 dan ip6:2001:db8::20 mengizinkan IP atau rentang tertentu. Tidak memerlukan DNS lookup.
a dan mx mengizinkan IP dari record A atau MX domain.
include:domain mengikutkan record SPF milik layanan lain (Google Workspace, Microsoft 365, layanan newsletter, aplikasi transaksional).
all di akhir, dengan kualifier: -all (fail, tolak), ~all (softfail, curigai), ?all (netral). Jangan pernah memakai +all, karena itu mengizinkan seluruh internet.

Perlu dipahami, SPF mengecek domain di alamat envelope (Return-Path atau MAIL FROM), bukan alamat From yang terlihat di aplikasi email. Ini alasan SPF saja tidak cukup dan DMARC dibutuhkan.

Batas 10 DNS lookup

Ini kesalahan SPF nomor satu. RFC 7208 bagian 4.6.4 menetapkan bahwa mekanisme yang memicu DNS lookup, yaitu include, a, mx, ptr, exists, dan modifier redirect, totalnya tidak boleh lebih dari 10. Hitungannya termasuk lookup di dalam setiap include secara berantai. Jika lebih, hasil SPF adalah permerror dan banyak penerima memperlakukannya sebagai gagal.

Contoh yang sering terjadi: satu include Microsoft 365, satu Google, satu layanan newsletter, satu CRM, satu helpdesk. Setiap include itu sendiri bisa berisi 2–4 lookup, sehingga total terlampaui tanpa Anda sadari.

Batas lain yang jarang diketahui: RFC 7208 menyarankan void lookup (lookup yang hasilnya kosong atau domainnya tidak ada) dibatasi maksimal dua. Include ke layanan yang sudah Anda hentikan bisa memicu masalah ini.

Cara mengatasinya:

Hapus include dari layanan yang sudah tidak dipakai.
Ganti a dan mx dengan ip4: jika IP-nya statis dan Anda yakin tidak berubah.
Hindari mekanisme ptr; RFC menyatakan mekanisme ini sebaiknya tidak dipublikasikan.
Kirim email pemasaran dari subdomain (misalnya news.tokoanda.id) yang punya record SPF sendiri.
Hati-hati dengan "SPF flattening" (mengganti include dengan daftar IP): jika penyedia mengubah IP-nya, email Anda bisa gagal tanpa peringatan.

Gunakan SPF checker kami untuk melihat jumlah lookup record Anda saat ini beserta status DMARC-nya.

Hanya boleh satu record SPF

Satu domain hanya boleh punya satu record TXT yang diawali v=spf1. Dua record membuat hasil permerror. Saat menambahkan layanan baru, gabungkan ke record yang sudah ada:

Salah:
"v=spf1 include:_spf.google.com ~all"
"v=spf1 include:mailer.example.net ~all"

Benar:
"v=spf1 include:_spf.google.com include:mailer.example.net ~all"

DKIM: tanda tangan digital pada setiap email

DKIM (DomainKeys Identified Mail, RFC 6376) membuat server pengirim menandatangani email dengan kunci privat. Kunci publiknya diletakkan di DNS. Penerima memverifikasi tanda tangan itu: jika cocok, berarti email benar-benar dikirim oleh pemegang kunci dan bagian yang ditandatangani (header penting dan isi) tidak diubah.

Kunci publik disimpan di nama berformat selector._domainkey.domain-anda:

default._domainkey.tokoanda.id.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...IDAQAB"

Selector (di sini default) memungkinkan satu domain memiliki banyak kunci, misalnya google._domainkey untuk Google Workspace dan s1._domainkey untuk layanan newsletter. Header email yang ditandatangani akan berisi d=tokoanda.id; s=default, yang memberi tahu penerima di mana mencari kuncinya.

Tips setting DKIM

Kunci DKIM tidak Anda buat sendiri secara manual. Panel hosting, Google Workspace, Microsoft 365, atau layanan email lainnya membuatkannya; Anda tinggal menyalin record ke DNS.
Gunakan kunci RSA 2048-bit. Google mensyaratkan minimal 1024-bit dan merekomendasikan 2048-bit.
Kunci 2048-bit lebih panjang dari 255 karakter, batas satu string TXT. Record harus dipecah menjadi beberapa string dalam satu record. Kebanyakan panel DNS melakukannya otomatis, tetapi kesalahan copy-paste (spasi atau tanda kutip yang hilang) adalah penyebab umum DKIM gagal.
Pastikan setiap layanan yang mengirim atas nama domain Anda menandatangani dengan domain Anda (d=tokoanda.id), bukan domain milik layanan itu. Ini krusial untuk DMARC.
Rotasi kunci secara berkala dengan selector baru, lalu hapus selector lama setelah tidak dipakai.

DMARC: kebijakan dan laporan untuk domain Anda

DMARC (Domain-based Message Authentication, Reporting, and Conformance) mengikat SPF dan DKIM ke alamat From yang dilihat penerima, lalu memberi tahu penerima apa yang harus dilakukan jika gagal. DMARC juga mengirimkan laporan kepada Anda tentang siapa saja yang mengirim email atas nama domain Anda.

Record DMARC selalu berada di nama _dmarc:

_dmarc.tokoanda.id.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@tokoanda.id"

Tag DMARC yang perlu Anda kenal

p= kebijakan: none (pantau saja), quarantine (masukkan ke spam), reject (tolak).
sp= kebijakan untuk subdomain; jika tidak ada, mengikuti p.
rua= alamat untuk laporan agregat harian berformat XML. Sangat disarankan.
adkim= dan aspf= mode alignment: r (relaxed, default) atau s (strict).
ruf= alamat laporan kegagalan per pesan. Banyak penyedia besar tidak mengirimkannya karena alasan privasi.

Apa itu alignment

Email lolos DMARC jika minimal satu dari berikut terpenuhi:

SPF lolos dan domain Return-Path selaras dengan domain From, atau
DKIM lolos dan domain d= pada tanda tangan selaras dengan domain From.

Dengan mode relaxed, mail.tokoanda.id dianggap selaras dengan tokoanda.id karena berada di domain organisasi yang sama. Dengan mode strict, keduanya harus identik.

Contoh nyata: Anda mengirim newsletter lewat sebuah layanan dengan From promo@tokoanda.id. SPF lolos, tetapi untuk domain Return-Path milik layanan itu (bounce.mailer.example.net). DKIM juga lolos, tetapi ditandatangani d=mailer.example.net. Keduanya lolos, namun tidak selaras, sehingga DMARC gagal. Solusinya: aktifkan custom domain authentication di layanan tersebut agar DKIM memakai d=tokoanda.id.

Dalam praktik, DKIM yang selaras adalah fondasi terpenting, karena SPF sering putus saat email diteruskan (forwarding), sedangkan tanda tangan DKIM biasanya tetap utuh.

Cara menerapkan DMARC bertahap: p=none ke quarantine ke reject

Langsung memasang p=reject pada hari pertama berisiko memblokir email sah dari layanan yang lupa Anda konfigurasi. Lakukan bertahap:

Inventaris. Daftar semua yang mengirim email atas nama domain: email kantor, website (formulir kontak, notifikasi toko online), aplikasi invoice, newsletter, CRM, helpdesk.
Pasang SPF dan DKIM untuk setiap sumber tersebut.
Publikasikan p=none dengan rua. Tidak ada email yang terpengaruh; Anda hanya mulai menerima laporan.
Baca laporan selama minimal beberapa minggu. File XML-nya sulit dibaca manual, jadi gunakan layanan analisis laporan DMARC. Cari sumber sah yang gagal alignment, lalu perbaiki.
Naikkan ke p=quarantine setelah hampir semua email sah lolos. Pantau lagi.
Naikkan ke p=reject setelah yakin. Pada titik ini, email palsu atas nama domain Anda akan ditolak penerima.

Standar DMARC terbaru, RFC 9989, menyarankan pola serupa: p=none setidaknya sebulan, lalu p=quarantine untuk periode yang sama, sebelum p=reject.

Untuk domain yang tidak pernah mengirim email (misalnya domain cadangan), langsung kunci saja:

tokoanda.com.         TXT  "v=spf1 -all"
_dmarc.tokoanda.com.  TXT  "v=DMARC1; p=reject"

Perubahan DMARC 2026: RFC 9989 menggantikan RFC 7489

Pada Mei 2026, IETF menerbitkan DMARC versi baru (sering disebut DMARCbis) sebagai RFC 9989, disertai RFC 9990 untuk laporan agregat dan RFC 9991 untuk laporan kegagalan. RFC 9989 menggantikan RFC 7489 dan statusnya naik menjadi Standards Track. Record lama Anda tetap valid (v=DMARC1 tidak berubah), tetapi ada beberapa perbedaan:

Tag pct dihapus, begitu pula rf dan ri. Sebagai pengganti pct, ada tag t=y (mode uji) yang meminta penerima menerapkan kebijakan satu tingkat lebih lunak: reject diperlakukan sebagai quarantine, dan quarantine sebagai none.
Tag baru np untuk kebijakan subdomain yang tidak ada, berguna melawan pemalsuan dengan subdomain acak.
Tag psd untuk operator public suffix, umumnya tidak perlu Anda pakai.
Domain organisasi ditentukan lewat "DNS tree walk", bukan lagi daftar Public Suffix List.

Tag yang tidak dikenali wajib diabaikan oleh penerima, jadi menambahkan t atau np tidak merusak apa pun. Namun tidak semua penerima langsung menerapkan RFC baru, sehingga jangan bergantung pada perilaku pct maupun t untuk keputusan penting; yang paling aman tetap menaikkan p secara bertahap.

Aturan pengirim Gmail, Yahoo, dan Outlook

Berdasarkan panduan pengirim Google, sejak 1 Februari 2024:

Untuk semua pengirim ke akun Gmail

SPF atau DKIM untuk domain pengirim.
IP pengirim memiliki forward dan reverse DNS (PTR) yang valid.
Koneksi memakai TLS.
Tingkat spam yang dilaporkan pengguna di Postmaster Tools di bawah 0,3%, idealnya di bawah 0,1%.
Format pesan sesuai RFC 5322, dan tidak memalsukan header From Gmail.

Untuk pengirim massal (lebih dari 5.000 email per hari ke Gmail)

SPF dan DKIM.
Record DMARC, minimal p=none.
Domain From selaras dengan domain SPF atau DKIM.
Email pemasaran wajib mendukung one-click unsubscribe (header List-Unsubscribe dan List-Unsubscribe-Post sesuai RFC 8058) serta tautan berhenti berlangganan yang terlihat di isi email.

Google menyatakan mulai November 2025 penegakan diperketat: email yang tidak memenuhi syarat bisa ditolak sementara (kode 4.7.x) atau permanen (5.7.x). Yahoo menerapkan syarat yang hampir sama, termasuk memproses permintaan berhenti berlangganan dalam 2 hari. Microsoft memberlakukan aturan serupa untuk pengirim lebih dari 5.000 email per hari ke Outlook.com, Hotmail, dan Live sejak 5 Mei 2025; email yang tidak patuh bisa ditolak dengan kode 550 5.7.515.

Meski bisnis kecil jarang mencapai 5.000 email per hari, perlakukan syarat pengirim massal sebagai standar. Biayanya hanya beberapa record DNS, dan reputasi domain Anda jauh lebih terlindungi.

Kesalahan umum dan checklist

Kesalahan yang sering terjadi

Dua record SPF, atau SPF melebihi 10 DNS lookup.
Memakai +all atau lupa menambahkan all di akhir.
Website (WordPress, toko online) mengirim email lewat fungsi PHP mail() dari server yang tidak tercantum di SPF dan tanpa DKIM. Gunakan SMTP terautentikasi.
Layanan newsletter menandatangani DKIM dengan domainnya sendiri, sehingga tidak selaras.
Langsung memasang p=reject tanpa membaca laporan.
Record DKIM terpotong saat disalin.
Memasang DMARC di nama yang salah (harus _dmarc, bukan @).

Checklist SPF DKIM DMARC

Inventaris semua layanan pengirim email.
Satu record SPF, maksimal 10 lookup, diakhiri ~all atau -all.
DKIM aktif untuk setiap layanan, dengan d= domain Anda, kunci 2048-bit.
DMARC p=none dengan rua.
Cek hasilnya dengan DNS lookup dan SPF checker.
Kirim email uji ke akun Gmail, buka "Tampilkan asli", pastikan SPF, DKIM, dan DMARC bernilai PASS.
Analisis laporan beberapa minggu, lalu naikkan ke quarantine, kemudian reject.
Pasang SPF -all dan DMARC p=reject di domain yang tidak mengirim email.

Pertanyaan yang sering diajukan

Apakah cukup memasang SPF saja?

Tidak. SPF hanya memeriksa server pengirim berdasarkan alamat envelope, tidak melindungi alamat From yang dilihat penerima, dan sering gagal saat email diteruskan. Gmail mewajibkan SPF dan DKIM serta DMARC untuk pengirim massal, dan ketiganya sebaiknya dipasang oleh semua domain bisnis.

Pilih ~all atau -all?

Keduanya dapat diterima. Banyak administrator memakai ~all selama masa transisi, lalu mengandalkan DMARC untuk penegakan. Gunakan -all jika Anda yakin semua sumber pengirim sudah tercantum, dan selalu gunakan -all untuk domain yang tidak pernah mengirim email.

Berapa lama sebaiknya DMARC berada di p=none?

Minimal beberapa minggu, sampai laporan menunjukkan semua sumber email sah sudah lolos dengan alignment. RFC 9989 menyarankan setidaknya satu bulan di p=none dan periode serupa di p=quarantine sebelum p=reject.

Kenapa DMARC gagal padahal SPF dan DKIM lolos?

Hampir pasti karena tidak selaras: SPF lolos untuk domain Return-Path milik layanan pihak ketiga, dan DKIM ditandatangani dengan domain layanan tersebut. Aktifkan autentikasi domain kustom di layanan itu agar DKIM memakai domain Anda.

Apakah record DMARC lama dengan pct masih berfungsi?

Record tetap valid karena versinya tetap v=DMARC1. RFC 9989 menghapus tag pct, sehingga penerima yang mengikuti standar baru akan mengabaikannya; jangan mengandalkan pct untuk penerapan bertahap.

Apakah email dari hosting otomatis sudah memenuhi syarat?

Tergantung penyedianya. Pastikan record SPF, DKIM, dan DMARC benar-benar terpasang di DNS domain Anda, bukan hanya di panel email, lalu verifikasi dengan email uji ke Gmail.

Langkah berikutnya

Mulailah dengan mengecek domain Anda di SPF checker: Anda akan langsung melihat jumlah DNS lookup dan apakah DMARC sudah terpasang. Jika Anda membutuhkan email dengan domain sendiri yang mudah diatur autentikasinya, lihat paket hosting kami, atau hubungi tim kami jika butuh bantuan memeriksa record Anda.