No DMARC record found: satu baris yang belum ada di domain Anda

Singkatnya

• Pesan itu berarti tidak ada catatan TXT di _dmarc.yourdomain.com. Server email Anda tidak rusak.
• Tambahkan satu catatan TXT dengan host _dmarc dan nilai v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Dengan p=none, pengiriman tetap persis seperti sebelumnya.
• Gmail, Yahoo, dan Outlook.com mewajibkan catatan ini hanya dari pengirim massal. Tetap tambahkan: Google menghitung seluruh domain dan tidak pernah mencabut status pengirim massal, dan laporan baru mulai datang setelah catatannya ada.
• Jika alat pemeriksa tetap tidak menemukan apa pun, cari penyedia DNS yang salah, nama host yang tergandakan, atau dua catatan DMARC. Dua catatan saling membatalkan.
• Standarnya berubah pada Mei 2026 dengan RFC 9989: pct dihapus, t dan np baru. Per Oktober 2026, bantuan Google masih menjelaskan pct.

“No DMARC record found” (catatan DMARC tidak ditemukan) berarti sebuah alat pemeriksa meminta catatan TXT di _dmarc.yourdomain.com kepada DNS dan tidak mendapat jawaban. Tidak ada yang rusak di server email Anda. Perbaikannya adalah satu catatan TXT dengan host _dmarc dan nilai v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Dengan p=none, email Anda dikirim persis seperti sebelumnya. Anda hanya memberi tahu penerima bahwa Anda ikut serta, dan Anda mulai menerima laporan.

DMARC adalah yang ketiga dari tiga catatan email, di samping SPF dan DKIM. SPF mencantumkan server yang boleh mengirim atas nama domain Anda. DKIM menandatangani setiap pesan. DMARC memberi tahu penerima apa yang harus dilakukan bila tidak satu pun dari keduanya menjamin domain di alamat From Anda, dan ke mana ringkasan harian harus dikirim. Sejak Mei 2026 DMARC ditetapkan dalam RFC 9989, yang menggantikan RFC 7489 yang lebih lama. Banyak panduan masih menjelaskan versi lama, begitu pula halaman bantuan Google per Oktober 2026.

Catatan yang perlu ditambahkan

Login ke tempat DNS domain Anda dikelola. Itu adalah perusahaan yang dituju nameserver Anda, yang tidak selalu sama dengan tempat Anda membeli domain. Tambahkan catatan baru dengan nilai berikut:

Bila ditulis sebagai satu baris dalam file zona, catatan jadinya terlihat seperti ini:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Ganti example.com dengan domain Anda sendiri. Ketiga bagiannya berfungsi sebagai berikut:

• v=DMARC1 menandai baris itu sebagai catatan DMARC. Bagian ini harus berada paling depan, dengan DMARC1 dalam huruf kapital. Jika tidak, penerima mengabaikan seluruh catatan.
• p=none adalah kebijakannya: perlakukan email saya seperti biasanya. Tidak ada yang diblokir atau dipindahkan ke spam karena catatan ini.
• rua=mailto:… adalah alamat untuk laporan harian. Buat alamat itu, atau alias yang meneruskan kepada Anda, sebelum menerbitkan catatan.

Google mencantumkan tiga kolom yang sama di Set up DMARC. Google juga meminta agar SPF dan DKIM sudah berfungsi selama 48 jam sebelum Anda menambahkan DMARC. Jika alat pemeriksa Anda juga menandai kedua catatan itu, perbaiki keduanya lebih dulu.

Cara memeriksa bahwa catatannya berfungsi

Tanyakan sendiri kepada DNS. Di macOS atau Linux, buka terminal dan gunakan dig. Di Windows, gunakan nslookup.

dig +short TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.com

Jika catatannya sudah aktif, baris itu muncul kembali dalam tanda kutip. Inilah jawaban domain Google sendiri pada 5 Oktober 2026:

$ dig +short TXT _dmarc.google.com
"v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com"

Jawaban kosong berarti catatannya belum ada, atau tidak berada di tempat yang dicari penerima. Setelah kueri Anda sendiri menampilkan baris itu, jalankan lagi alat pemeriksa yang memberi Anda pesan tadi. MXToolbox, misalnya, merumuskan masalahnya sebagai “No DMARC Record found” dan menjelaskan bahwa “domain Anda tidak memiliki catatan DMARC yang diterbitkan”.

