Alat populer

Tema

Cek DMARC

Cek record DMARC domain mana pun seperti cara server email penerima membacanya: di mana kebijakan ditemukan, apa yang terjadi pada email yang gagal, apakah laporan sampai ke seseorang, dan apa yang dibutuhkan SPF dan DKIM sebelum Anda menegakkannya.

Sumber: record TXT _dmarc milik domain dan domain induknya, lewat Google Public DNS (dengan Cloudflare 1.1.1.1 di belakangnya) · tree walk RFC 9989 · otorisasi laporan menurut RFC 9990 · SPF dan DKIM dari pemeriksa kami sendiri · tidak ada data tentang Anda yang disimpan

Bagaimana cara mengecek record DMARC?

Ketik sebuah domain di atas: pemeriksa menanyakan record TXT di _dmarc. ditambah domain ke DNS, naik ke domain organisasi jika tidak ada (RFC 9989 §4.10), dan menunjukkan apa yang dilakukan server penerima terhadap email yang gagal.

Secara manual, tanyakan nama yang sama: dig +short TXT _dmarc.paypal.com, atau nslookup -type=TXT _dmarc.paypal.com di Windows. Satu jawaban yang diawali v=DMARC1 adalah recordnya; dua jawaban berarti penerima tidak memakai keduanya (RFC 9989 §4.10).

dig berhenti di situ. Ia tidak naik dari subdomain, tidak mengecek apakah alamat laporan mau menerima laporan, dan tidak menunjukkan RFC mana yang diikuti penerima. Itulah yang ditambahkan pemeriksa ini.

dig +short TXT _dmarc.example.com

Setiap jawaban di nama itu. Yang diawali v=DMARC1 adalah recordnya.

Apa yang ditunjukkan dig, dan apa yang tidak

baris perintah

$ dig +short TXT _dmarc.paypal.com 1

"v=DMARC12; p=reject; rua=mailto:d@rua.agari.com,mailto:dmarc_agg@vali.email; ruf=mailto:d@ruf.agari.com,mailto:MTc4Mzcw@ruf.vali.email3"

$ dig TXT _dmarc.mail.google.com | grep status 4

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN

  1. 1Namanya _dmarc. ditambah domainBukan domain itu sendiri: TXT di paypal.com adalah tempat SPF.
  2. 2Satu record, v=DMARC1 di awalDua record di satu nama: penerima membuang keduanya (RFC 9989 §4.10).
  3. 3Tag, dipisahkan ;p adalah kebijakan; rua dan ruf menentukan ke mana laporan dikirim.
  4. 4Tidak ada apa-apa di sini? Naik ke atas_dmarc.mail.google.com adalah NXDOMAIN: record google.com yang berlaku.
Record paypal.com seperti dijawab Google Public DNS pada 24 Oktober 2026; mail.google.com tidak punya record sendiri.

Membaca hasilnya: sudut pandang penerima

Jawaban datang lebih dulu, sebagai satu kalimat. Di bawahnya, buktinya: record seperti yang diurai penerima, setiap tag diwarnai tepat di atas karakternya, dan di atas latar navy jalur yang ditempuh server penerima untuk domain ini, berakhir pada apa yang dilakukannya terhadap email yang gagal.

Tanpa skor: kebijakan di none adalah sebuah fase, bukan kegagalan, dan tangga di bawah jalur menjelaskan apa yang dibutuhkan langkah berikutnya.

Cek DMARC untuk paypal.com: menolak email yang gagal DMARC, dengan sudut pandang penerima dan tangga penegakanCek DMARC untuk paypal.com: menolak email yang gagal DMARC, dengan sudut pandang penerima dan tangga penegakanKesimpulanSatu kalimat tentang apa yang dilakukan penerima terhadap email yang gagal, dengan kebijakan, SPF, dan DKIM sekilas.RecordSetiap tag diwarnai di atas karakternya: arahkan kursor atau ketuk satu tag untuk melihat fungsinya. Default ada di bawahnya.Sudut pandang penerimaSetiap pertanyaan DNS yang diajukan server penerima untuk domain, berurutan, beserta jawabannya.Email yang gagal DMARCApa yang dilakukan penerima untuk domain, subdomain yang ada, dan nama yang tidak ada.Tangga penegakanDi mana domain berada antara none dan reject, dan apa yang dibutuhkan langkah berikutnya.
Cek DMARC untuk paypal.com: kesimpulan, record yang dipecah menjadi tag, sudut pandang penerima dengan setiap pertanyaan DNS dan nasib email yang gagal, serta tangga penegakan. Pilih sebuah angka untuk melihat apa yang ditunjukkan setiap bagian.

