Keamanan dan Data

Email Berdomain Usaha: Memasang SPF, DKIM, dan DMARC agar Pesan Dipercaya

Daftar semua layanan yang mengirim atas nama domain, pasang satu rekaman SPF dan kunci DKIM, lalu naikkan DMARC bertahap. Termasuk perubahan RFC 9989 tentang tag pct dan persyaratan pengirim Gmail.

18 menit baca
Ilustrasi AI: perempuan berambut digelung dan bercelemek cokelat mengetik di laptop yang layarnya berisi blok biru, abu-abu, dan oranye, di samping kotak kardus kiriman, amplop, dan kartu putih kosong
Ilustrasi AI: pemilik usaha rumahan menyiapkan email usaha di antara paket kiriman; alamat berdomain sendiri perlu rekaman DNS agar penerima bisa memastikan keasliannya.

Sejak 1 Februari 2024, Gmail mewajibkan setiap pengirim yang mengirim email ke akun Gmail pribadi untuk menyiapkan setidaknya SPF atau DKIM di domain pengirimnya. FAQ panduan pengirim email Google menambahkan bahwa mulai November 2025 Gmail memperketat penegakan terhadap lalu lintas yang tidak mematuhi aturan, dengan gangguan berupa penolakan sementara maupun permanen. Bagi usaha kecil yang baru memakai alamat seperti pesanan@namausaha.co.id, artinya jelas: membeli domain dan membuat kotak surat belum cukup. Tiga rekaman teks di DNS, yaitu SPF, DKIM, dan DMARC, menentukan apakah server penerima bisa memastikan bahwa email itu benar-benar dikirim oleh pemilik domain, bukan oleh orang yang meminjam namanya.

Semua ketentuan di bawah ini diambil dari Panduan pengirim email di Bantuan Gmail, halaman SPF, DKIM, dan DMARC di Bantuan Google Workspace, serta dokumen standar di rfc-editor.org, per pemeriksaan 17 Oktober 2026. Satu perubahan besar perlu dicatat sejak awal: RFC 7489, dokumen DMARC yang selama ini dirujuk banyak tutorial, sudah digantikan oleh RFC 9989 yang terbit Mei 2026 sebagai dokumen jalur standar. Dampaknya pada cara meluncurkan DMARC secara bertahap dibahas di bagian DMARC.

Tiga rekaman, tiga pertanyaan yang berbeda

Ketiganya sering disebut bersamaan, padahal masing-masing menjawab pertanyaan yang berlainan. SPF, yang diatur RFC 7208, menjawab: server mana saja yang diizinkan mengirim email atas nama domain ini? Halaman “Menyiapkan SPF” di Bantuan Google Workspace menyebut data SPF harus mencantumkan semua server yang mengirim email untuk domain, dan server penerima memeriksanya untuk memastikan pesan berasal dari server resmi.

DKIM, yang diatur RFC 6376, menjawab: apakah isi dan kepala pesan ini benar ditandatangani oleh pemegang domain dan tidak diubah di perjalanan? Caranya dengan sepasang kunci. Kunci privat disimpan di server pengirim dan dipakai menandatangani setiap pesan keluar; kunci publik diletakkan di DNS agar server penerima bisa memeriksa tanda tangan itu.

DMARC menjawab pertanyaan ketiga: kalau sebuah pesan mengaku dari domain ini tetapi tidak lulus pemeriksaan, apa yang sebaiknya dilakukan penerima, dan ke mana laporannya dikirim? Panduan pengirim Gmail menjelaskan syarat lulusnya: pesan harus diautentikasi dengan SPF atau DKIM, dan domain yang diautentikasi harus sama dengan domain yang muncul di kepala “From:”. Syarat kesamaan inilah yang disebut penyelarasan (alignment). Sebuah pesan bisa lulus SPF karena dikirim lewat server layanan buletin yang sah, tetapi tetap gagal DMARC bila domain yang lulus SPF adalah domain milik layanan itu, bukan domain usaha di kolom From.

Sebelum membuka panel DNS: daftar semua yang mengirim atas nama domain

