# Cara setting DMARC: contoh record dari p=none hingga reject > Untuk setting DMARC, pastikan SPF dan DKIM lolos untuk setiap layanan yang mengirim atas nama domain Anda, pasang record TXT di _dmarc.domainanda seperti v=DMARC1; p=none; rua=mailto:dmarc@domainanda, baca laporan hariannya selama beberapa minggu, lalu perketat kebijakannya ke quarantine dan akhirnya reject. Canonical: https://tellnod.com/id/guides/how-to-set-up-dmarc Last updated: 2026-10-22 Author: Tellnod team ## Langkah-langkah 1. **Cek SPF dan DKIM terlebih dahulu.** Catat setiap layanan yang mengirim dengan domain Anda di alamat From, lalu pastikan masing-masing lolos [SPF](https://tellnod.com/glossary#spf) atau [DKIM](https://tellnod.com/glossary#dkim) untuk domain Anda sendiri. Google menyarankan keduanya dipasang setidaknya 48 jam sebelum DMARC [S3]. 2. **Siapkan mailbox untuk laporan.** Buat alamat seperti dmarc@ninefold.example, atau gunakan layanan laporan DMARC. Laporan dikirim sebagai file XML terkompresi [S2]. 3. **Pasang record pemantauan.** Tambahkan record TXT dengan host `_dmarc` dan nilai `v=DMARC1; p=none; rua=mailto:dmarc@ninefold.example`. Kebijakan none tidak mengubah cara email diperlakukan [S1]. 4. **Verifikasi record.** Jalankan `dig +short TXT _dmarc.ninefold.example` atau gunakan alat DNS lookup, lalu pastikan hanya satu record yang muncul dan diawali v=DMARC1. 5. **Baca laporannya.** Tinjau laporan aggregate sampai setiap pengirim yang sah menunjukkan SPF atau DKIM yang selaras. Google menyarankan minimal satu minggu; RFC 9989 menyarankan sekitar satu bulan sebelum kebijakan diterapkan [S1][S3]. 6. **Naik ke quarantine.** Ubah kebijakan menjadi `p=quarantine`, sehingga email yang gagal masuk ke folder spam. Terus baca laporannya. 7. **Naik ke reject.** Setelah periode serupa dengan laporan yang bersih, ubah kebijakan menjadi `p=reject`, sehingga penerima menolak email yang gagal [S1]. ## Yang perlu disiapkan sebelum setting DMARC [DMARC](https://tellnod.com/glossary#dmarc) tidak mengautentikasi apa pun dengan sendirinya. DMARC membaca hasil SPF dan DKIM, lalu memeriksa bahwa setidaknya salah satunya lolos untuk domain yang selaras dengan alamat From yang terlihat [S1]. Jika alat marketing Anda menandatangani dengan domainnya sendiri, bukan domain Anda, DMARC gagal walaupun DKIM lolos. Perbaiki itu dulu, atau laporan Anda akan penuh dengan email Anda sendiri. Untuk brand pakaian kecil seperti Ninefold, daftar pengirim biasanya mencakup mailbox staf, email pesanan dan pengiriman dari platform toko, help desk, dan alat email marketing. Masing-masing perlu SPF atau DKIM yang diatur di ninefold.example. [Penjelasan SPF, DKIM, dan DMARC](https://tellnod.com/id/guides/spf-dkim-dmarc-explained) membahas cara kerja setiap record. > Gmail mewajibkan record DMARC dari pengirim lebih dari 5.000 pesan per hari ke akun Gmail pribadi, dan kebijakan none sudah diterima [S4]. Yahoo juga meminta pengirim massal memasang minimal p=none [S5]. Memasang record ini hanya butuh beberapa menit, jadi layak ditambahkan berapa pun volume Anda. ## Format record DMARC Record DMARC adalah record TXT yang dipasang di `_dmarc` pada domain Anda. Isinya daftar tag yang dipisahkan titik koma. Tag `v=DMARC1` harus berada paling depan, atau penerima mengabaikan seluruh record [S1]. Berikut tag yang dibutuhkan toko online: | Tag | Contoh | Fungsinya | | --- | --- | --- | | v | v=DMARC1 | Versi; harus menjadi tag pertama | | p | p=none | Kebijakan untuk domain Anda: none, quarantine, atau reject | | rua | rua=mailto:dmarc@ninefold.example | Tujuan laporan aggregate harian | | sp | sp=reject | Kebijakan untuk subdomain yang ada, jika berbeda dari p | | np | np=reject | Kebijakan untuk subdomain yang tidak ada | | adkim / aspf | adkim=r | Alignment DKIM dan SPF: relaxed (default) atau strict | | t | t=y | Pengujian: meminta penerima menerapkan satu tingkat di bawah kebijakan yang tertulis | Abaikan `adkim` dan `aspf` kecuali ada alasan khusus. Alignment relaxed, yang merupakan default, membuat email yang ditandatangani subdomain seperti mail.ninefold.example selaras dengan alamat From di ninefold.example [S1], dan Yahoo menerima alignment relaxed [S5]. ## Contoh record DMARC untuk setiap tahap Contoh berikut memakai ninefold.example. Ganti domain dan alamat laporan dengan milik Anda, lalu pasang masing-masing di host `_dmarc`. ### Pemantauan `v=DMARC1; p=none; rua=mailto:dmarc@ninefold.example` ### Quarantine `v=DMARC1; p=quarantine; rua=mailto:dmarc@ninefold.example` ### Reject `v=DMARC1; p=reject; np=reject; rua=mailto:dmarc@ninefold.example` > Panduan yang lebih lama, termasuk halaman rollout dari Google, memakai `pct=` untuk menerapkan kebijakan pada sebagian persentase email [S3]. RFC 9989 menghapus tag itu karena penerima hanya menerapkannya dengan andal pada 0 atau 100, dan menggantinya dengan `t=y` untuk masa pengujian [S1]. Penerima wajib mengabaikan tag yang tidak dikenalnya, jadi penerima yang belum mendukung `np` atau `t` cukup melewatinya [S1]. ## Isi laporan rua DMARC Penyedia kotak masuk yang mengirim laporan aggregate biasanya mengirim satu laporan per hari untuk setiap domain, dalam bentuk file XML terkompresi [S2]. Setiap laporan mencantumkan alamat IP yang mengirim email dengan domain Anda, jumlah pesan dari masing-masing, hasil SPF dan DKIM, apakah hasilnya selaras, dan tindakan penerima terhadap email tersebut [S2]. - **Sumber yang Anda kenal tetapi gagal alignment** adalah pengirim yang lupa diatur. Aktifkan DKIM dengan domain Anda di layanan itu, atau tambahkan ke SPF. - **Sumber yang tidak Anda kenal** bisa berupa layanan yang didaftarkan rekan tim, atau pihak yang memalsukan domain Anda. Tanyakan dulu ke tim sebelum menerapkan kebijakan. - **Email yang diteruskan** sering gagal SPF tetapi lolos DKIM [S1]. Itu wajar, dan menjadi salah satu alasan DKIM yang selaras paling penting. XML mentah sulit dibaca manual, jadi banyak toko mengarahkan `rua` ke layanan laporan yang mengubahnya menjadi grafik. Jika layanan itu memakai domain lain, domain tersebut harus memasang record otorisasi, atau penerima mengabaikan alamatnya [S2]. Layanan laporan biasanya mengurus ini dari sisi mereka. ## Naik dari p=none ke quarantine lalu reject Urutannya selalu sama: pantau, lalu quarantine, lalu reject. Yang berbeda hanyalah lama setiap tahap. Google menyarankan minimal satu minggu di none [S3]. RFC 9989 menyarankan minimal satu bulan di none dan periode serupa di quarantine sebelum reject [S1]. Toko dengan sedikit pengirim dan laporan yang bersih bisa bergerak lebih cepat daripada toko yang memakai belasan alat. Hindari mengubah kebijakan tepat sebelum periode sibuk seperti Harbolnas 12.12 atau menjelang Lebaran. | Kebijakan | Email yang gagal | Kapan dipakai | | --- | --- | --- | | p=none | Dikirim seperti biasa; hanya dilaporkan | Selama Anda mencari semua pengirim | | p=quarantine | Dianggap mencurigakan, biasanya masuk spam | Setelah laporan menunjukkan semua pengirim Anda selaras | | p=reject | Ditolak oleh penerima | Setelah periode bersih di quarantine | Sebelum setiap perubahan, periksa laporan seminggu terakhir untuk sumber yang Anda kenal tetapi gagal. Jika staf mengirim ke milis (mailing list) dari domain toko, RFC 9989 menyarankan untuk tidak memakai `p=reject`: email milis yang ditolak penerima menimbulkan masalah bagi milis itu dan bisa membuat pelanggannya dikeluarkan [S1]. Dalam kasus itu, quarantine adalah titik berhenti yang wajar. ## DMARC untuk subdomain Tanpa record sendiri, subdomain seperti news.ninefold.example memakai kebijakan di ninefold.example. Gunakan `sp` untuk memberi kebijakan berbeda pada subdomain yang ada, dan `np` untuk nama yang tidak ada, yang sering dipakai untuk memalsukan sebuah brand [S1]. Sebagian toko mengirim email marketing dari subdomain agar terpisah dari email staf. Subdomain itu bisa punya record `_dmarc` sendiri. RFC 9989 menjelaskan cara menguji subdomain dengan `p=quarantine; t=y`, lalu beralih ke `p=reject` dan menghapus tanda pengujian [S1]. ## Setting DMARC dengan Tellnod di Claude atau ChatGPT Tellnod adalah [konektor MCP](https://tellnod.com/glossary#mcp-connector) untuk menulis, melihat pratinjau, dan mengirim email marketing dari Claude atau ChatGPT. Anda bisa langsung mengirim dari alamat di domain bersama Tellnod, misalnya hello@yourshop.tellnodmail.com, dengan batas 500 penerima per kampanye dan 1.000 email per bulan. Verifikasi domain Anda sendiri menghapus batas tersebut. Minta di chat: “Jadikan ninefold.example sebagai domain pengirim saya.” Tellnod memberikan record SPF, DKIM, dan DMARC lalu memeriksanya untuk Anda. Jika DNS dikelola orang lain, minta tautan penyiapan untuk dikirim kepada mereka: mereka bisa menambahkan record dengan satu klik di penyedia yang didukung, atau menyalinnya, tanpa membuat akun. Anda diberi tahu di chat dan lewat email saat domain sudah terverifikasi. Jika Anda sudah punya record DMARC, pertahankan satu record saja dan pastikan email dari Tellnod selaras sebelum Anda memperketat kebijakannya. Setiap kampanye tetap melewati pratinjau desktop dan seluler serta kartu konfirmasi yang hanya bisa ditekan oleh Anda. Anda menyetujui setiap pengiriman. [Hubungkan Tellnod](https://tellnod.com/id/connect) untuk mulai dengan paket gratis, atau bandingkan paket di [halaman harga](https://tellnod.com/id/pricing). Untuk hal lain yang diharapkan Gmail dan Yahoo, lihat [dasar-dasar deliverability](https://tellnod.com/guides/email-deliverability-basics). ## FAQ ### Record DMARC apa yang baik untuk permulaan? Mulailah dengan v=DMARC1; p=none; rua=mailto: diikuti alamat yang Anda baca. Record ini tidak mengubah pengiriman sama sekali dan mulai mengirimkan laporan harian [S1]. ### Apakah p=none cukup untuk Gmail dan Yahoo? Ya, untuk persyaratan pengirim massal. Keduanya menerima kebijakan none, asalkan domain From selaras dengan SPF atau DKIM [S4][S5]. Menerapkan kebijakan yang lebih ketat nantinya menambah perlindungan dari spoofing. ### Berapa lama sebaiknya bertahan di p=none? Sampai laporan menunjukkan semua pengirim yang sah sudah selaras. Google menyarankan minimal satu minggu, dan RFC 9989 menyarankan sekitar satu bulan sebelum kebijakan diterapkan [S1][S3]. ### Bolehkah ada dua record DMARC? Tidak. Pasang satu record TXT di _dmarc. Jika lookup menghasilkan lebih dari satu record DMARC, penerima membuang semuanya, jadi gabungkan menjadi satu [S1]. ### Record DMARC dipasang di domain utama atau subdomain? Di host _dmarc pada domain yang ada di alamat From Anda. Record di domain utama juga mencakup subdomain yang tidak punya record sendiri, melalui tag p, sp, atau np [S1]. ## Sources - [S1] RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC): (checked 2026-10-22) - [S2] RFC 9990: DMARC aggregate reporting: (checked 2026-10-22) - [S3] Google Workspace Admin Help: Recommended DMARC rollout: (checked 2026-10-22) - [S4] Google Workspace Admin Help: Email sender guidelines: (checked 2026-10-22) - [S5] Yahoo Sender Hub: Sender best practices: (checked 2026-10-22)