DMARC ieviešana: no none līdz reject

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

Mācību mērķis: Pēc šīs nodarbības Jūs varēsiet izskaidrot, kā darbojas salāgošana (alignment), plānot DMARC ieviešanu pa posmiem no p=none līdz p=reject, izvēlēties pareizos tagus (rua, sp, np, t) un novērst zināmās kļūmes saistībā ar pāradresāciju un jaunumu vēstuļu sarakstiem.

Pamatjēdzieni: DMARC (RFC 9989), Author Domain (domēns laukā From), salāgošana (alignment), relaxed un strict (adkim, aspf), organizācijas domēns, DNS tree walk, p=none, p=quarantine, p=reject, rua, sp, np, t=y (testēšanas režīms), novecojuši tagi pct, rf, ri, jaunumu vēstuļu saraksti (mailing lists), From pārrakstīšana, ARC

Ko tieši pārbauda DMARC

DMARC katram ienākošajam e-pastam atbild uz vienu jautājumu: vai SPF vai DKIM ir veiksmīgs domēnam, kas atbilst From adresei? Domēnu From adresē standartā sauc par Author Domain. Ieraksta pamati aprakstīti DNS kursa 4.5. nodarbībā. 2026. gada maijā tika publicēts pārskatītais standarts: RFC 9989, ar RFC 9990 apkopoto pārskatu un RFC 9991 kļūdu pārskatu vajadzībām. Esošie ieraksti ar v=DMARC1 paliek derīgi bez izmaiņām.

Salāgošana praksē

"Atbilst" sauc par salāgošanu (alignment). Ir divi režīmi:

• relaxed (noklusējuma): domēniem ir viens un tas pats organizācijas domēns. nieuws.example.com un example.com ir salāgoti; example.com un example.net nav.
• strict (adkim=s vai aspf=s): domēniem jābūt precīzi vienādiem.

SPF gadījumā DMARC salīdzina Return-Path domēnu ar From domēnu. DKIM gadījumā derīga paraksta d= domēnu. Daži piemēri e-pastam ar From: info@example.com:

Tāpēc atstājiet adkim un aspf uz relaxed, ja vien Jums nav labs iemesls rīkoties citādi.

Kā saņēmējs zina, kas ir organizācijas domēns? Agrāk to noteica ar Public Suffix List, saraksts ar tādiem domēniem kā .nl, .co.uk un github.io. RFC 9989 to aizstāj ar DNS tree walk: saņēmējs meklē _dmarc ierakstus gan domēnam, gan tā augstākā līmeņa domēniem. Parastam lietotājam nekas nemainās; to pamanīsiet tikai tad, ja strādājat ar ierakstiem apakšdomēnos.

Ieviešana četros posmos

Mērķis ir p=reject: tad saņēmēji noraida e-pastus, kas izliekas esam no Jums, un tā ir labākā aizsardzība pret viltus rēķiniem un phishing uzbrukumiem Jūsu vārdā. Taču, ja uzreiz iestatāt reject, nepazīstot savus sūtītājus, Jūs drīz vien noraidīsiet savus pašu rēķinus. Tāpēc šī secība (šī kursa ieteicamā kārtība):

0. posms: sagatavošanās

• Izveidojiet visu savu sūtītāju uzskaiti (4.2. nodarbība).
• Pārliecinieties, ka katram sūtītājam ir salāgots SPF vai DKIM; ieteicams DKIM, jo tas saglabājas pēc pāradresācijas.
• Izveidojiet atsevišķu adresi pārskatiem, piemēram, dmarc@example.com, vai izmantojiet pārskatu pakalpojumu. Drīz vien saņemsiet vairākus pārskatus dienā.

1. posms: mērīšana ar p=none

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

p=none ar pašu e-pastu neko nedara. Saņēmēji piegādā visu kā parasti, bet katru dienu nosūta Jums apkopoto pārskatu (aggregate report) ar katru serveri, kas sūtījis e-pastu Jūsu domēna vārdā, un vai SPF, DKIM un DMARC bija veiksmīgi. Ar to Jūs izpildāt arī Gmail, Yahoo un Microsoft minimālo prasību lielapjoma sūtītājiem (5.3. nodarbība).

Atstājiet to tā vismaz divas līdz četras nedēļas, un ilgāk, ja Jums ir pakalpojumi, kas sūta pastu reti (ikgadēja atgādinājuma vēstule, ceturkšņa rēķins). Izlasiet pārskatus (4.5. nodarbība) un salabojiet katru pašu avotu, kas neiztur pārbaudi.

2. posms: p=quarantine

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

E-pasts, kas neiztur DMARC pārbaudi, saņēmējam nonāk mēstuļu mapē. Ja tomēr aizmirstat kādu avotu, tas e-pasts nav pazudis, bet to ir grūti atrast. Ja vēlaties rīkoties piesardzīgi, vispirms pievienojiet t=y (testēšanas režīms): saņēmēji tad piemēro par soli maigāku politiku (quarantine gadījumā tātad none), bet pārskatos redzēsiet, kas notiktu. Tas RFC 9989 aizstāj veco tagu pct=.

Vērojiet pārskatus vēl dažas nedēļas.

3. posms: p=reject

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

E-pasts, kas neiztur DMARC pārbaudi, tiek noraidīts. Sūtītājs saņem atlēciena paziņojumu (bounce), piemēram, Microsoft gadījumā ar kodu 5.7.509, bet Gmail gadījumā ar norādi uz DMARC politiku (6. modulis). Turpiniet sekot pārskatiem: jauni pakalpojumi parādās vienmēr.