Kesalahan paling umum bukan salah ketik, melainkan lupa bahwa ada pengirim lain. Halaman SPF Google Workspace memberi daftar yang perlu diperiksa: server web, server email lokal, server email penyedia hosting, gateway keluar, layanan yang mengirim email otomatis seperti formulir kontak di situs, dan semua penyedia pihak ketiga yang mengirim email untuk domain. Untuk usaha kecil, daftarnya biasanya lebih pendek tetapi tetap sering terlewat satu atau dua.

Contoh rekaan: toko kue rumahan fiktif “Kue Sekar” memakai domain rekaan kuesekar.example. Kotak surat pemilik dan admin berada di Google Workspace. Situs toko berjalan di hosting yang mengirim notifikasi pesanan lewat formulir web. Sebulan sekali, pemilik mengirim kabar menu baru lewat layanan buletin email. Aplikasi kasir daring mengirim nota ke email pelanggan dengan alamat nota@kuesekar.example. Ada empat pengirim, dan keempatnya harus masuk hitungan sebelum satu rekaman pun dibuat. Bila aplikasi kasir lupa didaftarkan, nota pelanggan bisa masuk spam atau ditolak begitu kebijakan DMARC diperketat.

Cara cepat menyusun daftar ini: kumpulkan semua email yang pernah dikirim dari domain usaha dalam tiga bulan terakhir, termasuk email otomatis, lalu lihat dari layanan mana masing-masing dikirim. Untuk tiap layanan, buka dokumentasinya dan cari kata “SPF”, “DKIM”, atau “domain authentication”. Sebagian besar layanan pengiriman memberi nilai include untuk SPF dan rekaman DKIM sendiri yang harus ditambahkan ke DNS usaha.

Contoh rekaman untuk domain rekaan

Tabel berikut memakai domain rekaan kuesekar.example. Menurut RFC 2606, akhiran .example termasuk nama yang dicadangkan untuk dokumentasi dan contoh, sehingga nilai di tabel tidak akan bertabrakan dengan domain sungguhan. Ganti nama domain, alamat laporan, dan nilai include dengan milik sendiri; nilai include untuk Google Workspace dan layanan buletin diambil dari tabel contoh di halaman SPF Google Workspace.

Tahap Jenis Host atau Nama Nilai (contoh rekaan untuk kuesekar.example) Catatan
1. SPF TXT @ v=spf1 include:_spf.google.com include:servers.mcsv.net ~all Satu rekaman SPF saja untuk domain ini; tambahkan include pengirim lain di baris yang sama
2. DKIM Google Workspace TXT google._domainkey v=DKIM1; k=rsa; p=(kunci publik panjang yang disalin dari konsol Admin) Pilih kunci 2048 bit bila penyedia DNS mendukung
3. DKIM layanan lain TXT atau CNAME Sesuai petunjuk layanan Sesuai petunjuk layanan Pemilih (selector) harus berbeda dari google
4. DMARC pemantauan TXT _dmarc v=DMARC1; p=none; rua=mailto:laporan-dmarc@kuesekar.example Dipasang setidaknya 48 jam setelah SPF dan DKIM aktif
5. DMARC karantina sebagian TXT (mengganti tahap 4) _dmarc v=DMARC1; p=quarantine; pct=10; rua=mailto:laporan-dmarc@kuesekar.example Setelah laporan minimal satu minggu bersih
6. DMARC penuh TXT (mengganti tahap 5) _dmarc v=DMARC1; p=reject; rua=mailto:laporan-dmarc@kuesekar.example Hanya bila semua pengirim sah sudah lulus dan selaras

Kolom Host di banyak panel DNS diisi dengan simbol @ untuk domain utama. Halaman SPF Google menyebut nilainya bisa juga ditulis sebagai nama domain lengkap bila panel memintanya, dan sebagian penyedia mengharuskan nilai SPF diapit tanda kutip. Karena tampilan panel berbeda-beda, ikuti petunjuk penyedia domain masing-masing untuk bentuk penulisannya, tetapi isi rekamannya tetap sama.

