SPF: kam ir tiesības sūtīt
RFC 7208 sākas ar konstatējumu: nekas e-pasta protokolā neliedz serverim norādīt jebkuru sūtītāja adresi. SPF ļauj domēna īpašniekam DNS publicēt to serveru sarakstu, kam atļauts sūtīt tā vārdā, un saņēmējam serverim pārbaudīt šo atļauju.
Divas precizitātes maina visu:
- SPF pārbauda aploksnes adresi (to, ko izmanto serveru savstarpējā saziņā, t. s. „MAIL FROM”) un servera paziņoto nosaukumu, nevis adresi, ko saņēmējs redz laukā „No”.
- SPF vērtē pēdējo serveri, kas piegādājis vēstuli. Ja vēstuli pārsūta cits serveris, to vairs nepiegādā izcelsmes domēna atļauts serveris: pārbaude var neizdoties, lai gan vēstule ir leģitīma.
Domēns publicē tikai vienu SPF ierakstu. Tajā jābūt visiem sūtīšanas avotiem: e-pastam, rēķinu programmai, jaunumu vēstuļu rīkam, CRM, kopētājam, kas skenē uz e-pastu.
DKIM: vēstule ir parakstīta
Saskaņā ar RFC 6376 DKIM ļauj parakstītāja domēna īpašniekam uzņemties daļu atbildības par vēstuli ar kriptogrāfiska paraksta palīdzību. Publiskā atslēga atrodas DNS. Paraksta pārbaude apliecina, ka parakstītās daļas kopš parakstīšanas nav mainījušās.
Paraksts ceļo kopā ar vēstuli. Tāpēc tas labāk nekā SPF pārdzīvo starpniekserveri vai pārsūtīšanu, ja vien starpnieks nemaina tematu vai saturu. Adresātu saraksts, kas vēstules beigās pievieno piezīmi, parakstu sabojā.
Ko DKIM nedara, saskaņā ar to pašu RFC: tas nešifrē vēstuli, neveiksme neliek to noraidīt, un parakstītāja domēnam nav jābūt tam, kas redzams laukā „No”. Tieši šo robu aizpilda DMARC.
DMARC: saskaņotība un politika
RFC 7489 definē DMARC kā līdzekli, ar ko domēna īpašnieks var paust politiku domēna līmenī. Mehānisms balstās uz saskaņotību: laukā „No” redzamās adreses domēnam jāatbilst domēnam, ko apstiprinājis SPF vai DKIM. Ja neviens no tiem nav saskaņots, DMARC pārbaude neizdodas.
Tad domēns publicē, ko tas vēlas:
- none: nekāda darbība netiek prasīta, tikai novērošana;
- quarantine: apstrādāt vēstuli kā aizdomīgu;
- reject: noraidīt vēstuli.
DMARC paredz arī pārskatus: apkopotos pārskatus, kas rāda, kuri serveri sūtījuši domēna vārdā un ar kādu rezultātu, un neveiksmes pārskatus par katru vēstuli atsevišķi. Tieši tie ļauj atklāt aizmirstu rīku, kas sūta jūsu vārdā, vai kādu, kas uzdodas par jūsu domēnu.
| Mehānisms | Ko tas pārbauda | Uz ko tas neskatās |
|---|
| SPF | Serverim, kas piegādā vēstuli, ir atļauja aploksnes domēnam | Redzamo adresi, saturu |
| DKIM | Parakstītā vēstule nav mainīta; domēns uzņemas par to atbildību | Redzamo adresi, satura godīgumu |
| DMARC | Redzamais domēns ir saskaņots ar SPF vai DKIM; politika neveiksmes gadījumā | Līdzīgus domēnus, attēlojamo vārdu, tekstu |
Vai DMARC aptur pikšķerēšanu?
Tas aptur daļu domēna viltojumu, nevis pikšķerēšanu kopumā. RFC 7489 to saka tieši: DMARC neapstrādā vizuāli līdzīgus domēnu vārdus, ne attēlojamā vārda ļaunprātīgu izmantošanu, un satura analīze ir ārpus tā darbības jomas. Tas necenšas atrisināt visas krāpniecisku vēstuļu problēmas.
Praktiski DMARC neredz:
- līdzīgu domēnu: krāpnieks nevainojami autentificē pats savu domēnu, kas līdzinās jūsējam;
- viltotu attēlojamo vārdu: „Grāmatvedība”, kas raksta no nesaistītas adreses;
- kompromitētu kontu, kas paraksta pareizi, jo sūta īstais serveris;
- vēstuli, kas nav saistīta ar jūsu domēnu: viltots pārvadātāja paziņojums nāk no domēna, kam ar jūsējo nav nekāda sakara;
- domēnu bez politikas: ja atdarinātais domēns publicē „none”, saņēmējam nav norādījuma noraidīt.
Šie gadījumi prasa citas analīzes: domēnu līdzību, reputāciju, saturu, uzvedību. Skatiet Surogātpasts, pikšķerēšana, ļaunprogrammatūra un kompromitēts konts.
Pārsūtīšana un adresātu saraksti: ARC
Pārsūtīšana bieži sabojā SPF, saraksts, kas maina vēstuli, sabojā DKIM, un tad DMARC pārbaude neizdodas leģitīmai vēstulei. ARC, kas aprakstīts RFC 8617 (eksperimentāls statuss), ļauj katram starpniekam apliecināt konstatēto autentifikācijas rezultātu. Galīgais serveris var izvēlēties to ņemt vērā.
Aizsargāt savu domēnu, filtrēt ienākošo
Šīs divas tēmas bieži jauc.
- Aizsargāt domēnu, kas sūta: publicēt SPF, DKIM un DMARC savam domēnam, lai citi varētu noraidīt vēstules, kas to viltoti izmanto. Publicējat jūs; piemēro saņēmēji.
- Filtrēt ienākošo: pārbaudīt citu domēnu ierakstus jūsu saņemtajā pastā un pēc tam piemērot visas pārējās analīzes.
Pakāpeniska ieviešana
- Visu domēna vārdā sūtošo avotu inventarizācija.
- Viens SPF ieraksts, kas tos atļauj; DKIM paraksts katram pakalpojumam, kas spēj parakstīt.
- DMARC režīmā „none” ar adresi pārskatu saņemšanai.
- Pārskatu lasīšana vairākas nedēļas; aizmirsto avotu labošana.
- Pāreja uz „quarantine”, pēc tam uz „reject”, kad visi leģitīmie sūtījumi ir saskaņoti.
Piemērs ilustrācijai. Birojs publicē DMARC režīmā „none” un lasa pirmos pārskatus. Tajos tas atklāj trīs avotus: savu e-pastu, kas ir pareizi saskaņots; rēķinu programmu, kas sūta rēķinus ar biroja domēnu bez DKIM paraksta; un nezināmu serveri ārzemēs, kas tā vārdā sūta simtiem vēstuļu. Birojs izlabo rēķinu programmu, sagaida tīru pārskatu ciklu un pāriet uz „quarantine”: saņēmēji, kas piemēro DMARC, turpmāk nezināmā servera vēstules apstrādā kā aizdomīgas.
Mainot e-pasta sistēmu, šie ieraksti jāsagatavo pirms MX maiņas. Rokasgrāmatā e-pasta migrēšana bez pārtraukuma šis brīdis ir aprakstīts; šeit tas netiek atkārtots.
Biežāk uzdotie jautājumi
Vai DMARC politika „none” aizsargā?
Nē. Tā ļauj novērot, izmantojot pārskatus. Aizsardzība sākas ar „quarantine” vai „reject”.
Kāpēc leģitīmai vēstulei neizdodas DMARC pārbaude?
Visbiežāk: pārsūtīšana, adresātu saraksts vai pakalpojums, kas sūta jūsu vārdā, nebūdams norādīts SPF un neparakstot ar DKIM.
Mūsu e-pasta sistēma neparaksta ar DKIM: ko darīt?
Vārteja, kas novietota sūtījumu ceļā, var parakstīt tās vietā. Skatiet Kā aizsargāt jau esošo e-pastu.
Kur saņemtai vēstulei var redzēt šo pārbaužu rezultātu?
Vēstules galvenēs. Klytic MTA gadījumā skatiet Kā izlasīt un eksportēt filtra lēmumu.
Kur ir Klytic
Klytic MTA risina abas tēmas, darbojoties pirms jebkuras e-pasta sistēmas:
- Essential un Advanced: SPF, DKIM un MX pārbaude; DMARC pārbaude, arī pārsūtītām vēstulēm, pateicoties ARC; izejošo sūtījumu DKIM paraksts, pat ja jūsu e-pasta sistēma to nedara.
- Advanced: DMARC konsole ar jūsu domēnu pārskatiem, brīdinājumiem un labošanas ieteikumiem, lai vadītu pakāpenisku pāreju uz „reject”.
DMARC ir tikai viens slānis: Klytic MTA pievieno līdzīgu domēnu, attēlojamā vārda un krāpšanas scenāriju atklāšanu, kas aprakstīta rakstā Uzdošanās par citu personu un vadītāja vārdā veikta krāpšana.
Ja izmantojat Klytic Mail, SPF, DKIM un DMARC ir iestatīti jūsu domēnam: tā ir sūtošā domēna aizsardzība. Klytic MTA savukārt var pasūtīt gan kopā ar Klytic Mail, gan bez tā.
Avoti
Skatīti 2026. gada oktobrī.
- RFC 7208, SPF: domēna īpašnieks publicē resursdatorus, kam atļauts izmantot tā domēnu identitātē „MAIL FROM” vai „HELO”, un saņēmējs pārbauda šo atļauju. rfc-editor.org
- RFC 6376, DKIM: domēns uzņemas atbildību par vēstuli ar kriptogrāfisku parakstu; nav šifrēšanas, nav obligātas noraidīšanas, parakstītāja domēns var atšķirties no redzamā autora. rfc-editor.org
- RFC 7489, DMARC: lauka „From” domēna saskaņotība ar SPF vai DKIM, politikas none, quarantine un reject, apkopotie un neveiksmes pārskati; vizuāli līdzīgi domēni, attēlojamais vārds un satura analīze ir ārpus darbības jomas. rfc-editor.org
- RFC 9989 (2026. gada maijs), kas aizstāj RFC 7489: tās pašas politikas vērtības un tie paši izņēmumi (līdzīgi domēni, attēlojamais vārds). rfc-editor.org
- RFC 8617, ARC (eksperimentāls): autentificēta pārsūtīšanas ķēde; DMARC saņēmējs var pieņemt novērtējumus, ko nes derīga ARC ķēde. rfc-editor.org
- Klytic, lapa Klytic MTA: autentifikācijas pārbaudes, izejošo sūtījumu DKIM paraksts un DMARC konsole piedāvājumos Essential un Advanced, papildiespējas, izvietošanas veidi, ieviešana ar MX. klytic.com
