---
title: "Cara Menaikkan DMARC Bertahap dari None ke Reject"
description: "Tahapan aman menaikkan DMARC dari p=none ke quarantine lalu reject, termasuk tanda siap naik, perubahan tag pct ke t di RFC 9989, dan kesalahan umum."
url: "https://nivelva.com/insight/cara-menaikkan-dmarc-bertahap-none-reject"
category: "Keamanan/Cyber Security"
tags: ["dmarc","email","anti spoofing","spf","dkim","dns"]
author: "Theresia Candiawan"
published: "2026-11-07T04:13:00+07:00"
updated: "2026-11-07T04:13:00+07:00"
language: "id"
publisher: "Nivelva (https://nivelva.com)"
---

# Cara Menaikkan DMARC Bertahap dari None ke Reject

> **Jawaban singkat:** Mulai dari p=none dengan laporan rua aktif, inventarisasi semua layanan pengirim sampai lolos SPF atau DKIM yang selaras, lalu naik ke p=quarantine dan akhirnya p=reject. Tiap tahap ditahan beberapa minggu sambil memantau laporan, dan naik hanya bila email sah sudah lolos semua.

DMARC adalah catatan DNS yang memberi tahu server penerima apa yang harus dilakukan terhadap email yang mengaku dari domainmu tapi gagal verifikasi SPF dan DKIM. Ada tiga tingkat kebijakan: `p=none` (hanya memantau), `p=quarantine` (masukkan ke spam), dan `p=reject` (tolak). Hanya dua yang terakhir yang benar-benar melindungi domain dari pemalsuan.

Yang dipertaruhkan saat menaikkan kebijakan cukup nyata. Naik terlalu cepat, dan invoice, email reset password, atau newsletter dari layanan yang lupa dikonfigurasi akan ikut ditolak. Terlalu lama di `p=none`, dan penipu tetap bebas mengirim email atas nama domainmu. Jalan tengahnya adalah naik bertahap berdasarkan data dari laporan DMARC.

## Seperti apa tahapan yang aman?

### Tahap 1: p=none dengan laporan aktif

Mulai dengan catatan TXT di `_dmarc.domainmu.com`:

```
v=DMARC1; p=none; rua=mailto:dmarc@domainmu.com
```

Tag `rua` adalah kuncinya. Tanpa alamat laporan, `p=none` tidak memberi informasi apa-apa. Penerima besar akan mengirim laporan agregat harian berisi IP mana saja yang mengirim atas nama domainmu dan apakah lolos SPF dan DKIM. Gmail mewajibkan pengirim massal (lebih dari 5.000 email per hari ke akun Gmail) sejak 1 Februari 2024 untuk punya DMARC minimal `p=none`, jadi tahap ini sekaligus memenuhi syarat dasar itu.