Ilustrasi AI: laptop biru tertutup di meja kayu dikelilingi dua amplop krem dan dua kartu putih yang dihubungkan tali biru, masing-masing bersegel lilin oranye
Ilustrasi AI: setiap amplop dan kartu tersambung ke laptop dan disegel, kiasan pesan yang ditandatangani DKIM dan dikirim dari server yang tercantum di SPF.

SPF: satu rekaman, paling banyak sepuluh pencarian

Aturan pertama ada di RFC 7208 bagian 3.2: sebuah nama domain tidak boleh memiliki beberapa rekaman yang membuat pemeriksaan otorisasi memilih lebih dari satu rekaman. Dalam praktik, ini berarti satu domain hanya boleh punya satu rekaman TXT yang diawali v=spf1. Kekeliruan yang sering terjadi adalah penyedia hosting sudah membuat rekaman SPF bawaan, lalu pemilik menambahkan rekaman SPF kedua untuk Google Workspace. Hasilnya dua rekaman, dan pemeriksaan SPF justru gagal. Yang benar adalah menggabungkan semua include ke dalam satu rekaman.

Aturan kedua adalah batas pencarian DNS. RFC 7208 menetapkan batas keseluruhan 10 mekanisme dan pengubah yang memicu pencarian DNS selama evaluasi SPF; halaman Google Workspace menuliskannya dengan lebih sederhana sebagai maksimum 10 tag include. Setiap include milik layanan pihak ketiga bisa berisi include lain di dalamnya, jadi usaha yang menambahkan layanan demi layanan bisa melampaui batas tanpa sadar. Bila jumlahnya mendekati sepuluh, tinjau apakah semua layanan itu masih dipakai. Google sendiri menyarankan menghapus domain atau alamat IP yang tidak lagi digunakan untuk mengirim email.

Akhiran rekaman menentukan sikap terhadap server yang tidak tercantum. Menurut RFC 7208, kualifikasi “~” menghasilkan softfail, yaitu pernyataan lemah bahwa server itu mungkin tidak berwenang, sedangkan “-” menghasilkan fail, pernyataan tegas bahwa server itu tidak berwenang. Google merekomendasikan ~all dalam data SPF. Untuk usaha kecil yang belum yakin semua pengirimnya tercatat, ~all adalah pilihan yang lebih aman; ketegasan terhadap pemalsu diserahkan kepada DMARC, yang bisa dinaikkan bertahap.

Dua catatan lagi dari halaman Google Workspace. Setiap subdomain yang mengirim email memerlukan rekaman SPF sendiri, dan setiap domain lain yang dimiliki usaha juga harus punya rekaman sendiri. Selain itu, autentikasi SPF bisa memerlukan waktu hingga 48 jam untuk mulai bekerja, jadi jangan menyimpulkan gagal hanya karena pemeriksaan satu jam kemudian belum lulus.

DKIM: kunci publik di DNS, kunci privat di server

RFC 6376 bagian 3.6.2.1 menetapkan bahwa semua kunci DKIM disimpan di subdomain bernama _domainkey. Nama lengkap rekamannya terdiri dari pemilih (selector), diikuti ._domainkey, lalu nama domain. Pemilih memungkinkan satu domain memakai beberapa kunci sekaligus, misalnya satu untuk Google Workspace dan satu untuk layanan buletin, tanpa saling menimpa.

Untuk Google Workspace, halaman “Menyiapkan DKIM” menjelaskan urutannya. Administrator super membuka konsol Google Admin, masuk ke Aplikasi, Google Workspace, Gmail, lalu Autentikasi email; memilih domain; dan mengklik Buat Data Baru. Panjang kunci yang dianjurkan 2048 bit bila penyedia domain mendukungnya, dengan 1024 bit sebagai pilihan bila tidak. Pemilih bawaan adalah google. Konsol kemudian menampilkan nama host DNS dan nilai rekaman TXT berbentuk v=DKIM1; k=rsa; p= diikuti kunci. Halaman itu memberi tiga peringatan yang sering menjebak. Setelah Gmail diaktifkan untuk organisasi, kunci DKIM baru bisa dibuat setelah 24 sampai 72 jam. Jangan mengklik Mulai Autentikasi sebelum rekaman ditambahkan ke DNS. Pesan “Anda harus memperbarui data DNS” di konsol bisa tetap tampil hingga 48 jam meskipun rekaman sudah benar.