Arti tiap bagian catatan DMARC

Sebuah catatan adalah daftar pasangan tag=value yang dipisahkan titik koma. Dalam standar, hanya v yang wajib, dan harus berada paling depan. Taruh p di urutan kedua: bantuan Google menyatakan bahwa “Tag v dan p harus dicantumkan lebih dulu”, dan standar yang lama mengharapkan urutan yang sama. Berikut tag dalam RFC 9989, bagian 4.7:

Catatan lama sering berakhir dengan pct=100. Tag itu dimaksudkan untuk menerapkan kebijakan pada sebagian email yang gagal. RFC 9989 menghapusnya, bersama rf dan ri, dan menjelaskan alasannya:

Pengalaman operasional menunjukkan bahwa tag “pct” biasanya tidak diterapkan secara akurat, kecuali bila nilai yang ditentukan adalah 0 atau 100 (bawaan), dan ketidakakuratan pada nilai lain sangat bervariasi dari satu implementasi ke implementasi lain.

Penerima harus mengabaikan tag yang tidak dikenalnya, jadi pct=100 yang lama tidak merugikan. Catatan yahoo.com dan microsoft.com masih memuatnya pada 5 Oktober 2026, dan halaman bantuan Google masih menganjurkan pct untuk penerapan bertahap. Di catatan baru, jangan cantumkan.

Apakah Anda perlu DMARC jika hanya mengirim beberapa email sehari?

Menurut aturan yang diterbitkan penyedia email besar, catatan DMARC diwajibkan begitu Anda mengirim secara massal. Di bawah itu, sifatnya anjuran.

Sumbernya adalah Email sender guidelines dari Google, Sender Best Practices dari Yahoo, dan pengumuman Microsoft untuk pengirim bervolume tinggi, semuanya per Oktober 2026. Jika Anda mengirim tiga puluh email sehari dari satu kotak masuk, tidak satu pun dari mereka menuntut catatan itu. Tetap ada tiga alasan untuk menambahkannya sekarang.

• Ambang batasnya dihitung per domain, dan tidak kembali ke nol. Google menjumlahkan semua pesan ke akun Gmail pribadi yang berasal dari domain utama yang sama, termasuk subdomain. FAQ pengirimnya menyebut: “Pengirim yang memenuhi kriteria di atas setidaknya satu kali dianggap pengirim massal secara permanen.”
• Google dan Yahoo sama-sama menganjurkannya untuk semua orang. Google menulis bahwa “kami menganjurkan agar Anda selalu menyiapkan SPF, DKIM, dan DMARC untuk domain Anda”. Yahoo “sangat mengimbau semua pengirim agar menerbitkan kebijakan DMARC untuk setiap domain yang mengirim email”.
• Tanpa catatan itu Anda tidak menerima laporan. Lewat laporan itulah Anda melihat server mana yang mengirim email dengan domain Anda di baris From, baik alat Anda sendiri maupun pihak asing.

Bagi pengirim massal, catatan yang tidak ada membawa akibat. FAQ pengirim Google mencantumkan kesalahan sementara 4.7.31 untuk hal itu: “domain pengirim tidak memiliki catatan DMARC, atau catatan DMARC-nya tidak menetapkan kebijakan DMARC”. Halaman yang sama menyebut bahwa sejak November 2025 email yang tidak memenuhi persyaratan menghadapi “penolakan sementara dan permanen”.

Catatan sudah ditambahkan, tetapi alat pemeriksa tetap tidak menemukan apa pun?

Kalau begitu, biasanya salah satu hal berikut penyebabnya. Periksa satu per satu dengan kueri dig di atas.

• Anda mengubah DNS di tempat yang salah. Jika nameserver Anda berada di perusahaan yang berbeda dari registrar Anda, catatan yang dimasukkan di registrar tidak pernah dikueri. dig +short NS example.com menunjukkan siapa yang menjawab untuk domain Anda.
• Host-nya salah. Catatan berada di example.com itu sendiri, atau di nama yang tergandakan, seperti dijelaskan di atas. Penerima hanya menanyakan _dmarc.example.com.
• Ada dua catatan DMARC. Standar bersikap tegas di sini: “Jika beberapa DMARC Policy Record dikembalikan untuk satu target, semuanya dibuang.” Gabungkan menjadi satu. Dua alamat laporan dimasukkan ke satu rua, dipisahkan dengan koma.
• Tag pertama tidak persis v=DMARC1. Huruf kecil, salah ketik seperti DMARC 1, atau p= di depannya membuat catatan tidak valid.
• Tipe catatannya bukan TXT, atau nilainya ditempel dengan tanda kutip melengkung dari sebuah dokumen. Ketik nilainya sebagai teks biasa, tanpa tanda kutip kecuali bantuan penyedia DNS Anda memintanya.
• Jawaban lama masih tersimpan di cache. Resolver mengingat “catatan tidak ada” selama beberapa waktu. Tanyakan langsung ke salah satu nameserver Anda sendiri dengan menambahkan namanya ke kueri, misalnya dig +short TXT _dmarc.example.com @ns1.example.net. Jika catatannya terlihat di sana, alat pemeriksa akan menyusul.

