Cara Mengatur SPF, DKIM, dan DMARC untuk Cold Email, Langkah demi Langkah

Jika Anda mengirim cold email dari domain Anda sendiri, tiga catatan DNS menentukan apakah server penerima percaya bahwa email itu benar-benar berasal dari Anda: SPF, DKIM, dan DMARC. Tanpa ketiganya, bahkan email pertama yang ditulis dengan baik pun bisa disaring sebelum ada yang membacanya.

Panduan ini ditujukan bagi pendiri usaha dan tim penjualan yang mengirim email prospek dari alamat seperti you@yourcompany.com, biasanya lewat Google Workspace. Kami (Outreach) membahas setiap catatan sesuai urutan pengaturannya, menampilkan format catatan persis seperti yang dipublikasikan halaman bantuan Google dan RFC, serta menunjukkan kesalahan yang membuat sebuah catatan tampak benar padahal diam-diam gagal.

Anda tidak perlu menjadi ahli DNS. Anda membutuhkan akses ke pengaturan DNS domain Anda (di registrar atau host DNS Anda) dan, untuk DKIM, akses admin ke Google Workspace.

Apa itu SPF, DKIM, dan DMARC, masing-masing dalam satu kalimat?

SPF mencantumkan server yang diizinkan mengirim email untuk domain Anda, DKIM menambahkan tanda tangan kriptografi yang membuktikan bahwa sebuah pesan tidak dipalsukan atau diubah, dan DMARC memberi tahu penerima apa yang harus dilakukan ketika sebuah pesan gagal dalam pemeriksaan tersebut. Ketiganya dipublikasikan sebagai catatan TXT di DNS domain Anda.

Ketiganya bekerja bersama. SPF dan DKIM masing-masing hanya membuktikan hal yang sempit; DMARC mengaitkan bukti-bukti itu dengan alamat yang benar-benar dilihat orang di baris From.

Apakah catatan ini benar-benar wajib untuk cold email?

Ya — setidaknya SPF atau DKIM wajib bagi setiap pengirim ke Gmail dan Yahoo, dan pengirim massal membutuhkan ketiganya. Ini bukan sekadar saran praktik terbaik; ini tercantum dalam aturan pengirim yang dipublikasikan kedua penyedia.

Pedoman pengirim email Google menyatakan bahwa semua pengirim harus "menyiapkan autentikasi email SPF atau DKIM untuk domain pengirim Anda." Pengirim yang mengirim "lebih dari 5.000 pesan per hari ke akun Gmail" juga harus "menyiapkan SPF dan DKIM" serta "autentikasi email DMARC untuk domain pengirim Anda," dan domain From harus selaras dengan domain SPF atau DKIM. Aturan ini berlaku sejak 1 Februari 2024.

Praktik terbaik Sender Hub Yahoo sejalan: setiap pengirim harus "menerapkan SPF atau DKIM sebagai persyaratan minimum," dan pengirim massal harus "menerapkan SPF dan DKIM sekaligus" serta "memublikasikan kebijakan DMARC yang valid dengan minimal p=none."

Program cold email kecil mungkin tidak pernah mencapai 5.000 pesan per hari. Tetap siapkan ketiganya: tidak dikenai biaya, hanya butuh satu sore, dan Anda tidak perlu mencari tahu di mana batasnya.

Bagaimana cara mengatur SPF?

Tambahkan satu catatan TXT di domain utama Anda yang diawali dengan v=spf1, mencantumkan setiap layanan yang mengirim email atas nama Anda, dan diakhiri dengan ~all. Untuk domain yang hanya mengirim lewat Google Workspace, halaman penyiapan SPF Google memberikan catatan persis seperti ini:

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

Langkah-langkahnya:

1. Masuk ke pengaturan DNS di host domain Anda.
2. Buat catatan TXT. Pada kolom host atau nama, Google menyarankan untuk memasukkan @ jika Anda menambahkannya ke domain utama, bukan ke subdomain.
3. Tempelkan catatan tersebut sebagai nilai, lalu simpan.
4. Tunggu. Google mencatat, "Diperlukan waktu hingga 48 jam agar autentikasi SPF mulai bekerja."