Panjang kunci juga merupakan syarat Gmail. Panduan pengirim email menyebut pengiriman ke akun Gmail pribadi mewajibkan kunci DKIM 1024 bit atau lebih, dan menyarankan 2048 bit bila penyedia domain mendukungnya. Sebagian panel DNS membatasi panjang satu baris teks, sehingga kunci 2048 bit perlu dipecah menjadi beberapa potongan dalam satu rekaman; RFC 6376 menetapkan bahwa potongan-potongan teks dalam satu rekaman TXT digabung tanpa spasi sebelum dipakai. Bila panel menolak kunci panjang, tanyakan cara memasukkannya kepada penyedia domain sebelum memilih kunci 1024 bit.

Layanan di luar Google Workspace memiliki kunci sendiri. Layanan buletin, aplikasi kasir, atau platform toko daring biasanya menyediakan menu autentikasi domain yang menghasilkan satu atau beberapa rekaman, kadang berupa CNAME, bukan TXT. Tambahkan rekaman itu persis seperti petunjuknya. Bila sebuah layanan tidak menyediakan DKIM dengan domain usaha sama sekali, pertimbangkan apakah email dari layanan itu sebaiknya memakai subdomain terpisah atau dikirim lewat server lain yang bisa diautentikasi.

DMARC bertahap: dari memantau ke menolak

DMARC adalah rekaman yang paling berisiko bila dipasang terburu-buru, karena kebijakan yang terlalu ketat bisa membuat email sah ikut ditolak. Halaman “Menyiapkan DMARC” di Google Workspace meminta SPF dan/atau DKIM sudah aktif sebelum DMARC dipakai, dan menyarankan menunggu 48 jam setelah keduanya disiapkan. Rekaman DMARC diletakkan di host _dmarc. Tag v dan p harus dicantumkan paling depan; tag lain boleh dalam urutan apa pun.

Halaman “Rekomendasi peluncuran DMARC” menyusun tahapannya. Mulailah dengan kebijakan p=none selama satu minggu: pesan dikirim seperti biasa dan tidak ada risiko ditolak, sementara laporan DMARC ditinjau setiap hari untuk menemukan pengirim yang belum lulus. Setelah setidaknya seminggu tanpa masalah, beralih ke p=quarantine untuk sebagian kecil pesan; pesan yang gagal DMARC dialihkan ke folder spam penerima. Google memberi contoh organisasi kecil memulai dengan 10 persen, sedangkan organisasi besar dengan 1 persen, lalu menaikkan persentasenya bertahap hingga 100 persen. Tahap akhirnya p=reject, yang membuat pesan yang gagal ditolak dan tidak dikirimkan.

Tag pct dan perubahan dalam RFC 9989

Persentase itu diatur dengan tag pct, yang di halaman Google didefinisikan sebagai bilangan bulat 1 sampai 100 dan dianjurkan disertakan saat peluncuran. Di sinilah ada perbedaan dengan standar terbaru. RFC 9989 yang terbit Mei 2026 menghapus tag pct dan menandainya sebagai historis. Lampiran A.6 dokumen itu menjelaskan alasannya: pengalaman operasional menunjukkan tag pct jarang diterapkan secara akurat kecuali bernilai 0 atau 100, dan ketidakakuratan untuk nilai lain sangat bervariasi antarpenerima. Sebagai gantinya, RFC 9989 memperkenalkan tag t untuk mode uji. Dengan t=y, penerima diminta menerapkan kebijakan satu tingkat di bawah yang tertulis: quarantine diperlakukan sebagai none, dan reject diperlakukan sebagai quarantine.