Kalau SPF, DKIM, dan DMARC belum terpasang sama sekali, mulai dari panduan [SPF, DKIM, dan DMARC agar email tidak masuk spam](https://nivelva.com/insight/spf-dkim-dmarc).

### Tahap 2: inventarisasi dan perbaiki semua pengirim sah

Selama beberapa minggu pertama, kumpulkan semua sumber email sah dari laporan: server email kantor, Google Workspace atau Microsoft 365, layanan email marketing, sistem invoice, helpdesk, notifikasi aplikasi, sampai printer kantor yang mengirim hasil scan.

Untuk setiap sumber, pastikan minimal satu dari dua hal ini lolos **dan selaras** (aligned) dengan domain di alamat From:

- **DKIM selaras**: email ditandatangani dengan `d=domainmu.com` (atau subdomainnya), bukan domain milik penyedia layanan.
- **SPF selaras**: domain di Return-Path (envelope from) adalah domainmu, dan IP pengirim tercantum di catatan SPF.

DKIM yang selaras lebih diandalkan karena tetap utuh saat email diteruskan, sedangkan SPF sering gagal pada email forward. Cara membaca laporan untuk menemukan sumber yang gagal dibahas di [cara membaca laporan DMARC dan menemukan pengirim palsu](https://nivelva.com/insight/cara-membaca-laporan-dmarc-menemukan-pengirim-palsu).

### Tahap 3: p=quarantine

Setelah semua sumber sah lolos, naikkan ke:

```
v=DMARC1; p=quarantine; rua=mailto:dmarc@domainmu.com
```

Email palsu kini masuk folder spam. Tahan di tahap ini beberapa minggu dan pantau dua hal: laporan DMARC (apakah ada sumber sah baru yang gagal) dan keluhan dari tim atau pelanggan soal email yang tiba-tiba masuk spam.

### Tahap 4: p=reject

```
v=DMARC1; p=reject; rua=mailto:dmarc@domainmu.com
```

Email yang gagal DMARC kini ditolak di tingkat server penerima. Ini tujuan akhirnya. Laporan tetap aktif, karena layanan baru yang dipakai tim di kemudian hari bisa saja lupa dikonfigurasi.

## Ringkasan tahap dan tanda siap naik

| Tahap | Catatan DMARC | Dampak ke email gagal | Tanda siap naik ke tahap berikutnya |
|:--|:--|:--|:--|
| Pantau | `p=none` + `rua` | Tidak ada, hanya dilaporkan | Semua sumber sah sudah dikenali dan lolos SPF atau DKIM selaras |
| Karantina | `p=quarantine` | Masuk spam | Beberapa minggu tanpa sumber sah yang gagal dan tanpa keluhan |
| Tolak | `p=reject` | Ditolak penerima | Tahap akhir, tetap pantau laporan |
| Subdomain | `sp=` | Mengikuti nilai yang diatur | Atur `sp=reject` bila subdomain tidak dipakai untuk email |

Durasi per tahap tidak ada aturan bakunya. Untuk domain dengan sedikit layanan pengirim, beberapa minggu biasanya cukup. Organisasi dengan banyak sistem dan cabang wajar butuh lebih lama.

## Bagaimana dengan tag pct dan t?

Di spesifikasi DMARC lama (RFC 7489), tag `pct` dipakai untuk menerapkan kebijakan hanya ke sebagian email, misalnya `p=quarantine; pct=25`. Pada Mei 2026, IETF menerbitkan RFC 9989 sebagai spesifikasi DMARC baru yang menggantikan RFC 7489. Di dalamnya, tag `pct` **dihapus** dan diganti tag `t`.

Tag `t=y` (mode uji) meminta penerima menerapkan kebijakan satu tingkat lebih ringan: `quarantine` diperlakukan seperti `none`, dan `reject` seperti `quarantine`. Nilai bawaannya `t=n`, artinya kebijakan diterapkan penuh.

> **Hati-hati di masa transisi:**
>
> Tidak semua server penerima sudah menerapkan RFC 9989. Penerima yang masih memakai aturan lama mengabaikan tag `t`, sehingga `p=reject; t=y` di sana tetap diperlakukan sebagai reject penuh. Jangan menjadikan `t=y` atau `pct` sebagai jaring pengaman utama. Naik ke tahap berikutnya hanya bila laporan menunjukkan semua email sah sudah lolos.

## Kapan bertahan di quarantine, kapan langsung reject?

Bertahan lebih lama di `p=quarantine` masuk akal bila domainmu dipakai oleh banyak sistem yang dikelola pihak berbeda, misalnya vendor aplikasi, agensi pemasaran, atau cabang dengan IT sendiri. Di kondisi seperti itu, selalu ada kemungkinan satu sistem terlupa, dan email yang masuk spam masih bisa diselamatkan penerimanya. Email yang ditolak tidak.

Sebaliknya, `p=reject` sebaiknya dikejar secepat data mengizinkan bila domainmu sering dipalsukan, misalnya untuk modus [invoice palsu dalam business email compromise](https://nivelva.com/insight/business-email-compromise-invoice-palsu), atau bila sumber pengirimmu sedikit dan semuanya sudah terkendali.

Untuk domain yang sama sekali tidak dipakai mengirim email (domain cadangan, domain lama), langsung pasang `v=DMARC1; p=reject;` bersama catatan SPF `v=spf1 -all`. Tidak ada email sah yang perlu dilindungi, jadi tidak perlu tahapan.

## Pertanyaan yang sering diajukan

### Berapa lama idealnya di p=none?

Selama yang dibutuhkan untuk mengenali dan memperbaiki semua pengirim sah. Untuk usaha kecil dengan sedikit layanan, beberapa minggu biasanya cukup. Yang penting bukan lamanya, tetapi laporan menunjukkan semua sumber sah sudah lolos.

### Apakah DMARC reject membuat email forward gagal?

Bisa, terutama bila email hanya lolos SPF. Karena itu pastikan email ditandatangani DKIM yang selaras, sebab tanda tangan DKIM biasanya tetap utuh saat diteruskan.

### Apakah catatan DMARC lama dengan pct masih berlaku?

Catatan tetap valid karena versinya tetap v=DMARC1. Penerima yang sudah mengikuti RFC 9989 akan mengabaikan pct, sedangkan penerima lama mungkin masih memakainya. Sebaiknya rencanakan tahapan tanpa bergantung pada pct.

### Apakah perlu mengatur kebijakan subdomain terpisah?

Bila tag sp tidak ditulis, subdomain mengikuti kebijakan p domain utama. Tulis sp secara eksplisit bila subdomain diperlakukan berbeda, misalnya sp=reject untuk subdomain yang tidak pernah mengirim email.

## Sumber

- <https://www.rfc-editor.org/rfc/rfc9989.html>
- <https://www.rfc-editor.org/rfc/rfc7489>
- <https://support.google.com/a/answer/81126>

---

Diterbitkan oleh Nivelva Insight (https://nivelva.com/insight/). Artikel ini: https://nivelva.com/insight/cara-menaikkan-dmarc-bertahap-none-reject
Kontak Nivelva: WhatsApp https://wa.me/6285111245007, email hello@nivelva.com
