DMARC nedrīkst sākt ar “reject” — droša ieviešana sākas ar pārskatiem

Ja uzņēmuma domēna vārdā vēstules sūta arī rēķinu, jaunumu, CRM un atbalsta sistēmas, tūlītēja p=reject politika var skart likumīgu pastu. Google ieteiktā DMARC ieviešanas kārtība sākas ar p=none un ikdienas pārskatiem; tikai pēc novērošanas tā paredz karantīnu nelielai neatbilstošo vēstuļu daļai. Noraidīšanu atstājiet posmam, kad esat pārbaudījuši visas vajadzīgās sūtīšanas plūsmas.

Drošā secība ir sūtītāju uzskaite, SPF un DKIM sakārtošana, domēnu saskaņas pārbaude īstās vēstulēs un DMARC pārskatu izvērtēšana. Kalendārs palīdz ieplānot darbu, taču pāreju uz stingrāku politiku nosaka tas, vai pārskatos vēl redzamas neizskaidrotas likumīga pasta kļūdas. p=none ļauj tās atrast, pirms DMARC politika liek saņēmējam vēstules ievietot surogātpastā vai noraidīt.

Apziniet katru sistēmu, kas sūta domēna vārdā

Vienā sarakstā pierakstiet darbinieku pastu un visus ārējos pakalpojumus: rēķinu izsūtīšanu, e-veikala paziņojumus, jaunumu vēstules, CRM automatizāciju, klientu atbalstu un vietnes kontaktformas. Katram norādiet atbildīgo cilvēku, redzamo sūtītāja adresi, pakalpojuma nosaukumu un vēstuļu veidu. Tas palīdzēs pārskatā pamanītu avotu salīdzināt ar reālu uzņēmuma procesu, nevis pēc IP adreses vien minēt, kam tas pieder.

Atsevišķi atzīmējiet reti izmantotās plūsmas, piemēram, paroles atiestatīšanu vai sezonālus paziņojumus. Īsā novērošanas periodā tās var nesūtīt nevienu vēstuli, tāpēc pārskatu klusums vēl nenozīmē, ka tās ir pareizi iestatītas. Pirms politikas pastiprināšanas nosūtiet no katras šādas sistēmas izmēģinājuma vēstuli uz ārēju pastkasti.

Saņemtās vēstules galvenēs pierakstiet redzamo From domēnu, SPF pārbaudē izmantoto domēnu un DKIM paraksta domēnu. Ja pakalpojumu nevarat sasaistīt ar konkrētu uzņēmuma vajadzību, noskaidrojiet tā īpašnieku pirms DNS izmaiņām. Sūtītāju saraksts ir arī atskaites punkts turpmākām pārbaudēm, kad uzņēmums pievienos jaunu rēķinu vai mārketinga rīku.

Sakārtojiet SPF un DKIM un pārbaudiet domēnu saskaņu

SPF norāda, kuri serveri drīkst sūtīt domēna vārdā; DKIM ļauj saņēmējam pārbaudīt vēstules kriptogrāfisko parakstu. Cloudflare DNS norādes Google Workspace konfigurācijai paredz vienu SPF ierakstu: ja izmantojat arī citus sūtītājus, to norādītās include vērtības pievieno tam pašam ierakstam, nevis izveido vēl vienu ierakstu, kas sākas ar v=spf1. Google Workspace piemēru nedrīkst uzskatīt par pilnu konfigurāciju domēnam, no kura sūta arī citas sistēmas.

Katram pakalpojumam izmantojiet tieši tā norādīto SPF mehānismu un DKIM iestatīšanas kārtību. DKIM DNS ierakstam vajadzīgs pareizais selektors un atslēga; pēc publicēšanas vēl jāpārliecinās, ka pakalpojums vēstules tiešām paraksta. Tas, ka DNS zonā redzams TXT ieraksts, pats par sevi nepierāda veiksmīgu autentifikāciju saņemtā vēstulē.

DMARC pārbaudē svarīga ir domēnu saskaņa. Gmail sūtītāju prasības lielapjoma sūtītājiem paredz SPF, DKIM un DMARC; tieši sūtītā pastā redzamajam From domēnam jāsaskan ar SPF vai DKIM autentificēto domēnu. Tādēļ tehniski veiksmīgs pakalpojuma paša domēna DKIM paraksts var nepalīdzēt jūsu domēna DMARC pārbaudei. Ja tā notiek, meklējiet pakalpojuma iespēju autentificēt jūsu sūtītāja domēnu un pārbaudiet jaunu vēstuli pēc izmaiņām.