Jika layanan lain juga mengirim email dari domain Anda — alat newsletter, CRM, atau layanan email transaksional — masing-masing membutuhkan include: sendiri di catatan yang sama. Halaman Google memberikan contoh gabungan berikut:

v=spf1 include:_spf.google.com include:amazonses.com ~all
v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all
v=spf1 include:_spf.google.com include:_spf.salesforce.com ~all

Gunakan nilai include yang didokumentasikan oleh masing-masing layanan pengirim; jangan menebaknya.

Haruskah catatan SPF diakhiri dengan ~all atau -all?

Panduan penyiapan Google memakai ~all, dan itulah pilihan bawaan yang aman selagi Anda masih mencari tahu setiap layanan yang mengirim email atas nama Anda. Kedua akhiran itu memiliki arti berbeda dalam RFC 7208, standar SPF:

• ~all (softfail) adalah "Pernyataan lemah dari ADMD penerbit bahwa host tersebut kemungkinan besar tidak diotorisasi."
• -all (fail) adalah "Pernyataan eksplisit bahwa klien tidak diotorisasi untuk menggunakan domain pada identitas yang diberikan."

Dengan -all, layanan pengirim yang Anda lupa sertakan akan mengalami kegagalan keras. Setelah DMARC terpasang dan laporannya menunjukkan setiap sumber yang sah lolos, akhiran SPF menjadi kurang penting, karena kebijakan DMARC menjadi instruksi yang diikuti penerima.

Mengapa SPF rusak jika terlalu banyak include?

Karena satu pemeriksaan SPF hanya boleh memicu paling banyak 10 pencarian DNS; jika lebih dari itu, seluruh hasilnya menjadi error. RFC 7208, bagian 4.6.4 menyatakan bahwa implementasi "HARUS membatasi jumlah total istilah tersebut hingga 10 selama evaluasi SPF" dan "Jika batas ini terlampaui, implementasi HARUS mengembalikan 'permerror.'"

Istilah yang dihitung adalah include, a, mx, ptr, exists, dan pengubah redirect. Yang terpenting, hitungan ini mencakup seluruh evaluasi — sehingga include: yang di dalamnya berisi include lain menghabiskan beberapa dari 10 jatah Anda. Halaman Google sendiri menuliskannya sebagai "Catatan SPF dapat memiliki maksimum 10 tag include"; RFC adalah pembacaan yang lebih ketat karena pencarian bersarang juga dihitung.

Jika selama bertahun-tahun Anda menambahkan beberapa alat penjualan dan pemasaran, hapus yang tidak lagi Anda pakai sebelum menambahkan include baru.

Apa yang terjadi jika sebuah domain memiliki dua catatan SPF?

SPF gagal dengan error — dua catatan dianggap sebagai konfigurasi yang rusak, bukan sebagai dua daftar yang digabungkan. RFC 7208 menyatakan bahwa jika lebih dari satu catatan v=spf1 ada untuk sebuah domain, pemeriksaan tersebut "menghasilkan hasil 'permerror'."

Salah satu penyebab yang umum: seseorang menambahkan catatan TXT kedua untuk alat baru alih-alih mengedit catatan yang sudah ada. Solusinya adalah menggabungkannya menjadi satu catatan dengan beberapa istilah include:, seperti pada contoh di atas.

Bagaimana cara mengaktifkan DKIM di Google Workspace?

Buat kunci di konsol Admin, publikasikan sebagai catatan TXT di google._domainkey, lalu klik "Mulai otentikasi." Halaman penyiapan DKIM Google menjelaskan jalurnya:

1. Di konsol Google Admin, buka Aplikasi > Google Workspace > Gmail > Autentikasi email. (Anda memerlukan hak istimewa administrator Setelan Gmail.)
2. Pilih domain dan buat catatan baru.
3. Pilih panjang kunci. Google menyarankan memilih 2048 "Jika penyedia domain Anda mendukung kunci 2048-bit" karena "Kunci yang lebih panjang lebih aman daripada kunci yang lebih pendek," dan 1024 hanya "Jika host domain Anda tidak mendukung kunci 2048-bit."
4. Pertahankan pemilih awalan (selector) default, google — Google menyebutnya "opsi yang direkomendasikan" untuk Workspace.
5. Google menampilkan nama host DNS, google._domainkey, dan nilai TXT yang diawali dengan v=DKIM1. Salin keduanya ke catatan TXT baru di host DNS Anda.
6. Kembali di konsol Admin, klik Mulai otentikasi.

