DMARC pārskatu lasīšana

4. modulis: Nogādājamība: SPF, DKIM un DMARC praksē · Lasīšanas laiks: 12 minūtes

Mērķis: Pēc šīs nodarbības Jūs varēsiet atvērt un izlasīt DMARC apkopojošo pārskatu, katrai rindai noteikt, kāds ir avots un kāpēc tas iztur vai neiztur pārbaudi, un izlemt, ko labot, ko drīkst ignorēt un kad varat stingrināt savu politiku.

Pamatjēdzieni: apkopojošais pārskats (aggregate report, RFC 9990), rua, XML, gzip vai zip, report_metadata, policy_published, record, row, source_ip, count, policy_evaluated (disposition, dkim, spf), identifiers (header_from, envelope_from), auth_results, selektors, kļūdu pārskats (ruf, RFC 9991), pārskatu pakalpojums, privātums

Ko Jūs saņemsiet

Ja savā DMARC ierakstā esat norādījuši rua adresi (nodarbība 4.4), lielie saņēmēji, piemēram, Google, Microsoft un Yahoo, Jums aptuveni katru dienu nosūtīs apkopojošo pārskatu. Tas ir e-pasts ar pielikumu, parasti saspiestu (gzip) XML failu ar nosaukumu, piemēram:

receiver.example!example.com!1793923200!1794009599.xml.gz

Tas nozīmē: no saņēmēja receiver.example, par Jūsu domēnu example.com, par periodu starp abiem laika zīmogiem (sekundes kopš 1970. gada; šeit 2026. gada 6. novembris, visa diena UTC laikā).

Pārskats nesatur e-pasta saturu, tematus, un parasti arī ne saņēmēju adreses. Tas satur katra nosūtītāja servera ziņu skaitu un SPF, DKIM un DMARC rezultātu. Tādēļ tas ir uzticams pārskats par to, kas sūta e-pastu Jūsu domēna vārdā, arī par avotiem, par kuriem pats biji aizmirsis, un par krāpniekiem.

Pārskata uzbūve

Pārskatam ir trīs daļas. Zemāk svarīgākie fragmenti no šīs nodarbības piemēra faila (dmarc-rapport-1.xml).

1. Kas ziņo un par kādu periodu

<report_metadata>
  <org_name>receiver.example</org_name>
  <email>noreply-dmarc@receiver.example</email>
  <report_id>receiver.example-20261106-7f3c2a91</report_id>
  <date_range>
    <begin>1793923200</begin>
    <end>1794009599</end>
  </date_range>
</report_metadata>

2. Kādu politiku saņēmējs atrada pie Jums

<policy_published>
  <domain>example.com</domain>
  <p>none</p>
  <sp>none</sp>
  <np>none</np>
  <adkim>r</adkim>
  <aspf>r</aspf>
  <testing>n</testing>
</policy_published>

Vienmēr to pārbaudiet: ja šeit nav tas, ko domājāt, ka ir Jūsu DNS, tad saņēmējs izlasīja citu (vai vecu) ierakstu.

3. Katram avotam: ieraksts (record)

Katrs record attiecas uz vienu nosūtītāja IP adresi ar vienu rezultātu kombināciju:

<record>
  <row>
    <source_ip>198.51.100.40</source_ip>
    <count>1250</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <envelope_from>bounce.mailer.example</envelope_from>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>mailer.example</domain>
      <selector>k1</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>bounce.mailer.example</domain>
      <scope>mfrom</scope>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

Svarīgākā atšķirība: auth_results pretstatā policy_evaluated

Šeit ir lasīšanas būtība. Iepriekšējā piemērā auth_results ir divas reizes pass: DKIM izturēja pārbaudi domēnam mailer.example, un SPF izturēja pārbaudi domēnam bounce.mailer.example. Taču policy_evaluated divas reizes rāda fail. Tā nav pretruna: policy_evaluated ieskaita tikai tādu iztures pārbaudi, kas ir salāgota ar header_from. Neviens no abiem domēniem nepieder pie example.com, tāpēc DMARC neiztur pārbaudi.

Tā lasāma katra rinda:

1. Skatieties uz policy_evaluated. Vai pie dkim vai spf ir pass? Tad DMARC iztur pārbaudi un šis avots ir kārtībā.
2. Ja viss neiztur? Skatieties auth_results domēnus. Vai tas ir Jūsu izmantots pakalpojums, kas gan iztur pārbaudi, bet ar savu domēnu? Tad pie šī pakalpojuma jāieslēdz DKIM ar savu domēnu (nodarbība 4.3).
3. Ja arī auth_results neiztur, vai DKIM pilnīgi trūkst? Noskaidrojiet, kam pieder IP adrese (reverse DNS, nodarbība 5.1, vai whois meklēšana). Ja tā ir kāda no Jūsu sistēmām: jālabo. Ja tā nav zināma un ir aizdomīgs daudzums: visticamāk, viltojums.

Modeļi, ko redzēsiet atkārtoti

Pievērsiet uzmanību arī IPv6: pats serveris, kas dažkārt nosūta caur IPv6, kamēr Jūsu SPF minēta tikai IPv4 adrese, tajās rindās dos softfail. Ar DKIM parakstu DMARC tad tomēr iztur pārbaudi, bet tas ir pazīme, ka Jūsu SPF nav pilnīgs.