Bagi pemilik usaha, perbedaan ini tidak perlu membingungkan. Prinsip bertahapnya sama: pantau dulu, perketat perlahan, dan baru menolak setelah semua pengirim sah terbukti lulus. Per pemeriksaan 17 Oktober 2026, halaman Google Workspace masih memakai pct dalam contoh peluncurannya, sementara standar baru memakai t. Penerima yang belum menerapkan RFC 9989 akan mengabaikan tag t, dan penerima yang sudah menerapkannya akan mengabaikan pct. Karena itu, tahap karantina sebagian sebaiknya diperlakukan sebagai masa uji yang hasilnya tidak bisa diukur persis, bukan sebagai pembagian persentase yang pasti. Ukuran kesiapan yang lebih bisa diandalkan adalah laporan agregat: bila selama beberapa minggu semua sumber sah sudah lulus dan selaras, kebijakan boleh dinaikkan.

Tag lain yang perlu diketahui: rua menentukan alamat penerima laporan agregat, dan Google menyarankan selalu menyertakannya. Laporan bisa datang dalam jumlah banyak setiap hari, jadi Google menganjurkan kotak surat atau grup khusus, bukan kotak surat pribadi pemilik. Gmail tidak mendukung tag ruf untuk laporan kegagalan per pesan. Bila usaha kelak memakai BIMI untuk menampilkan logo di kotak masuk, halaman yang sama menyebut kebijakan p harus quarantine atau reject.

Membaca laporan agregat tanpa tenggelam di dalamnya

Laporan agregat DMARC dikirim penerima sebagai berkas lampiran berformat XML yang sulit dibaca langsung. Untuk usaha kecil, ada dua pilihan praktis: memakai alat pembaca laporan gratis atau berbayar yang mengubah XML menjadi tabel, atau membuka berkasnya dengan penampil XML dan hanya membaca bagian yang penting. Yang dicari dalam setiap laporan sebenarnya sedikit: alamat IP atau nama server pengirim, jumlah pesan, hasil SPF dan DKIM, serta apakah domain yang lulus selaras dengan domain di kolom From.

Polanya biasanya mudah dikenali. Sumber yang mengirim banyak pesan dan lulus keduanya adalah server Google Workspace. Sumber yang mengirim puluhan pesan seminggu dan gagal penyelarasan bisa jadi layanan buletin atau aplikasi kasir yang belum diberi DKIM dengan domain usaha. Sumber tak dikenal dari negara yang tidak ada hubungannya dengan usaha, dengan pesan yang gagal semua pemeriksaan, adalah kandidat pemalsuan, dan justru itulah yang ingin dihentikan dengan kebijakan reject. Catat setiap sumber sah yang gagal, perbaiki rekamannya, lalu tunggu laporan minggu berikutnya sebelum mengubah kebijakan.

Persyaratan Gmail yang menyentuh usaha kecil

Panduan pengirim email membagi persyaratan menjadi dua kelompok. Untuk semua pengirim ke akun Gmail pribadi (alamat berakhiran @gmail.com atau @googlemail.com), syaratnya: SPF atau DKIM untuk domain pengirim; data DNS maju dan balik (PTR) yang valid untuk domain atau IP pengirim; koneksi TLS; rasio spam yang dilaporkan di Postmaster Tools di bawah 0,3 persen; format pesan sesuai RFC 5322; dan tidak meniru kepala “From:” Gmail. Pesan yang tidak diautentikasi dapat ditandai spam atau ditolak dengan kode galat 5.7.26.

Kelompok kedua adalah pengirim massal, yaitu yang mengirim sekitar 5.000 pesan atau lebih ke akun Gmail pribadi dalam 24 jam. Mereka wajib memasang SPF, DKIM, dan DMARC sekaligus, dengan kebijakan DMARC yang boleh disetel ke none; domain di kolom From harus selaras dengan domain SPF atau DKIM; dan pesan pemasaran wajib mendukung berhenti berlangganan sekali klik serta memuat tautan berhenti berlangganan yang terlihat jelas. FAQ panduan pengirim menambahkan dua hal yang relevan bagi usaha yang sedang tumbuh. Kuota 5.000 dihitung dari semua pesan yang dikirim dari domain primer yang sama, termasuk subdomainnya. Pengirim yang pernah memenuhi kriteria itu sekali saja akan dianggap pengirim massal secara permanen.

