DMARC ieraksta pārbaudītājs

DMARC ieraksta struktūra un tā komponenti

DMARC (Domain-based Message Authentication, Reporting, and Conformance) ir e-pasta autentifikācijas protokols, kas izmanto SPF (Sender Policy Framework) un DKIM (DomainKeys Identified Mail), lai aizsargātu domēnu pret e-pasta viltošanu. Lai DMARC darbotos pareizi, domēna DNS zonā ir jāpublicē TXT ieraksts ar precīzu sintaksi un noteiktiem elementiem.

Katrs DMARC ieraksts sastāv no elementu jeb tagu virknes, kurus atdala ar semikoliem. Šo elementu secībai, vērtībām un pareizrakstībai ir izšķiroša nozīme, lai saņemošie pasta serveri spētu pareizi interpretēt jūsu domēna drošības politiku. "DMARC ieraksta pārbaudītājs" analizē šo ierakstu struktūru, identificē aktīvos, vēsturiskos vai nederīgos elementus un palīdz novērst konfigurācijas kļūdas pirms ieraksta publicēšanas DNS.

Svarīgākie DMARC elementi un to loma

DMARC ieraksts satur vairākus parametrus, kas nosaka, kā saņēmējam jārīkojas ar e-pastiem, kuri neiziet autentifikāciju.

• Protokola versija (v): Katram DMARC ierakstam ir jāsākas ar elementu v=DMARC1. Šis lielums ir reģistrjutīgs, un tam ir jābūt pašam pirmajam elementam ierakstā. Ja šis nosacījums netiek izpildīts, saņemošās sistēmas ierakstu ignorēs.
• Domēna politika (p): Šis elements nosaka galveno politiku jūsu pamatdomēnam. Ja elements p nav norādīts, tiek piemērota noklusējuma politika none.
• Apakšdomēnu politika (sp): Nosaka politiku visiem pamatdomēna apakšdomēniem. Ja šis elements nav definēts, apakšdomēni manto pamatdomēna politiku p.
• Neeksistējošu apakšdomēnu politika (np): Nosaka politiku apakšdomēniem, kas faktiski neeksistē. Ja elements np nav norādīts, sistēma meklē specifiskāko pieejamo tagu, pakāpeniski atkāpjoties no np uz sp un galu galā uz pamatdomēna politiku p.

DMARC politiku veidi un to ietekme

DMARC definē trīs galvenos politikas līmeņus, kas nosaka e-pasta ziņojumu apstrādi:

1. none (tikai monitorings): Šī politika tiek izmantota, lai uzraudzītu e-pasta plūsmu un saņemtu atskaites, taču tā nepieprasa saņēmējiem ierobežot vai noraidīt ziņojumus, kas neiziet SPF vai DKIM pārbaudes.
2. quarantine (karantīna): Pieprasa saņemošajiem serveriem aizdomīgos e-pastus novirzīt uz mēstuļu mapi vai paturēt karantīnā, nevis piegādāt tieši iesūtnē.
3. reject (noraidīšana): Stingrākā politika, kas pieprasa saņemošajiem serveriem pilnībā noraidīt un nepiegādāt e-pastus, kuri nav izgājuši autentifikāciju.

Testēšanas režīmā elementam t=y ir īpaša nozīme: tas pazemina politikas stingrību. Proti, ja ir iestatīta politika reject, elements t=y to pazemina līdz quarantine, savukārt politiku quarantine tas pazemina līdz none. Tas ļauj droši pārbaudīt konfigurāciju, neriskējot ar leģitīmu e-pastu pazaudēšanu.

Atskaišu konfigurēšana (rua un ruf)

DMARC nodrošina atgriezenisko saiti par e-pasta sūtījumiem, izmantojot divu veidu atskaites:

• Agregētās atskaites (rua): Nosaka e-pasta adreses, uz kurām jāsūta apkopotie dati par e-pasta plūsmu un autentifikācijas statusiem. Ja nav norādīta derīga rua adrese, agregētās atskaites netiek pieprasītas.
• Kļūmju atskaites (ruf): Nosaka adreses, uz kurām jāsūta detalizēta informācija par konkrētiem ziņojumiem, kas nav izgājuši autentifikāciju. Elements fo (kļūmju ziņošanas opcijas) tiek ignorēts, ja ierakstā nav norādīta derīga ruf kļūmju atskaišu adrese.

Mūsdienu standartos daži vēsturiskie parametri ir zaudējuši savu nozīmi. Piemēram, sufikss !size atskaites URI adresē ir novecojis, un pašreizējām saņemošajām sistēmām tas ir jāignorē. Tāpat arī procentuālais sadalījums pct ir uzskatāms par vēsturisku elementu, kas ierobežo politikas piemērošanu tikai tajās saņemošajās sistēmās, kuras joprojām izmanto vecākas DMARC specifikācijas.