DMARC adalah apa, dan untuk apa dipakai?

DMARC memberi tahu server email penerima apa yang harus dilakukan terhadap email yang memakai domain Anda di baris From: tetapi tidak bisa membuktikan berasal dari Anda, dan ke mana laporan tentangnya dikirim (RFC 9989 §4.7).

Buktinya adalah SPF atau DKIM yang aligned dengan domain From:: SPF pass untuk domain bounce di organisasi yang sama, atau tanda tangan DKIM dengan d= domain Anda. Satu pass yang aligned sudah cukup (RFC 9989 §5.3.5); selain itu gagal DMARC, dan kebijakan record yang menentukan: kirim, folder spam, atau tolak.

Laporan adalah separuh lainnya. Penerima yang menghormati rua mengirim ringkasan harian setiap server yang mengirim atas nama domain Anda, dan dari situlah Anda menemukan pengirim sah yang terlupakan sebelum menegakkan kebijakan.

Dua pesan, satu baris From:

From: billing@example.comp=reject · rua=mailto:dmarc@example.com

Tagihan Anda, dikirim lewat layanan emaillewat layanan yang diatur dengan DKIM kustom, sehingga menandatangani dengan d=example.com

  1. SPFpass · bounces.esp.example (tidak aligned)
  2. DKIMpass · d=example.com (aligned)
  3. DMARCpass: satu hasil aligned sudah cukup
Terkirim

Tagihan palsu dari 203.0.113.9server yang tidak pernah diotorisasi example.com

  1. SPFfail · 203.0.113.9 tidak tercantum
  2. DKIMtidak ada · tanpa tanda tangan
  3. DMARCfail → p=reject
Ditolak

550 5.7.1 Email rejected per DMARC policy for example.com

Laporan agregat besok ke dmarc@example.com: 1 pesan dari 203.0.113.9, SPF fail, DKIM tidak ada, disposisi reject.

Pass tidak menjamin pengiriman (filter penerima tetap menentukan), dan fail di p=reject adalah permintaan, bukan perintah (RFC 9989 §5.4, §7.4). Alamat dari RFC 5737; teks balasan adalah contoh dari RFC 9989 sendiri.

Penjelasan tag record DMARC

Record DMARC adalah daftar pasangan tag=value dalam record TXT di _dmarc. ditambah domain: v=DMARC1 di awal, lalu tag kebijakan, alignment, dan pelaporan dalam urutan apa pun (RFC 9989 §4.7).

RFC 9989 (Mei 2026) menggantikan RFC 7489. RFC ini menambahkan np, psd, dan t, serta menghapus pct, rf, dan ri: penerima saat ini mengabaikannya, sedangkan penerima yang masih memakai RFC 7489 membacanya, sehingga record dengan pct=25 berarti hal berbeda bagi penerima yang berbeda.

Tag yang tidak Anda publikasikan memakai nilai defaultnya, dan pemeriksa juga menampilkannya: sp yang hilang berarti subdomain mendapat p.

Setiap tag, menurut fungsinya

v=DMARC1; p=reject; sp=quarantine; np=reject; adkim=r; aspf=r; rua=mailto:dmarc@example.com; ruf=mailto:forensic@example.com; fo=1
VersiKebijakanUji dan suffixAlignmentLaporanDihapus
TagYang diaturDefaultStatusTerlihat di
vVersiDMARC1wajib, di awalRFC 9989192
pKebijakan untuk domainnone · quarantine · rejectnone jika tidak ada dan rua validRFC 9989192
spKebijakan untuk subdomain yang adanone · quarantine · rejectpRFC 998939
npKebijakan untuk nama yang tidak adanone · quarantine · rejectsp, lalu pbaru di RFC 99892
tMode uji: satu tingkat di bawah kebijakany · nnbaru di RFC 99890
psdPublic suffix (y) atau domain organisasi (n)y · n · uubaru di RFC 99891
adkimAlignment DKIMr · srRFC 998920
aspfAlignment SPFr · srRFC 998924
ruaKe mana laporan agregat dikirimmailto:…tanpa laporanRFC 9989186
rufKe mana laporan kegagalan dikirimmailto:…tanpa laporanRFC 9989120
foKapan laporan kegagalan dikirim0 · 1 · d · s0RFC 998996
pctBagian email gagal yang dikenai kebijakan0–100–dihapus70
rfFormat laporan kegagalanafrf–dihapus9
riInterval laporan, dalam detik86400–dihapus14
Terlihat di: berapa banyak dari 192 record DMARC yang dipublikasikan 196 domain ternama membawa tag itu (dibaca 24 Oktober 2026; 69 dari 70 tag pct berisi pct=100). Default dan status dari RFC 9989 §4.7 dan Lampiran C.