Bagi toko kecil, angka 5.000 sehari mungkin terasa jauh, tetapi satu kampanye promosi ke seluruh daftar pelanggan bisa melewatinya dalam sehari. Karena statusnya permanen, lebih aman menyiapkan SPF, DKIM, dan DMARC sekaligus sejak awal. Ada satu konsekuensi lain dari larangan meniru kepala From Gmail: mengirim buletin lewat layanan pihak ketiga dengan alamat pengirim @gmail.com berisiko gagal DMARC, karena layanan itu tidak berwenang mengirim atas nama gmail.com. Alamat berdomain sendiri menyelesaikan masalah ini, karena pemilik usaha bisa mendaftarkan layanan itu di rekaman SPF dan DKIM domainnya. Daftar pelanggan yang dikirimi buletin juga tunduk pada aturan pelindungan data; cara menyusunnya dibahas di panduan data pelanggan yang perlu disimpan.

Semua persyaratan ini memperbesar peluang email sampai di kotak masuk, tetapi tidak menjamin keterkiriman. Gmail dan penyedia lain tetap menilai reputasi pengirim, isi pesan, dan reaksi penerima.

Menguji hasilnya dengan satu email ke akun Gmail sendiri

Setelah setiap tahap, uji dengan cara paling sederhana: kirim email dari kotak surat usaha ke akun Gmail pribadi pemilik, lalu periksa kepala pesannya. Halaman “Melacak email dengan header lengkapnya” di Bantuan Gmail menjelaskan jalurnya. Buka Gmail di browser, buka email yang diuji, klik Lainnya di samping tombol Balas, lalu pilih Tampilkan versi asli. Jendela baru menampilkan header lengkap, lengkap dengan tombol untuk menyalinnya. Di dalam header itu, cari baris hasil autentikasi yang memuat kata spf=, dkim=, dan dmarc= beserta hasilnya. Bila ketiganya bernilai pass dan domain yang disebut adalah domain usaha, tahap itu sudah benar.

Bila hasilnya membingungkan, salin header itu dan tempelkan ke alat Header Pesan di Toolbox Google Admin, seperti yang dianjurkan halaman yang sama, lalu klik analisis. Alat itu menyusun ulang header menjadi tabel yang lebih mudah dibaca. Ulangi pengujian untuk setiap pengirim dalam daftar inventaris, bukan hanya kotak surat utama. Untuk formulir situs, isi formulir kontak dengan alamat Gmail pribadi sebagai penerima uji. Untuk layanan buletin, kirim kampanye uji ke diri sendiri. Untuk aplikasi kasir, buat transaksi percobaan dan minta nota dikirim ke Gmail pemilik.

Contoh rekaan lanjutan: pada uji pertama “Kue Sekar”, email dari kotak surat Google Workspace lulus SPF dan DKIM, tetapi nota dari aplikasi kasir hanya lulus SPF atas domain milik penyedia aplikasi, sementara DKIM-nya ditandatangani dengan domain penyedia, bukan kuesekar.example. Akibatnya DMARC gagal karena tidak ada domain yang selaras dengan kolom From. Perbaikannya ada di menu autentikasi domain aplikasi kasir, bukan di rekaman SPF usaha. Contoh semacam ini yang menjelaskan mengapa pengujian dilakukan per pengirim dan mengapa kebijakan DMARC tidak dinaikkan sebelum seluruh daftar lulus. Catat tanggal dan hasil setiap uji di lembar yang sama dengan daftar pengirim, sehingga ketika ada layanan baru, pemilik tahu persis pemeriksaan mana yang harus diulang.

Lima kekeliruan yang sering ditemukan di panel DNS

Pertama, dua rekaman SPF untuk satu domain, seperti dijelaskan di atas. Periksa dengan alat pemeriksa DNS gratis atau Toolbox Google Admin sebelum dan sesudah menambahkan rekaman. Kedua, menulis nama domain lengkap di kolom Host pada panel yang otomatis menambahkan nama domain, sehingga rekaman tercipta di kuesekar.example.kuesekar.example. Bila setelah 48 jam rekaman tidak terbaca, cek nama host yang sebenarnya tersimpan. Ketiga, lupa memperbarui SPF ketika berganti layanan, misalnya pindah dari satu layanan buletin ke layanan lain. Halaman Google menegaskan bahwa pengirim baru yang tidak tercantum di SPF lebih mungkin ditandai spam.