Publicējiet p=none un noskaidrojiet, ko rāda pārskati

Kad SPF un DKIM ir pārbaudīti, domēna DNS zonā izveidojiet TXT ierakstu ar nosaukumu _dmarc. Nosacīts saturs ir v=DMARC1; p=none; rua=mailto:[email protected]. Piemēra adreses vietā norādiet savu pārskatu pastkasti vai pārskatu apstrādes pakalpojuma piešķirto adresi un pārliecinieties, ka tā saņem pastu. Ieraksts jāievieto pie pakalpojumu sniedzēja, kas faktiski pārvalda domēna DNS.

p=none neprasa saņēmējam DMARC kļūdas dēļ vēstuli ievietot karantīnā vai noraidīt; rua norāda, kur sūtīt apkopotos pārskatus. Tas negarantē nonākšanu iesūtnē, jo saņēmējs var vērtēt vēstuli arī pēc citiem piegādes un surogātpasta filtrēšanas kritērijiem. Neapstrādāti apkopotie pārskati var būt grūti lasāmi, tādēļ lielākai pasta plūsmai noder rīks, kas tos apkopo pa avotiem un autentifikācijas rezultātiem.

Salīdziniet pārskatos redzamos avotus ar sūtītāju sarakstu un pārbaudiet kļūdas pie konkrētā pakalpojuma. Pazīstama rēķinu sistēma ar neveiksmīgu pārbaudi var norādīt uz trūkstošu SPF atļauju, neieslēgtu DKIM vai nesaskaņotu From domēnu; nepazīstams avots var būt domēna viltošanas mēģinājums. Pārskats viens pats ne vienmēr atklāj konkrēto lietotni, tāpēc secinājumu salīdziniet ar pakalpojumu iestatījumiem un nosūtītu izmēģinājuma vēstuli. Nepievienojiet SPF ierakstam katru pārskatā redzamo IP adresi bez sūtītāja identificēšanas.

Pastipriniet politiku pa nedēļām, neizlaižot pārbaudes

Šis ir orientējošs plāns domēnam ar vairākiem sūtītājiem. Ja kāda svarīga plūsma sūta reti vai pārskatos vēl ir neskaidras kļūdas, attiecīgo posmu pagariniet.

1. Pirmajā nedēļā pabeidziet sūtītāju sarakstu. Noskaidrojiet katra pakalpojuma SPF un DKIM prasības un atzīmējiet plūsmas, kurām būs vajadzīga atsevišķa izmēģinājuma vēstule.
2. Otrajā nedēļā sakārtojiet SPF un DKIM, pārbaudiet ārēji saņemtu vēstuļu galvenes un publicējiet p=none ar pārskatu adresi. Pārliecinieties, ka redzamais From domēns sakrīt ar vismaz vienu veiksmīgi autentificētu domēnu.
3. Nākamajā nedēļā regulāri salīdziniet pārskatus ar zināmajiem sūtītājiem. Salabojiet likumīgās plūsmas, kas neiztur DMARC, un atsevišķi izmēģiniet reti izmantotās sistēmas.
4. Kad likumīgajiem sūtītājiem vairs nav neizskaidrotu kļūdu, ieslēdziet p=quarantine ar nelielu pct vērtību. Tā nosaka, kādai neatbilstošo vēstuļu daļai piemēro karantīnas politiku; turpiniet vērot pārskatus un pārbaudiet, vai svarīgas vēstules nenonāk saņēmēju surogātpasta mapēs.
5. Palieliniet karantīnas tvērumu līdz pilnam apjomam. Uz p=reject pārejiet pēc tam, kad visas vajadzīgās plūsmas ir identificētas un pārbaudītas arī pie stingrākās politikas.

Ja pēc maiņas parādās likumīgs sūtītājs ar DMARC kļūdu, apturiet politikas pastiprināšanu un labojiet tā autentifikāciju. Jaunu pasta pakalpojumu turpmāk iekļaujiet sūtītāju sarakstā un pārbaudiet tā domēnu saskaņu pirms vēstuļu izsūtīšanas klientiem.

Lasiet arī:

• Rocket EVA ievieš bremzi MI aģentiem — darbību var apturēt pirms izpildes
• Airbnb ievieš MI meklēšanu — rezultātus precizē dinamiski filtri
• Clockify vai Toggl Track: zemāka cena sacenšas ar vieglāku ieviešanu