Kebijakan DMARC: p=none vs quarantine vs reject

p=none meminta penerima mengirim email yang gagal seperti biasa dan hanya melaporkannya; quarantine meminta mereka memperlakukannya sebagai mencurigakan, biasanya folder spam; reject meminta mereka menolaknya saat percakapan SMTP.

None adalah sebuah fase, bukan kegagalan: RFC 9989 §7.4 menyarankan setidaknya sebulan di sana dengan laporan yang mengalir, dan selama itu lagi di quarantine, sebelum reject. Domain yang penggunanya memposting ke milis sebaiknya berhenti di quarantine.

Penyedia kotak surat besar pun berbeda-beda: gmail.com dan outlook.com memublikasikan p=none untuk domain itu sendiri dan sp=quarantine untuk subdomain, sedangkan google.com, yahoo.com, dan microsoft.com memublikasikan reject.

Ke mana email palsu berakhir

Terkirimp=none

apache.orggmail.comsamsung.com

23 dari 192

Folder spamp=quarantine

github.comapple.comamazon.com

30 dari 192

Ditolakp=reject

google.compaypal.commicrosoft.com

139 dari 192

none 23quarantine 30reject 139dari 192 record, 196 domain ternama, 24 Oktober 2026

Pada akhirnya penerima yang memutuskan: mereka boleh mengirim email yang gagal di p=reject, dan tidak boleh menolak hanya berdasarkan kebijakan (RFC 9989 §5.4, §7.4). Sebuah studi vendor menunjukkan seberapa tertinggal web secara umum: di 1,8 juta domain teratas pada awal 2026, EasyDMARC menemukan 29,2% di p=none dan 22,9% di quarantine atau reject.

Apakah DMARC benar-benar perlu?

Ya, jika Anda mengirim massal ke Gmail, Yahoo, atau Outlook.com: ketiganya mewajibkan record DMARC, dan p=none sudah cukup untuk memenuhi aturan. Penegakan (quarantine atau reject) yang menghentikan orang lain mengirim atas nama domain Anda, dan logo BIMI membutuhkannya.

Gmail mewajibkannya sejak 1 Februari 2024 bagi pengirim lebih dari 5.000 pesan sehari ke akun Gmail; Yahoo sejak Februari 2024, tanpa menyebut volume; Outlook.com sejak 5 Mei 2025, di atas 5.000 sehari. Tanpa record, Gmail menjawab 4.7.31 (dan 4.7.32 jika From: tidak aligned), sedangkan Outlook.com menolak dengan 550 5.7.515.

Untuk domain yang tidak mengirim apa pun, DMARC adalah perlindungan termurah: p=reject, null MX, dan v=spf1 -all, seperti yang dipublikasikan example.com (M3AAWG).

Apa yang diminta setiap penyedia kotak surat dari pengirim massal

Gmail1 Feb 20245.000+ sehari ke akun Gmail4.7.31 · 4.7.32
YahooFeb 2024tanpa ambang dipublikasikanDMARC harus pass
Outlook.com5 Mei 20255.000+ sehari550 5.7.515
Terkirimp=nonememenuhi aturan ketiga penyedia
Folder spamquarantinemenghentikan sebagian besar pemalsuan · logo BIMI dimungkinkan
Ditolakrejectmenghentikan pemalsuan di pintu · BIMI

✓Wajib: sebuah record, p=none atau lebih ketatiPerlindungan: quarantine atau reject

