Tagasuri ng DMARC Record

Ang DMARC (Domain-based Message Authentication, Reporting, and Conformance) ay isang mahalagang protocol sa seguridad ng email na nagbibigay-daan sa mga may-ari ng domain na protektahan ang kanilang pagkakakilanlan laban sa spoofing. Gumagana ang "Tagasuri ng DMARC Record" sa pamamagitan ng pag-parse sa ibinigay na DMARC TXT record upang suriin ang mga patakaran nito, alignment settings, mga address para sa ulat, at mga legacy na halaga ng porsyento. Tinutukoy ng tool ang mga invalid na tag at nagbibigay ng mga tala sa syntax at patakaran upang matulungan ang mga administrator na maunawaan kung paano binibigyang-kahulugan ng mga receiving system ang kanilang record.

Pagproseso at Privacy ng Data

Ang paggamit sa tool na ito ay sumusunod sa mahigpit na patakaran sa lokal na pagproseso. Nananatili sa iyong browser ang DMARC record. Hindi ito ina-upload o sine-save ng BroBroGo. Ang inilagay na DMARC TXT value ay hindi isinusulat sa storage ng browser, at walang anumang panlabas na request na nauugnay sa record ang ipinapadala sa network.

Pagsusuri sa mga Bahagi ng DMARC Record

Ang isang wastong DMARC record ay binubuo ng mga partikular na tag na nagdidikta kung paano dapat hawakan ng mga mail server ang mga mensaheng hindi pumapasa sa SPF (Sender Policy Framework) at DKIM (DomainKeys Identified Mail) na pagpapatunay.

Ang Papel ng v=DMARC1

Ang bawat DMARC record ay dapat magsimula sa tag na v=DMARC1. Ang halagang ito ay case-sensitive at dapat na siyang unang tag sa buong string. Kung wala ito o kung hindi ito ang unang elemento, hindi kikilalanin ng mga receiving system ang record bilang isang DMARC policy.

Mga Patakaran sa Domain (p, sp, np)

Tinutukoy ng mga patakaran kung anong aksyon ang dapat gawin ng receiver kapag nabigo ang pagpapatunay ng email:

• p: Ang pangunahing patakaran para sa root domain. Kung walang p tag na nakita, ang patakaran ng domain ay awtomatikong babalik sa none. Ang patakarang p=none ay nagmamasid lamang sa mga pagkabigo at hindi humihiling sa mga receiver na i-quarantine o i-reject ang mga email na hindi pumasa sa pagsusuri.
• sp: Ang patakarang inilalapat sa mga subdomain ng root domain.
• np: Ang patakaran para sa mga subdomain na hindi umiiral sa DNS.

Kapag walang mas partikular na tag na tinukoy sa record, ang patakaran para sa mga subdomain ay may sinusunod na fallback hierarchy: mula np patungong sp, at sa huli ay babalik sa pangunahing p.

Pagsusuri sa Alignment at Testing Mode (t=y)

Ang identifier alignment ay nagpapasya kung gaano kahigpit ang pagtutugma ng domain sa From header laban sa mga domain sa SPF at DKIM.

Sa panahon ng paglipat o pagsubok, ang tag na t=y ay ginagamit upang ilagay ang DMARC sa testing mode. Ang tag na ito ay may direktang epekto sa pagpapatupad ng patakaran: pinapababa ng t=y ang patakarang quarantine patungong none, at ang patakarang reject naman ay pinapababa patungong quarantine habang isinasagawa ang pagsubok.

Pag-configure ng mga Ulat (rua at ruf)

Ang DMARC ay nagbibigay ng mekanismo para sa feedback sa pamamagitan ng dalawang uri ng ulat:

• rua: Naglalaman ng pangkalahatang istatistika ng trapiko ng email. Kung walang wastong rua address na tinukoy sa record, hindi hihilingin ang mga aggregate report sa mga receiver.
• ruf: Naglalaman ng mga detalyadong impormasyon sa mga partikular na mensaheng nabigo sa pagpapatunay.

Ang opsyonal na tag na fo (failure reporting options) ay may direktang dependency sa ruf. Kung walang wastong ruf failure-report address na nakalagay sa record, ang tag na fo ay babalewalain ng mga receiving system.

Mga Historic na Tag at Pagbabago sa Standard

Sa pag-unlad ng mga pamantayan ng DMARC mula sa RFC 7489 patungo sa RFC 9989, ilang mga tag at katangian ang itinuturing na ngayong historic o obsolete:

• pct (RFC 7489): Ang tag na pct ay itinuturing nang historic. Nililimitahan lamang nito ang saklaw ng patakaran para sa mga receiver na sumusunod pa rin sa mas lumang mga detalye ng DMARC.
• Ang!size suffix: Ang paggamit ng !size suffix sa isang report URI (halimbawa sa rua o ruf) ay lipas na o obsolete. Dapat na itong balewalain ng mga modernong receiving system.
• Mga Historic Tag: Ang tool ay nagmamarka ng mga tag na lipas na upang malaman ng administrator na maaari na itong balewalain ng mga system na sumusunod sa kasalukuyang pamantayan.

Mga Panuntunan sa Input at Pagsusuri ng Tool

Upang magamit ang tool, i-paste ang DMARC TXT value sa input field. Ang tool ay may limitasyon na dapat ay mas mababa sa 20,000 character ang haba ng record.

Kung ang kinopyang DNS record ay naglalaman ng mga naka-quote na DNS TXT chunk, awtomatiko itong tinatanggap at pinagsasama ng tool bago simulan ang pagsusuri. Pagkatapos ng proseso, ipapakita ng tool ang sumusunod na istruktura ng resulta:

1. Buod ng DMARC: Nagpapakita ng pangkalahatang estado ng p, sp, np, alignment ng DKIM/SPF, bilang ng mga address sa rua/ruf, at ang halaga ng pct.
2. rua / ruf: Detalyadong listahan ng mga destinasyon ng ulat.
3. Mga nasuring termino: Isang talahanayan na naglalaman ng Termino, Value o qualifier, at Uri (tulong sa pagtukoy kung ito ay RFC 9989, RFC 7489, Hindi kilala, o invalid).
4. Mga tala sa syntax at patakaran: Listahan ng mga babala o isyu sa istruktura.

Mga Karaniwang Error at Mensahe ng System

Sa panahon ng pagsusuri, maaaring lumitaw ang mga sumusunod na mensahe ng error o abiso depende sa kalidad ng inilagay na record:

• "Maglagay ng suportadong DMARC record."
• "Mag-paste muna ng DMARC record."
• "Hindi pangkaraniwang malaki ang record na iyon. Panatilihin itong mas mababa sa 20,000 character."
• "Dapat magsimula ang record sa v=DMARC1."
• "Termino ‹position›: dapat unang termino ang v=DMARC1."
• "×2: ‹tag› (‹position›)" (para sa mga duplicate na tag)
• "name=value ✕ (‹position›)" (para sa mga malformed na tag na hindi gumagamit ng semicolon bilang separator)
• "‹tag›=∅ (‹position›)" (kapag walang halaga ang tag)
• "‹tag›=‹detail› ✕ (‹position›)" (para sa mga invalid na halaga)
• "URI ✕: ‹tag› (‹position›)" (kapag mali ang format ng email address sa ulat)
• "Hindi kilala: ‹tag› (‹position›)" (para sa mga hindi rehistradong tag)
• "RFC 7489 → RFC 9989: ‹tag› (‹position›)" (para sa mga historic na tag)

Mga Madalas Itanong (FAQ)

Mga tala sa syntax at patakaran: p / sp / np?

Ang p ay ang patakaran para sa pangunahing domain, ang sp ay para sa mga subdomain, at ang np ay para sa mga hindi umiiral na subdomain. Kung walang tinukoy na p tag, awtomatikong gagamitin ang p=none. Ang testing mode na t=y ay nagpapababa sa higpit ng patakaran (ang reject ay nagiging quarantine, at ang quarantine ay nagiging none). Kung walang mas partikular na tag, ang hierarchy ng pagpapatupad ay sumusunod sa pagkakasunod-sunod na np patungong sp at babalik sa p.

RFC 9989: pct / rf / ri?

Hindi. Ang tekstong ipe-paste mo lang ang sinusuri ng pahinang ito. Hindi ito nagtatanong sa DNS, nagpapalawak ng provider records, sumusubok ng sender IP, o nagkukumpirma ng tugon ng receiving mail server. RFC 9989: pct / rf / ri → historic; np / psd / t → active.

Pinatutunayan ba ng malinis na resulta na gumagana ang aking DMARC setup?

Hindi. Ang tekstong ipe-paste mo lang ang sinusuri ng pahinang ito. Hindi ito nagtatanong sa DNS, nagpapalawak ng provider records, sumusubok ng sender IP, o nagkukumpirma ng tugon ng receiving mail server. Ang tool na ito ay nakatuon lamang sa pagsusuri ng syntax, mga tag, at mga patakaran ng string na iyong ibinigay.