Ke mana laporan dikirim, dan apa yang dilakukan dengannya

Setiap penerima yang mendapat email dengan domain Anda di baris From mengirim laporan ke alamat rua. Menurut halaman Google About DMARC reports, laporan itu “biasanya dikirim sekali sehari lewat email”. Laporannya berupa file XML, biasanya dikompresi, yang dilampirkan pada sebuah email. RFC 9990 menjelaskan formatnya.

Google memperingatkan bahwa organisasi besar “mungkin menerima hingga ratusan atau bahkan ribuan laporan setiap hari” dan menganjurkan sebuah grup atau kotak masuk khusus. Jumlahnya bergantung pada seberapa banyak yang Anda kirim dan ke berapa domain, jadi satu atau dua kotak masuk menghasilkan jauh lebih sedikit. Alias seperti dmarc@ dengan filter ke folder tersendiri sudah cukup.

Alamat itu sebaiknya berada di domain yang sama dengan catatannya. Jika Anda ingin laporan dikirim ke tempat lain, domain lain itu harus menyetujuinya dengan menerbitkan catatannya sendiri. Tanpa itu, penerima harus mengabaikan alamat tersebut (RFC 9990, bagian 4).

example.com._report._dmarc.otherdomain.net.  IN  TXT  "v=DMARC1;"

Itulah sebabnya alamat Gmail gratis tidak bisa dipakai sebagai alamat laporan: gmail.com tidak menerbitkan catatan semacam itu ketika kami memeriksanya pada 5 Oktober 2026.

Di dalam file, setiap blok record mewakili satu server pengirim: alamat IP-nya, jumlah pesannya, dan di bawah policy_evaluated apakah DKIM dan SPF lolos untuk domain Anda. Ada dua hal yang Anda cari. Server yang Anda kenal tetapi menunjukkan fail perlu diperbaiki, dan DMARC gagal padahal SPF dan DKIM lolos menjelaskan caranya. Server yang tidak Anda kenal adalah alat yang Anda lupakan atau seseorang yang memakai nama Anda.

Setelah p=none: kapan kebijakan diperketat

p=none adalah mode pemantauan. Mode ini memenuhi syarat minimum yang diminta penyedia email, dan tidak mencegah siapa pun memalsukan alamat Anda. Yang mencegahnya hanyalah p=quarantine, yang meminta penerima memperlakukan email yang gagal sebagai mencurigakan, dan p=reject, yang meminta penerima menolaknya.

Sebelum memperketat, setiap sumber sah email Anda harus lolos. RFC 9989 menyebut bahwa celah semacam itu “HARUS ditangani sebelum upaya apa pun” untuk menegakkan kebijakan, dan bahwa, bergantung pada seberapa sering Anda mengirim, “mungkin diperlukan berbulan-bulan” laporan untuk memastikannya. Halaman penerapan bertahap dari Google menilai satu minggu laporan “biasanya cukup”. Dengan satu kotak masuk dan satu atau dua alat, Anda lebih dekat ke angka Google, tetapi beri waktu beberapa minggu agar pengiriman faktur bulanan dan formulir kontak ikut terlihat.

Untuk langkahnya sendiri, kedua sumber itu tidak sepakat. Google masih menyarankan p=quarantine; pct=5 lalu menaikkan angkanya. Standar sudah membuang pct dan menawarkan ini sebagai gantinya:

v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com

t=y meminta penerima memperlakukan kegagalan satu tingkat lebih rendah untuk sementara, yaitu sebagai none. Bila laporan tetap bersih, hapus t=y. Perlu diingat bahwa penerima yang tidak mengenal tag itu akan mengabaikannya dan menerapkan quarantine sepenuhnya, dan bahwa halaman Google tidak menyebut t per Oktober 2026. Jika kebijakan yang lebih ketat akan mengenai email yang belum bisa Anda perbaiki, tetaplah di p=none.