Dari halaman pengirim milik masing-masing penyedia, dibaca 24 Oktober 2026. Tingkat spam di bawah 0,3% dan berhenti berlangganan satu klik juga aturan, tetapi DNS tidak bisa menunjukkannya; tampilan Persyaratan pada pemeriksa menyebut bagian mana yang bisa dibuktikannya.

Cara memperbaiki kegagalan DMARC: penerusan, milis, domain milik vendor

Temukan sumber yang gagal di laporan agregat, lalu perbaiki di pengirimnya: tanda tangani dengan DKIM untuk domain Anda sendiri, atau pindahkan ke domain bounce di dalam organisasi Anda. Tiga penyebab mencakup sebagian besar kegagalan.

Penerusan mempertahankan tanda tangan DKIM tetapi merusak SPF, jadi DKIM yang membawa pass. Milis yang mengubah pesan merusak keduanya. Dan layanan email yang menandatangani dengan domainnya sendiri lolos DKIM untuk dirinya, bukan untuk Anda: aktifkan DKIM kustom layanan itu (biasanya CNAME seperti s1._domainkey) dan return path kustom.

Tiga kegagalan, apa yang ditunjukkan laporan, dan perbaikannya

Penerusan

  • SPF192.0.2.80 tidak ada di SPF example.com
  • DKIMtanda tangan utuh

Laporan menunjukkanspf=fail dkim=pass → pass

Tanda tangani semuanya dengan DKIM; DKIM bertahan saat diteruskan. ARC (RFC 8617) membantu penerus menjamin.

Milis

  • SPFserver milis yang mengirim
  • DKIMisi berubah: hash gagal

Laporan menunjukkanspf=fail dkim=fail → fail

Milis yang menulis ulang From: memperbaikinya; domain yang penggunanya memposting ke milis berhenti di quarantine (RFC 9989 §7.4).

Domain milik vendor

  • SPFpass untuk bounces.esp.example: tidak aligned
  • DKIMpass untuk esp.example: tidak aligned

Laporan menunjukkandkim=pass(esp.example) → fail

Aktifkan DKIM kustom vendor: s1 dan s2 milik paypal.com adalah CNAME ke SendGrid, yang menandatangani sebagai paypal.com.

Alamat dari RFC 5737; esp.example adalah nama contoh. CNAME SendGrid adalah selector asli paypal.com (24 Oktober 2026).

DMARC untuk subdomain: sp dan np

Subdomain tanpa record sendiri mendapat kebijakan domain organisasinya: sp untuk subdomain yang ada, np untuk nama yang tidak ada, masing-masing kembali ke p (RFC 9989 §4.7).

Subdomain yang memublikasikan record sendiri memakainya untuk dirinya. Tetapi record di antara sebuah nama dan domain organisasinya tidak pernah dipakai untuk nama itu: pohon berkeley.edu menunjukkannya, di mana sp=none milik eecs.berkeley.edu tidak sampai ke www.eecs.berkeley.edu (RFC 9989 §4.10.1).

np adalah kemenangan murah: nama yang tidak ada tidak mengirim email sungguhan, jadi np=reject memblokir pemalsuan dari nama itu bahkan saat p masih di none. Penerima RFC 7489 tidak mengenal np dan memakai sp.

Pohon berkeley.edu, seperti dibaca penerima

berkeley.edup=reject; np=reject; psd=n; rua=…record sendiri · psd=n: domain organisasiDitolak
www.berkeley.edutanpa recordada → sp, tidak ada → pDitolak
eecs.berkeley.edup=reject; sp=none; rua=…record sendiri → pDitolak
www.eecs.berkeley.edutanpa recordtelusuri: record eecs.berkeley.edu dilewati (bukan domain organisasi) → p milik berkeley.eduDitolak
nosuch-x7.berkeley.eduNXDOMAINtidak ada → npDitolak

sp=none milik eecs.berkeley.edu tidak pernah diterapkan: record di antara sebuah nama dan domain organisasinya tidak dipakai untuk nama itu (RFC 9989 §4.10.1). Pemeriksa menandainya sebagai record yang tidak dipakai.

Dibaca 24 Oktober 2026 lewat Google Public DNS. nosuch-x7.berkeley.edu adalah nama karangan; NXDOMAIN-nya asli.

Membaca laporan DMARC (rua)