Nilai TXT yang dihasilkan Google berbentuk seperti ini (kuncinya sendiri adalah string panjang yang unik untuk domain Anda):

v=DKIM1; k=rsa; p=MIIBIjANBgkqh...(your public key continues)

Waktu: Google menyatakan "diperlukan waktu hingga 48 jam agar autentikasi DKIM mulai bekerja" setelah Anda menambahkan kunci. Jika Anda baru saja menyiapkan Gmail untuk domain baru, Google mencatat bahwa Anda "harus menunggu 24–72 jam" sebelum kunci DKIM bahkan tersedia di konsol Admin.

Jika layanan lain mengirim email atas nama Anda, layanan itu akan memberi Anda catatan DKIM sendiri dengan selector sendiri. Publikasikan juga catatan itu — beberapa kunci DKIM dengan selector berbeda dapat berdampingan, tidak seperti SPF.

Bagaimana cara mengatur DMARC tanpa memblokir email Anda sendiri?

Publikasikan catatan TXT di _dmarc.yourcompany.com dengan p=none terlebih dahulu, baca laporannya, dan baru kemudian perketat kebijakannya. Halaman penyiapan DMARC Google menyatakan: "Saat Anda mulai menggunakan DMARC, sebaiknya tetapkan opsi kebijakan (p) ke none." Google juga menyarankan Anda untuk "menunggu selama 48 jam setelah menyiapkan SPF dan/atau DKIM sebelum menyiapkan DMARC."

Halaman Google memberikan contoh catatan lengkap berikut:

v=DMARC1; p=reject; rua=mailto:postmaster@example.com, mailto:dmarc@example.com; pct=100; adkim=s; aspf=s

Contoh itu menunjukkan kondisi akhir yang paling ketat. Untuk catatan pertama, format yang sama dengan kebijakan pemantauan dan satu alamat laporan sudah cukup — misalnya v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com. Tag rua mengirim laporan agregat ke kotak surat itu; Google merekomendasikan kotak surat atau grup khusus, karena laporan bisa datang dalam jumlah besar.

Tiga nilai kebijakan, sebagaimana didefinisikan dalam spesifikasi DMARC:

Satu domain hanya mendapat satu catatan DMARC. Menurut RFC 9989, jika beberapa catatan DMARC dikembalikan, "semuanya dibuang" — artinya tidak ada kebijakan yang berlaku sama sekali.

Apa arti "keselarasan" (alignment), dan mengapa DMARC gagal padahal SPF lolos?

DMARC hanya lolos jika SPF atau DKIM lolos untuk domain yang cocok dengan alamat From yang dilihat orang. SPF bisa lolos untuk domain milik layanan pengirim Anda sendiri sementara baris From menampilkan domain Anda — dan DMARC tetap gagal, karena domain yang lolos itu tidak selaras.

Spesifikasi DMARC menyatakan bahwa sebuah pesan lolos jika setidaknya satu metode autentikasi menghasilkan status lolos "berdasarkan pengenal yang selaras" (RFC 7489, yang kini dilanjutkan dalam RFC 9989). Secara bawaan, keselarasan bersifat longgar (adkim dan aspf bernilai bawaan r): mail.yourcompany.com dan yourcompany.com dianggap cocok karena keduanya berbagi domain organisasi yang sama. Mode ketat (s), seperti pada contoh Google, mengharuskan kecocokan persis.

Dalam praktiknya, inilah alasan DKIM sangat penting untuk cold email: ketika layanan pengirim Anda menandatangani dengan domain Anda, keselarasan DKIM lolos meskipun keselarasan SPF tidak.

Apakah standar DMARC berubah pada 2026?

Ya. RFC 9989, yang dipublikasikan pada Mei 2026 sebagai dokumen Standards Track, menggantikan RFC 7489 yang asli — dan RFC ini menghapus tag pct. Catatan v=DMARC1 yang sudah ada tetap berfungsi.