Di mana WarmupBay berperan

Saat Anda menghubungkan kotak masuk, WarmupBay memeriksa SPF, DKIM, dan DMARC untuk domainnya. Jika catatan DMARC belum ada, WarmupBay menampilkan catatan siap pakai untuk Anda salin. Anda tetap bisa memulai pemanasan. Jika setelah 72 jam catatan itu masih belum ada, pemanasan berhenti.

WarmupBay tidak bisa menambahkan catatan itu untuk Anda, karena DNS Anda adalah milik Anda, dan WarmupBay tidak mengumpulkan atau membaca laporan DMARC. Yang dilakukannya adalah langkah setelah catatan terpasang: kotak masuk Anda bertukar beberapa email sehari dengan kotak masuk lain dalam jaringan bersama, mulai dari tiga dan bertambah satu setiap hari, sehingga aktivitas pengiriman terbangun secara bertahap. Layanan ini gratis untuk 10 email sehari. Lihat apa saja yang dicakup pemeriksaan dan pemanasannya, atau hubungkan kotak masuk Anda setelah catatannya terpasang.

Pertanyaan yang sering diajukan

Apakah catatan DMARC di example.com juga mencakup subdomain seperti news.example.com?

Ya. Penerima pertama-tama mencari catatan di _dmarc.news.example.com. Jika tidak ada, penerima beralih ke catatan domain organisasi, yaitu example.com. Kebijakan yang diterapkan pada subdomain adalah yang ada di sp jika Anda mengaturnya, dan jika tidak, yang ada di p.

Bolehkah saya menerbitkan v=DMARC1; p=none tanpa alamat rua?

Ya. Itu catatan yang valid, dan dihitung sebagai kebijakan yang diterbitkan. Anda tidak akan menerima laporan, jadi Anda tidak akan melihat apakah email Anda sendiri lolos atau siapa lagi yang memakai domain Anda. Yahoo menyebut alamat rua yang berfungsi sangat dianjurkan, dan Google menganjurkan agar selalu mencantumkannya.

Apakah saya perlu catatan DMARC untuk domain kedua yang hanya saya pakai untuk outreach?

Ya. Penerima mencari domain di alamat From setiap pesan, jadi catatan di domain utama Anda tidak mencakup domain lain. Gunakan baris yang sama di domain kedua. Jika laporannya ingin dikirim ke alamat di domain utama, domain utama harus menerbitkan catatan otorisasi yang dijelaskan di bagian tentang tujuan pengiriman laporan.

Apa yang sebaiknya diterbitkan domain yang tidak pernah mengirim email?

Pasangan yang ketat. M3AAWG menganjurkan catatan SPF v=spf1 -all dan catatan DMARC dengan p=reject untuk domain yang tidak pernah mengirim email, agar tidak ada yang bisa memakainya di alamat From. Untuk DMARC, itu berarti baris v=DMARC1; p=reject di _dmarc.

Apakah p=none lebih buruk bagi email saya daripada p=quarantine atau p=reject?

Aturan pengirim yang diterbitkan Gmail, Yahoo, dan Outlook.com meminta setidaknya p=none dan tidak lebih ketat dari itu. Kebijakan menentukan apa yang terjadi pada email yang gagal DMARC, termasuk email palsu atas nama Anda. Ada satu fitur yang menuntut lebih: BIMI, yaitu logo di samping pesan Anda, mewajibkan quarantine atau reject menurut bantuan Google.

Sumber

1. RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC), May 2026
2. RFC 9990: DMARC Aggregate Reporting, May 2026
3. Email sender guidelines – Gmail Help
4. Email sender guidelines FAQ – Gmail Help
5. Set up DMARC – Google Workspace Help
6. Recommended DMARC rollout – Google Workspace Help
7. About DMARC reports – Google Workspace Help
8. Troubleshoot DMARC issues – Google Workspace Help
9. Sender Best Practices – Yahoo Sender Hub
10. Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders – Microsoft Community Hub
11. DMARC Record Published – MXToolbox
12. M3AAWG Email Authentication Recommended Best Practices, September 2020 (PDF)
13. M3AAWG Protecting Parked Domains Best Common Practices, December 2015 (PDF)