Kad drīkst rīkoties ātrāk?

Ja visa Jūsu pasta plūsma iet caur vienu pakalpojumu sniedzēju, kurš Jūsu vietā nokārto SPF un DKIM, un neviens cits nesūta neko Jūsu domēna vārdā? Tad stingru politiku var ieviest uzreiz. Dažas hostinga kompānijas tāpēc pēc noklusējuma iestata p=reject. Ja pēc tam tomēr sākat izmantot jaunumu vēstuļu pakalpojumu vai grāmatvedības programmu, uz laiku atgrieziet to pie p=none ar pārskatu adresi, kamēr šis pakalpojums ir pienācīgi sakārtots.

Citi tagi

Pārskatu adrese citā domēnā (piemēram, pārskatu pakalpojumā) darbojas tikai tad, ja tas domēns dod atļauju ar ierakstu, piemēram, example.com._report._dmarc.rapportdienst.example. Pakalpojums parasti to nokārto pats (RFC 9990, 4. nodaļa).

Kļūmes

Jaunumu vēstuļu saraksti (mailing lists)

Klasisks jaunumu vēstuļu saraksts pāradresē Jūsu e-pastu visiem dalībniekiem no sava servera un bieži pievieno [lijst] tematam vai zemteksta rindu. Tad SPF neiztur pārbaudi (cits serveris), un DKIM arī neiztur pārbaudi (e-pasts izmainīts). Ar p=reject saņēmēji noraida Jūsu ziņu, kas nosūtīta sarakstam. Moderna saraksta programmatūra to risina, pārrakstot From adresi uz saraksta adresi ("Jānis via Biedri"), vai pārsūtot e-pastu bez izmaiņām. Ja izmantojat sarakstu, kas to nedara, Jūs to redzēsiet savos pārskatos.

Pāradresācija

Skatiet 3.3. nodarbību: SPF pārtrūkst, DKIM parasti saglabājas. Saņēmējs ar ARC var nolemt uzticēties zināmam pāradresētājam. Pārskatos to atpazīsiet kā e-pastu no nezināma servera ar DKIM pass un SPF fail; tas nav iemesls mīkstināt politiku.

Divi ieraksti vai drukas kļūda

Divi DMARC ieraksti uz _dmarc padara politiku nederīgu, tāpat kā drukas kļūda p= laukā (p=rejected nepastāv). Pārbaudiet pēc katras izmaiņas.

Praksē: kā tas izskatās panelī

WebOké hostinga pakotnē pēc noklusējuma ir iestatīts v=DMARC1;p=reject, bez pārskatu adreses. Tas ir droši, ja visa Jūsu pasta plūsma iet caur šiem serveriem. Ja sūtāt pastu arī caur citiem pakalpojumiem, iestatiet p=none ar rua adresi un izejiet cauri posmiem. DirectAdmin to izdarāt sadaļā DNS Administration pie _dmarc ieraksta ar zīmuļa ikonu (lauki Domain policy type un Aggregate Email (RUA)); Mans WebOké izmantojiet DMARC palīgu DNS cilnē. Pie citiem pakalpojumu sniedzējiem izveidojiet TXT ierakstu ar nosaukumu _dmarc un ierakstiet tekstu paši; rezultāts ir tāds pats.

Kopsavilkums

• DMARC ir veiksmīgs, ja SPF vai DKIM ir veiksmīgs domēnam, kas salāgots ar From domēnu; relaxed salāgošana pieņem apakšdomēnus.
• Ieviešana: uzskaite, p=none ar rua un pārskatu lasīšana, p=quarantine (iespējams, ar t=y), un tad p=reject.
• Izmantojiet np=reject neesošiem apakšdomēniem, tiklīdz galvenā politika ir stingra. pct, rf un ri ir novecojuši.
• Jaunumu vēstuļu saraksti un pāradresācija rada paredzamas kļūmes; DKIM un ARC daļēji tās kompensē.
• Tieši viens ieraksts uz _dmarc, bez drukas kļūdām.

Tests

Uzdevums

Uzdevums Z4.4: Jūsu domēna DMARC pārbaude un nākamā soļa izvēle. Ievadiet savu domēnu (vai internet.nl). Ievadiet DMARC ierakstu tā, kā to atradāt, p= vērtību, un vai tajā ir rua adrese. Pēc tam izvēlieties, kurš ieviešanas posms, Jūsuprāt, ir nākamais solis, un kāpēc. Programma pieprasa ierakstu reāllaikā, pārbauda sintaksi saskaņā ar RFC 9989 (viens ieraksts, derīgs p, zināmi tagi, novecojuši tagi kā brīdinājums) un novieto Jūsu atbildes blakus.

Lasiet tālāk

Šo rakstu soļi attiecas uz WebOké paneļiem; pie citiem pakalpojumu sniedzējiem darbība ir līdzīga.

• Bezmaksas DNS kurss 4.5: DMARC: ko saņēmējiem darīt ar viltus pastu
• DirectAdmin rokasgrāmata 5.9: DMARC iestatīšana
• Kas ir DMARC? Skaidrojums vienkāršā valodā
• DMARC ieraksta izveide DirectAdmin
• RFC 9989 (DMARC), jo īpaši 4.7. sadaļa (tagi) un C pielikums (izmaiņas kopš RFC 7489)