Laporan agregat adalah berkas XML harian dari setiap penerima yang mencantumkan setiap server yang mengirim email atas nama domain Anda, berapa pesannya, dan apakah SPF, DKIM, dan DMARC pass (RFC 9990).

Bacalah per sumber: server dan layanan Anda sendiri seharusnya menunjukkan pass yang aligned; layanan dikenal yang gagal butuh DKIM kustomnya; alamat tak dikenal yang gagal di p=reject adalah pemalsuan, yang sudah dihentikan. Layanan laporan (dmarcian, Valimail, EasyDMARC, Postmark, dan lainnya) mengubah ribuan berkas menjadi daftar itu.

Laporan ke alamat di domain lain hanya tiba jika domain itu setuju: ia memublikasikan yourdomain._report._dmarc.its-host dengan v=DMARC1 (RFC 9990 §4). Pemeriksa menanyakannya untuk Anda, dan memberikan record persis yang diperlukan jika belum ada.

Satu laporan, dibaca baris demi baris

<org_name>google.com</org_name>1

<date_range>23 Okt, 00.00 UTC – 24 Okt, 00.00 UTC</date_range>

<policy_published>example.com · p=reject</policy_published>2

<source_ip>198.51.100.24</source_ip> <count>412</count> dkim=pass spf=fail → none3

<source_ip>203.0.113.9</source_ip> <count>37</count> dkim=fail spf=fail → reject4

  1. 1Siapa yang melaporSatu berkas per penerima per hari (RFC 9990: setidaknya setiap 24 jam).
  2. 2Kebijakan yang ditemukannyaApa yang dibacanya di _dmarc.example.com.
  3. 3Email yang diteruskan, diselamatkan DKIMSPF gagal di penerus; tanda tangan yang aligned lolos DMARC.
  4. 4Pemalsuan, dihentikanServer tak dikenal, tidak ada yang aligned, ditolak.
paypal.comrua=mailto:d@rua.agari.comrua.agari.compaypal.com._report._dmarc.rua.agari.com TXT "v=DMARC1;"✓ diotorisasi: laporan mengalir

Layanan laporan yang dikenali pemeriksadmarcianValimailEasyDMARCPostmarkCloudflareMimecastProofpointAgariRed SiftPowerDMARC+6 lagi

XML dipersingkat dan karangan (alamat dokumentasi, RFC 5737); record otorisasinya asli milik paypal.com, dibaca 24 Oktober 2026.

Cek DMARC: pertanyaan yang sering diajukan

DMARC adalah apa?

DMARC adalah record DNS yang memberi tahu server email penerima apa yang harus dilakukan terhadap email yang memakai domain Anda di baris From: tetapi gagal alignment SPF dan DKIM: mengirimnya, mengarantina, atau menolak. DMARC juga menyebut ke mana penerima mengirim laporan tentang email itu. Ia dipublikasikan sebagai record TXT di _dmarc ditambah domain Anda dan didefinisikan RFC 9989, yang menggantikan RFC 7489 pada Mei 2026.

Apa yang ditunjukkan pemeriksa record DMARC?

Ia membaca record TXT di _dmarc ditambah domain, dan milik domain induknya jika tidak ada, seperti yang dilakukan penerima. Pemeriksa ini menunjukkan record tag demi tag beserta defaultnya, kebijakan untuk domain, subdomain, dan nama yang tidak ada, apakah alamat laporan mau menerima laporan, serta record SPF dan kunci DKIM domain, tanpa skor.

Bagaimana cara menguji DMARC?

Cek domain di atas untuk kebijakan yang dipublikasikan: itulah uji DMARC yang bisa dijawab DNS. Untuk melihat apakah pesan sungguhan pass, kirim satu ke kotak surat yang Anda kuasai dan baca header Authentication-Results-nya, atau tempel header ke Analisis Header Email. Validator DMARC mengecek sintaks record; hanya pesan yang menunjukkan apakah SPF atau DKIM aligned.

Kebijakan DMARC mana yang sebaiknya dipakai lebih dulu?

Mulailah dengan p=none dan alamat rua, agar penerima mengirim laporan harian tanpa mengubah pengiriman. Perbaiki setiap pengirim sah yang gagal, biasanya dengan mengaktifkan DKIM kustomnya, lalu naik ke quarantine dan akhirnya reject. RFC 9989 menyarankan minimal sebulan di p=none dan selama itu lagi di quarantine. Domain yang tidak mengirim email bisa langsung ke p=reject.

