Pemeriksa Cathetan DMARC

Pangerten dhasar Cathetan DMARC

DMARC (Domain-based Message Authentication, Reporting, and Conformance) yaiku protokol standar sing digunakake dening pemilik domain kanggo nglindhungi domain saka panggunaan sing ora sah, kayata spoofing email. Protokol iki nggunakake cathetan TXT ing DNS sing diwiwiti nganggo nilai sing sensitif marang aksara gedhe-cilik (case-sensitive) yaiku v=DMARC1. Nilai v=DMARC1 iki kudu dadi istilah utawa tag sing kapisan ing njeron cathetan. Yen ora diwiwiti nganggo tag iki, utawa yen posisi tag kasebut salah, sistem panampa email ora bakal bisa ngenali cathetan kasebut minangka instruksi DMARC sing sah.

Pemeriksa Cathetan DMARC minangka piranti sing dirancang kanggo mriksa lan njlentrehake isi saka cathetan TXT DMARC sing sampeyan lebokake. Piranti iki mriksa struktur sintaksis, pilihan kabijakan, alamat laporan, lan persentase panggunaan kanggo mesthekake kabeh komponen kasebut wis bener sadurunge dipublikasikake ing DNS.

Cara Kerja lan Aturan Pamriksan

Nalika sampeyan nglebokake nilai DMARC TXT, piranti iki bakal nindakake analisis adhedhasar aturan lan watesan tartamtu:

• Watesan Karakter: Nilai sing dilebokake kudu ing sangisore 20,000 karakter. Yen ngluwihi watesan iki, piranti bakal nampilake pesen kesalahan "Cathetan kuwi gedhe banget. Tetepna ing sangisore 20,000 karakter.".
• Panggabungan Potongan DNS: Yen sampeyan nglebokake potongan DNS TXT sing ana ing njeron tandha petik, piranti bakal nggabungake potongan kasebut dadi siji senar (string) sadurunge dianalisis. Nalika kedadeyan iki, cathetan "Potongan DNS TXT ing tandha petik digabungake sadurunge dianalisis." bakal ditampilake.
• Urutan Tag: Tag v=DMARC1 kudu dadi tag sing kapisan. Yen ana ing posisi liya, bakal metu pesen "Istilah ‹position›: v=DMARC1 kudu dadi istilah pisanan.".
• Duplikasi lan Kerusakan Tag: Saben tag mung entuk metu sepisan. Yen ana tag sing kaping pindho, bakal metu pesen "×2: ‹tag› (‹position›)". Yen format tag ora nggunakake pasangan jeneng lan nilai sing dipisahake nganggo titik koma, bakal metu pesen "name=value ✕ (‹position›)".

Kabijakan Domain lan Subdomain (p, sp, np)

Kabijakan DMARC nemtokake tumindak apa sing kudu ditindakake dening server panampa email nalika nampa pesen sing gagal verifikasi SPF utawa DKIM. Ana telung jinis tag kabijakan sing dianalisis dening piranti iki:

1. Domain Policy (p): Iki minangka kabijakan utama kanggo domain tingkat dhuwur. Yen tag p ora ditemokake ing cathetan, kabijakan domain kanthi otomatis bakal mudhun (fallback) menyang none. Kabijakan p=none mung digunakake kanggo ngawasi (monitoring) lan ora njaluk panampa email kanggo nolak utawa ngarantina email sing gagal.
2. Subdomain Policy (sp): Kabijakan khusus sing ditrapake kanggo subdomain.
3. Non-existent Subdomains Policy (np): Kabijakan khusus kanggo subdomain sing ora ana utawa ora didaftar.

Yen tag sing luwih spesifik ora ana, kabijakan subdomain bakal mudhun kanthi urutan saka np menyang sp, lan pungkasan bakal nggunakake kabijakan utama p.

Saliyane iku, ana mode uji coba nggunakake tag t=y. Nalika mode iki aktif, kabijakan quarantine bakal mudhun dadi none, lan kabijakan reject bakal mudhun dadi quarantine sajrone proses tes.

Konfigurasi Laporan (rua lan ruf)

DMARC nyedhiyakake mekanisme umpan balik liwat rong jinis laporan:

• Laporan Agregat (rua): Alamat email sing digunakake kanggo nampa ringkesan laporan aktivitas pangiriman email. Yen ora ana alamat rua sing sah, laporan agregat ora bakal dijaluk.
• Laporan Gagal (ruf): Alamat email kanggo nampa rincian informasi nalika ana email sing gagal verifikasi.

Piranti iki uga mriksa aturan khusus gegayutan karo laporan:

• Tag fo (failure options) bakal diabaikan yen ora ana alamat ruf sing sah ing cathetan kasebut.
• Suffix !size sing asring ditempelake ing URI laporan saiki wis kuna (obsolete) lan kudu diabaikan dening sistem panampa email modern miturut standar RFC 9989.

Tag Historis lan Standar RFC

Sajrone owah-owahan standar saka RFC 7489 menyang RFC 9989, sawetara tag saiki wis dianggep minangka tag historis utawa kuna. Piranti iki bakal menehi tandha marang tag kasebut:

• Persentase (pct): Nilai pct digunakake kanggo mbatesi cakupan kabijakan mung kanggo panampa sing isih nggunakake spesifikasi DMARC lawas. Ing standar saiki, nilai iki dianggep minangka fitur historis.
• Status Tag: Saben tag sing dianalisis bakal dikelompokake dadi papat status, yaiku RFC 9989 (Aktif), RFC 7489 (Historis), Ora dingerteni, utawa ✕ DMARC (Ora sah). Tag sing ora didaftar bakal diabaikan dening sistem panampa DMARC.

Keamanan Data lan Pangolahan

Proses pamriksan cathetan DMARC iki ditindakake kanthi lokal ing njeron browser pangguna. Ora ana data utawa teks cathetan sing diunggah menyang server njaba utawa disimpen ing panyimpenan browser. Piranti iki uga ora ngirim panjaluk (request) metu menyang internet nalika nindakake analisis.

---

Pitakonan sing Asring Ditakoni (FAQ)

Cathetan sintaks lan kabijakan: p / sp / np? Kabijakan utama ditemtokake dening tag p. Yen p=none, sistem mung ngawasi lan ora njaluk panyaring email kanggo nolak pesen. Nalika nindakake tes nganggo t=y, tingkat kabijakan bakal mudhun (reject dadi quarantine, lan quarantine dadi none). Kanggo subdomain, urutan penurunan kabijakan (fallback) yaiku saka np menyang sp, banjur menyang p yen tag sing luwih spesifik ora ditemokake.

RFC 9989: pct / rf / ri? Ora. Kaca iki mung mriksa teks sing sampeyan tempel. Ora takon DNS, ngembangake cathetan panyedhiya, nguji IP pangirim, utawa mesthekake tanggapan server email panampa. Miturut standar RFC 9989, tag kayata pct, rf, lan ri wis dianggep minangka tag historis (historic), dene tag kayata np, psd, lan t minangka tag sing aktif.

Apa asil sing resik mbuktekake yen setelan DMARC bisa digunakake? Ora. Kaca iki mung mriksa teks sing sampeyan tempel. Ora takon DNS, ngembangake cathetan panyedhiya, nguji IP pangirim, utawa mesthekake tanggapan server email panampa. Asil sing resik mung nuduhake yen sintaksis lan struktur cathetan sing sampeyan tempel wis bener miturut aturan DMARC.