No pārskata līdz lēmumam

Esat gatavi stingrināt savu politiku (no none uz quarantine, pēc tam uz reject), ja:

• katrs Jums piederošs avots policy_evaluated rāda vismaz vienu pass;
• tā ir bijis jau pāris nedēļas, pie visiem lielajiem saņēmējiem;
• tas, kas joprojām neiztur pārbaudi, ir tikai pāradresēts e-pasts ar derīgu DKIM parakstu (tas tomēr iztur pārbaudi) vai skaidrs viltojums.

Ja neiztur pārbaudi liels Jūsu pašu avots, kā piemērā jaunumu vēstuļu pakalpojums ar 1250 ziņām, tad vēl ir par agru. Ar p=reject saņēmējs noraidītu šīs 1250 jaunumu vēstules.

Pārskatu padarīšana lasāmā veidā

Viens pārskats teksta redaktorā ir izlasāms. Divdesmit dienā nē. Ir trīs veidi:

• Pārskatu pakalpojums (to ir daudz, arī ar bezmaksas variantu). Jūs ievietojat to adresi laukā rua, un tie izveido grafikus un sarakstus. Ņemiet vērā: tādā gadījumā šim pakalpojumam dodat ieskatu par to, kuri serveri sūta e-pastu Jūsu vārdā, un pārskata adrese atrodas to domēnā (skatiet atļauju caur _report._dmarc nodarbībā 4.4). Izvēlieties pakalpojumu, kuram uzticaties un kas ievēro VDAR.
• Savs rīks: pastāv atvērtā pirmkoda programmas, kas pārskatus izgūst no pastkastes un ievieto tos pārskatā.
• Lasīšana pašu spēkiem, izmantojot XML skatītāju vai pārlūkprogrammu, retākai lietošanai.

Kļūdu pārskati (ruf, RFC 9991) ir citādi: par katru neveiksmīgu e-pastu, dažkārt ar paša e-pasta fragmentiem. Gandrīz neviens liels saņēmējs tos nesūta, tieši privātuma apsvērumu dēļ. Lai pareizi ieviestu DMARC, tie Jums nav vajadzīgi.

Praksē: tā tas izskatās

WebOké Jūs varat ievadīt pārskata adresi DMARC palīglīdzeklī DirectAdmin vai Mans WebOké (skatiet nodarbību 4.4), un paši izvēlaties pastkasti, kurā pārskati ienāks; atsevišķa adrese, piemēram, dmarc@, ar savu mapi, novērš to, ka parastā pasta plūsma to noslāpē. Lasīšanai izmantojiet pārskatu pakalpojumu vai programmu pēc izvēles. Tas darbojas vienādi pie jebkura pakalpojumu sniedzēja: pārskats ir standarta formātā.

Kopsavilkums

• Apkopojošais pārskats ir ikdienas XML fails (bieži saspiests), katram saņēmējam, kurā norādīts katra nosūtītāja IP ziņu skaits un rezultāti.
• auth_results uzrāda neapstrādātu SPF un DKIM rezultātu; policy_evaluated tikai to, kas izturēja pārbaudi salāgoti. Pass laukā auth_results var būt fail no DMARC viedokļa.
• Pāradresētu e-pastu atpazīstat pēc DKIM pass ar SPF fail; viltojumu pēc visa fail no nezināmas IP adreses.
• Stingrinat savu politiku tikai tad, kad visi Jūsu pašu avoti pāris nedēļas pēc kārtas iztur pārbaudi.
• Kļūdu pārskati (ruf) ir reti un nav nepieciešami.

Tests

Uzdevums

Uzdevums Z4.5: DMARC pārskata lasīšana. Atveriet piemēra failu dmarc-rapport-1.xml (apkopojošais pārskats par example.com, ar izdomātiem datiem). Atbildiet uz jautājumiem: kādu politiku saņēmējs atrada, cik ziņu kopā ir pārskatā, cik no tām neizturēja DMARC pārbaudi, kura rinda ir jaunumu vēstuļu pakalpojums un kas tur jādara, kura rinda ir pāradresēts e-pasts, kura rinda, visticamāk, ir viltojums, kas jāmaina SPF ierakstā saskaņā ar 6. rindu, kura rinda iztur pārbaudi tikai pateicoties DKIM pie pakalpojuma ar savu Return-Path, un vai domēns tagad var pāriet uz p=quarantine? Programma pārbaudīs Jūsu atbildes pēc fiksētas atslēgas un katram jautājumam paskaidros, kura pārskata rinda sniedz atbildi.

Lasiet arī

Šajos rakstos aprakstītie soļi attiecas uz WebOké paneļiem; pie citiem pakalpojumu sniedzējiem process ir līdzīgs.

• Kas ir DMARC? Skaidrojums vienkāršā valodā
• DirectAdmin rokasgrāmata 5.9: DMARC iestatīšana
• Bezmaksas DNS kurss 4.5: DMARC: ko saņēmējiem darīt ar viltus pastu
• RFC 9990 (DMARC Aggregate Reporting), ar pārskata piemēru B pielikumā; RFC 9991 (Failure Reporting)