Keempat, memasang p=reject pada hari pertama karena mengikuti contoh di internet. Contoh di halaman “Menyiapkan DMARC” kebetulan memakai p=reject, tetapi halaman yang sama meminta pemilik memulai dengan none. Kelima, mengarahkan laporan rua ke alamat di domain lain tanpa persiapan. Google mencatat bahwa bila alamat laporan berada di domain berbeda dari domain yang menghosting DMARC, rekaman tambahan diperlukan di domain tujuan laporan.

Ada juga situasi yang tidak sepenuhnya di tangan pemilik: email yang diteruskan. Bila pelanggan meneruskan email toko dari kotak suratnya ke alamat lain, SPF bisa gagal di penerima akhir karena server penerusnya tidak tercantum. Di sinilah DKIM berperan, karena tanda tangan tetap utuh selama isi pesan tidak diubah. Panduan pengirim Gmail sendiri menyarankan agar SPF, DKIM, dan DMARC selalu disiapkan untuk domain, bukan hanya salah satunya, dan memiliki halaman praktik terbaik tersendiri bagi yang rutin meneruskan email.

Ketika pelanggan bertanya apakah email itu asli

Lulus pemeriksaan teknis hanyalah sarana; tujuan akhir ketiga rekaman ini adalah kepercayaan. Pelanggan yang menerima nota dari nota@kuesekar.example, konfirmasi pesanan dari pesanan@kuesekar.example, dan alamat yang sama tercantum di situs serta profil usaha akan lebih mudah membedakannya dari email palsu yang meminta transfer ke rekening lain. Setelah DMARC mencapai reject, penipu yang mencoba memakai domain usaha di kolom From berisiko ditolak oleh penerima yang menghormati kebijakan DMARC.

Lengkapi perlindungan teknis itu dengan kebiasaan komunikasi yang konsisten. Cantumkan alamat email resmi di halaman kontak situs; pertimbangan halaman wajib situs usaha dibahas di panduan kapan usaha membutuhkan website. Beri tahu pelanggan bahwa perubahan nomor rekening tidak pernah diumumkan lewat email saja. Lindungi akun administrator Google Workspace dan akun penyedia domain dengan verifikasi dua langkah, karena siapa pun yang menguasai panel DNS bisa mengubah ketiga rekaman ini; urutannya ada di panduan verifikasi dua langkah akun usaha. Bila pelanggan melaporkan email mencurigakan atas nama toko, minta mereka meneruskannya sebagai lampiran agar kepala pesannya bisa diperiksa, lalu cocokkan dengan laporan DMARC minggu itu. Pola penipuan yang menyasar penjual dan pembeli dibahas di panduan modus penipuan penjual online.

Dokumen bantuan Google dan standar IETF yang dirujuk

Pertanyaan yang sering diajukan

Domain saya cuma dipakai untuk website, tidak kirim email. Perlu SPF dan DMARC juga?

Perlu dipertimbangkan, karena penipu bisa memakai nama domain itu di kolom From. Panduan pengirim Gmail menyarankan autentikasi email juga disiapkan untuk domain yang menghosting situs publik.

Setelah rekaman DNS disimpan, kapan hasilnya bisa dicek?

Halaman Google menyebut SPF bisa memerlukan hingga 48 jam untuk mulai bekerja, dan DMARC sebaiknya dipasang 48 jam setelah SPF dan DKIM aktif. Uji ulang setelah jeda itu sebelum mengubah apa pun.

Boleh pakai -all saja supaya lebih tegas?

Boleh, tetapi bila ada pengirim sah yang belum tercantum, emailnya bisa gagal. Google merekomendasikan ~all, sementara ketegasan terhadap pemalsu diatur lewat kebijakan DMARC yang dinaikkan bertahap.

Lanjutkan belajar

Panduan terkait