Perubahan utama yang akan disadari sebagian besar pengirim: pct (menerapkan kebijakan hanya pada sebagian persentase email yang gagal) sudah dihapus. RFC menjelaskan bahwa "Pengalaman operasional menunjukkan bahwa tag 'pct' biasanya tidak diterapkan secara akurat, kecuali nilai yang ditentukan adalah 0 atau 100." Sebagai gantinya ada flag pengujian, t=y, yang meminta penerima untuk tidak menerapkan kebijakan yang Anda nyatakan selama Anda mengujinya.

Halaman bantuan Google masih menampilkan pct=100 dalam contohnya. Itu tidak merusak apa pun: RFC 9989 menyatakan "tag yang tidak dikenal HARUS diabaikan," sehingga sisa pct itu dilewati begitu saja. Saat Anda berikutnya mengedit catatan, Anda dapat menghapusnya.

Bagaimana cara memeriksa bahwa semuanya berfungsi?

Cari catatan yang sudah Anda publikasikan, lalu kirim pesan nyata ke alamat Gmail dan baca hasil autentikasinya. Dua pemeriksaan cepat:

1. Cari catatan DNS. Pemeriksa gratis kami mencari catatan SPF, DKIM, dan DMARC untuk domain dari alamat yang Anda masukkan — tanpa perlu mendaftar. Pemeriksa ini memeriksa selector DKIM default Google (google._domainkey); jika layanan pengirim Anda memakai selector lain, pemeriksa akan melaporkan DKIM sebagai belum terkonfirmasi meskipun sudah disiapkan. Alat ini tersedia dalam bahasa Inggris dan Korea; masukkan alamat email pengirim Anda.
2. Periksa pesan nyata. Kirim email ke akun Gmail yang Anda kendalikan, buka email tersebut, pilih "Tampilkan versi asli," lalu cari SPF: PASS, DKIM: PASS, dan DMARC: PASS.

Setelah itu, beri waktu satu atau dua minggu untuk laporan DMARC. Ketika setiap sumber sah yang Anda gunakan tampak lolos, beralihlah dari p=none ke p=quarantine, dan kemudian ke p=reject jika Anda menginginkan perlindungan terkuat terhadap pemalsuan.

Kesalahan apa yang paling sering merusak autentikasi?

Dua catatan SPF, terlalu banyak pencarian SPF, DKIM yang dibuat tetapi tidak pernah dimulai, dan DMARC yang dipublikasikan sebelum SPF dan DKIM sempat bekerja. Daftar periksa:

• Satu catatan SPF, dengan setiap pengirim sebagai include: di dalamnya, dan tidak lebih dari 10 istilah pencarian.
• Klik "Mulai otentikasi" setelah memublikasikan kunci DKIM — catatan DNS saja tidak cukup.
• Tunggu sekitar 48 jam setelah SPF dan DKIM sebelum menambahkan DMARC, dan publikasikan di _dmarc, bukan di domain utama.
• Kirim dari domain yang Anda kendalikan. Anda tidak dapat memublikasikan DMARC untuk alamat @gmail.com.

Autentikasi membuat email Anda dipertimbangkan; autentikasi tidak membuat penerima menginginkannya. Keluhan spam tetap diperhitungkan — Google dan Yahoo sama-sama menyatakan agar tingkat spam Anda tetap di bawah 0.3%, seperti yang kami bahas di mengapa cold email masuk spam. Selain itu, mengirim ke alamat yang tidak ada menghasilkan email terpental, itulah sebabnya kami menyarankan Anda memverifikasi alamat sebelum mengirim.

Versi singkatnya

• Google dan Yahoo mewajibkan SPF atau DKIM dari setiap pengirim, dan ketiganya plus keselarasan dari pengirim massal (5.000+ pesan per hari ke Gmail).
• SPF: satu catatan TXT di @, misalnya v=spf1 include:_spf.google.com ~all; tetap dalam batas 10 istilah pencarian DNS.
• DKIM: kunci 2048-bit, selector google, TXT di google._domainkey, lalu Mulai otentikasi.
• DMARC: satu catatan TXT di _dmarc, mulai dari p=none dengan alamat laporan, perketat kemudian. RFC 9989 (Mei 2026) mengganti pct dengan t=y.
• Periksa catatan Anda dengan pemeriksa autentikasi email gratis kami, lalu konfirmasikan pada pesan nyata.