Apakah p=none melindungi domain saya?

Tidak. p=none meminta penerima menangani email yang gagal seperti biasa, jadi pesan palsu hanya dinilai oleh filter spam mereka sendiri. Yang diberikannya adalah laporan, dan ia memenuhi aturan pengirim massal Gmail, Yahoo, dan Outlook.com. Anggap ini fase pemantauan: perlindungan dimulai di quarantine, dan reject menghentikan email palsu sebelum sampai ke siapa pun.

Apa arti t=y dalam record DMARC?

t=y adalah mode uji RFC 9989: penerima menerapkan satu tingkat di bawah kebijakan yang dipublikasikan, jadi p=reject bertindak seperti quarantine dan p=quarantine seperti none. Ia tidak berpengaruh pada p=none dan tidak mengubah laporan. Penerima yang masih memakai RFC 7489 tidak mengenal tag ini dan menerapkan kebijakan apa adanya. Hapus t=y setelah laporan menunjukkan semua pengirim sah aligned.

Apakah tag pct masih dipakai?

RFC 9989 menghapus pct, bersama rf dan ri, karena nilai selain 0 dan 100 diterapkan tidak konsisten. Penerima saat ini mengabaikannya dan menerapkan kebijakan ke semua email yang gagal. Penerima yang masih memakai RFC 7489 melakukan sampling: pct=25 di quarantine mengirim seperempat email yang gagal ke spam dan mengirim sisanya. pct=100 tidak berbahaya; untuk fase uji, pakai t=y.

Mengapa alamat rua saya "belum diotorisasi"?

Jika laporan dikirim ke kotak surat di domain organisasi lain, domain itu harus setuju dengan memublikasikan record TXT bernama yourdomain._report._dmarc.its-host dengan nilai v=DMARC1 (RFC 9990 §4). Tanpanya, penerima yang mengecek melewati alamat itu. Record ini ada di DNS tujuan, bukan DNS Anda: layanan laporan memublikasikan wildcard untuk semua pelanggan, jadi biasanya ini berarti salah ketik atau kotak surat milik mitra.

Apakah subdomain perlu record DMARC sendiri?

Biasanya tidak. Subdomain tanpa record mendapat kebijakan domain organisasinya: sp untuk subdomain yang ada, np untuk nama yang tidak ada, keduanya kembali ke p. Publikasikan satu di subdomain hanya jika butuh kebijakan berbeda. Record di nama perantara, seperti team.example.com untuk www.team.example.com, tidak dipakai untuk nama yang lebih dalam.

Apa yang terjadi jika domain memublikasikan dua record DMARC?

Penerima membuang keduanya, jadi tidak ada kebijakan DMARC yang berlaku dan tidak ada laporan yang dikirim, bahkan jika salah satunya berisi reject (RFC 9989 §4.10). Biasanya ini terjadi saat record baru ditambahkan tanpa menghapus yang lama, atau saat penyedia DNS menambahkan default. Sisakan satu record di _dmarc dan hapus yang lain; pemeriksa menunjukkan mana yang tampak dimaksudkan.

Mengapa DMARC gagal padahal SPF pass?

DMARC butuh SPF pass untuk domain yang aligned dengan alamat From:. Sebagian besar layanan email mengirim dengan domain bounce miliknya sendiri, jadi SPF pass untuk mereka, bukan untuk Anda, dan tidak dihitung. Hal yang sama berlaku untuk DKIM yang ditandatangani dengan domain layanan. Siapkan DKIM kustom atau return path kustom layanan itu agar domain yang pass adalah milik Anda.

Pemeriksa menunjukkan tanpa record, padahal baru saya tambahkan. Mengapa?

Cek dulu kolom host: kebanyakan panel DNS hanya meminta _dmarc, dan mengetik _dmarc.example.com di sana membuat _dmarc.example.com.example.com. Lalu tunggu jawaban lama kedaluwarsa: jika nama itu pernah dicari, resolver menyimpan NXDOMAIN-nya selama TTL negatif zona, sering 5 menit sampai satu jam. SERVFAIL atau timeout tampil sebagai "tidak bisa dicek", tidak pernah sebagai tanpa record.

Ada yang kurang?Usulkan fitur atau alat baru

Alat email dan DNS terkait