Identifikatoru saskaņošana (Alignment)

DMARC pārbauda, vai domēns sūtītāja adresē From: sakrīt ar domēniem, kas norādīti SPF un DKIM pārbaudēs. Šo saskaņošanu kontrolē divi parametri:

• aspf: SPF identifikatoru saskaņošanas režīms (var būt stingrs vai piekļāvīgs).
• adkim: DKIM identifikatoru saskaņošanas režīms (stingrs vai piekļāvīgs).

Biežākās sintakses kļūdas DMARC ierakstos

Analizējot DMARC ierakstus, bieži tiek pieļautas kļūdas, kas padara visu ierakstu nederīgu vai neefektīvu. Šis rīks palīdz identificēt šādas problēmas:

• Nepareizs sākums: Ieraksts nesākas ar v=DMARC1 vai šis elements nav pirmajā vietā.
• Dublēti elementi: Viens un tas pats tags (piemēram, p vai rua) parādās vairākas reizes.
• Slikti noformēti tagi: Elementi nav atdalīti ar semikoliem vai neatbilst formātam nosaukums=vērtība.
• Tukšas vērtības: Norādīts taga nosaukums, bet tam nav piešķirta vērtība.
• Nereģistrēti vai vēsturiski tagi: Izmantoti elementi, kurus pašreizējie DMARC saņēmēji ignorē vai uzskata par novecojušiem.

Kā darbojas DMARC ieraksta pārbaudītājs

Šis rīks ir izstrādāts, lai palīdzētu pasta administratoriem pārbaudīt DMARC TXT ieraksta struktūru pirms tā publicēšanas DNS zonā.

Ievades dati

Lietotājs ievada DMARC TXT vērtību, kuras garums nepārsniedz 20 000 rakstzīmju. Rīks atbalsta arī pēdiņās ietvertas DNS TXT daļas, kuras pirms analīzes tiek automātiski apvienotas vienā virknē.

Analīzes rezultāti

Pēc pārbaudes veikšanas rīks izvada šādu informāciju:

1. DMARC kopsavilkums: Parāda galvenos iestatījumus, tostarp domēna politiku (p), apakšdomēnu politiku (sp), neeksistējošu apakšdomēnu politiku (np), identifikatoru saskaņošanu (DKIM / SPF), atskaišu skaitu un vēsturisko procentuālo vērtību (pct).
2. Atskaites galamērķi: Detalizēta informācija par agregēto (rua) un kļūmju (ruf) atskaišu adresēm.
3. Analizētie elementi: Tabula ar visiem ierakstā identificētajiem tagiem, to vērtībām un statusu (Aktīvs, Vēsturisks, Nezināms vai Nederīgs).
4. Sintakses un politikas piezīmes: Saraksts ar brīdinājumiem un kļūmēm, kas palīdz izprast ieraksta interpretāciju un novērst nepilnības.

Privātums un datu apstrāde

Jūsu ievadītais DMARC ieraksts tiek apstrādāts lokāli jūsu tīmekļa pārlūkprogrammā. Rīks neaugšupielādē un nesaglabā ievadītos datus, tie netiek ierakstīti pārlūka krātuvē, un netiek veikti nekādi ārēji tīkla pieprasījumi.

---

Biežāk uzdotie jautājumi (FAQ)

Sintakses un politikas piezīmes: p / sp / np?

Ja ierakstā nav norādīts p tags, domēna politika automātiski kļūst par none. Ja izmantojat t=y testēšanas režīmu, saņēmēji pazemina politiku reject uz quarantine, bet quarantine uz none. Ja nav norādīts specifisks apakšdomēnu taga ieraksts, sistēma meklē politiku secībā: np → sp → p.

RFC 9989: pct / rf / ri?

Nē. Šī lapa pārbauda tikai jūsu ielīmēto tekstu. Tā neveic DNS vaicājumus, neizvērš pakalpojumu sniedzēju ierakstus, nepārbauda sūtītāja IP un neapstiprina, ko atgriezīs saņemošais pasta serveris. Saskaņā ar jaunāko standartu RFC 9989 tādi elementi kā pct, rf un ri ir uzskatāmi par vēsturiskiem (historic), savukārt np, psd un t ir aktīvi (active).

Vai nevainojams rezultāts pierāda, ka mana DMARC konfigurācija darbojas?

Nē. Šī lapa pārbauda tikai jūsu ielīmēto tekstu. Tā neveic DNS vaicājumus, neizvērš pakalpojumu sniedzēju ierakstus, nepārbauda sūtītāja IP un neapstiprina, ko atgriezīs saņemošais pasta serveris. Nevainojams rezultāts rīka analīzē nozīmē tikai to, ka ielīmētā teksta sintakse un loģiskā struktūra ir pareiza.