SPF, DKIM ja DMARC lahti seletatud: turvaline tee p=reject’ini

Igaüks võib kirjutada teie domeeni e-kirja saatja (From) reale. SPF, DKIM ja DMARC võimaldavad vastuvõtval serveril kontrollida, kas kiri tuli tõesti teilt, ja ütlevad talle, mida teha, kui see nii ei olnud. Hoolikalt seadistatuna muudavad need täpselt teie domeeni nime kasutava võltsimise palju raskemaks. Kiirustades seadistatuna võivad need blokeerida teie enda arved.

Mida iga mehhanism teeb

SPF (Sender Policy Framework, RFC 7208) on DNS-i TXT-kirje, mis loetleb serverid, mis tohivad domeeni nimel kirju saata. Vastuvõtja võrdleb ühenduse loonud serveri IP-aadressi selle loendiga. SPF kontrollib ümbriku saatjat (identiteete MAIL FROM ja HELO), mitte From-aadressi, mida saaja näeb.

DKIM (DomainKeys Identified Mail, RFC 6376) lisab igale kirjale krüptograafilise allkirja. Silt d= nimetab allkirjastava domeeni ja s= selektori. Avalik võti avaldatakse DNS-is aadressil selector._domainkey.domain. Kehtiv allkiri näitab, et kirja allkirjastatud osad ei ole muutunud pärast seda, kui see domeen need allkirjastas.

DMARC seob mõlemad nähtava From-domeeniga. Uuendatud versioon avaldati 2026. aasta mais standardirajal (Standards Track) oleva dokumendina RFC 9989, mis asendab RFC 7489. DMARC-kirje sätestab teie poliitika ja palub vastuvõtjatel teile aruandeid saata.

Joondus on osa, mis kipub kahe silma vahele jääma

Kiri läbib DMARC-i, kui SPF või DKIM läbitakse ja autenditud domeen on joondatud From-domeeniga. Leebe joondus, mis on vaikimisi, aktsepteerib vastavust organisatsiooni domeeni tasemel, seega on mail.example.eu joondatud domeeniga example.eu. Range joondus (adkim=s või aspf=s) nõuab täpset vastavust.

Kõige sagedamini läheb see valesti kolmandate osapoolte saatjatega. Uudiskirjaplatvorm võib kasutada ümbriku domeenina näiteks bounces.platform.example. SPF läbitakse platvormi domeeni puhul, kuid see domeen ei ole joondatud domeeniga example.eu, seega ei anna see teie DMARC-tulemusele midagi.

Lahendus on lasta platvormil allkirjastada DKIM-iga, kasutades d=example.eu, või seadistada kohandatud tagastusaadress (return-path) mõnele teie enda alamdomeenile. RFC 9989 soovitab domeeniomanikel kasutada nii SPF-i kui ka DKIM-i. Nii saab üks neist tulemuse siiski kanda, kui teine nurjub, näiteks pärast edasisaatmist.

Kuidas kirjed välja näevad

Allpool olevad näited kasutavad dokumentatsiooni jaoks reserveeritud IP-aadressi ja kohatäitjaks olevat teenusepakkujat. Asendage need oma väärtustega.

example.eu.                    TXT  "v=spf1 include:spf.mail-provider.example ip4:203.0.113.25 ~all"
s2026._domainkey.example.eu.   TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."
_dmarc.example.eu.             TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.eu"

Ülaltoodud DMARC-kirje on seirerežiimis. See küsib koondaruandeid, kuid ei nõua meetmeid kirjade suhtes, mis kontrolli ei läbi. Koondaruanded, mis on nüüd kirjeldatud standardis RFC 9990, näitavad, millised serverid saadavad kirju teie domeeni nimel ja kas need läbivad kontrolli.

DKIM-võtmete puhul nõuab RFC 6376 pikaajaliste võtmete jaoks vähemalt 1024-bitiseid RSA-võtmeid. Google nõuab isiklikele Gmaili kontodele saadetavate kirjade puhul vähemalt 1024 bitti ja soovitab 2048 bitti, kui teie teenusepakkuja seda toetab.

Turvaline üleminek p=none’ilt p=reject’ile

1. Loetlege kõik saatjad. Arvestage oma e-posti platvormi, CRM-i, arveldus- ja palgasüsteeme, kasutajatuge, veebisaidi vorme ning seadmeid, näiteks skannereid, mis saadavad dokumente e-postiga.
2. Seadistage igaühe jaoks SPF ja DKIM. Paluge igal teenusel allkirjastada DKIM-iga teie enda domeeni all, kui see on võimalik.
3. Avaldage p=none koos rua-aadressiga. RFC 9989 kirjeldab seda tavapärase lähtepunktina, et saaksite leida saatjad, kes seadistamisel kahe silma vahele jäid.
4. Lugege aruandeid ja parandage lüngad. Andke sellele vähemalt mitu nädalat ja kauem, kui teil on igakuised või kvartaalsed postitused, näiteks palgateatised või aastaaruanded.
5. Minge üle p=quarantine’ile ja seejärel p=reject’ile. RFC 9989 kaotas vana sildi pct. Selle asendaja on testrežiim: t=y palub vastuvõtjatel rakendada poliitikat ühe astme võrra leebemalt, seega käsitletakse p=reject; t=y karantiinina.
6. Katke alamdomeenid ja pargitud domeenid. Silt sp määrab olemasolevate alamdomeenide poliitika ja uus silt np hõlmab alamdomeene, mida ei ole olemas.

Käsitlege t=y leevendusena, mitte garantiina. Nii RFC 7489 kui ka RFC 9989 käsivad vastuvõtjatel eirata silte, mida nad ei tunne. Vastuvõtja, kes pole uut spetsifikatsiooni veel kasutusele võtnud, võib seega rakendada teie avaldatud poliitikat täies ulatuses.

Sammu 6 puhul peaks domeen, mis kunagi kirju ei saada, seda selgelt välja ütlema. Avaldage SPF-kirje, mis ei volita kedagi, ja tagasilükkamise poliitika:

parked-example.eu.                              TXT  "v=spf1 -all"
_dmarc.parked-example.eu.                       TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.eu"
parked-example.eu._report._dmarc.example.eu.    TXT  "v=DMARC1"

Kolmas kirje on oluline, sest aruanded lähevad teisele domeenile. RFC 9990 nõuab, et vastuvõtjad kontrolliksid enne aruannete saatmist, kas sihtdomeen on nõustunud poliitikadomeeni aruandeid vastu võtma.

Suured postkastiteenuse pakkujad juba ootavad seda tööd. Alates 1. veebruarist 2024 on Google nõudnud masspostitajatelt (üle 5000 kirja päevas Gmaili) joondatud SPF-i, DKIM-i ja DMARC-i kasutamist. Poliitika p=none vastab sellele miinimumnõudele, kuid ei kaitse teie domeeni.

Levinud vead

Kaks SPF-kirjet

Domeen tohib avaldada ainult ühe SPF-kirje. Kui vastuvõtja leiab neid rohkem kui ühe, on SPF-i tulemus permerror, mitte läbimine. Uue teenuse lisamisel ühendage selle include olemasolevasse kirjesse, selle asemel et luua teine kirje.

Üle kümne DNS-päringu

RFC 7208 piirab SPF-i hindamisel DNS-päringuid põhjustavate terminite arvu kümnega: include, a, mx, ptr, exists ja modifikaator redirect. Arvesse lähevad ka teie include’ide sisse pesastatud include’id. Kui piir ületatakse, on tulemus permerror.

Terminid ip4, ip6 ja all arvesse ei lähe, seega aitab oma serverite loetlemine aadressi järgi. Eemaldage include’id teenuste jaoks, mida te enam ei kasuta. RFC soovitab ka piirata nn tühjad päringud (void lookups), mis ei tagasta vastust, kahega.

+all ja ?all

Mehhanism all sobib alati ja tulemuse määrab selle kvalifikaator. +all volitab seega iga serveri internetis, nii et ärge seda kunagi avaldage. ?all annab neutraalse tulemuse, mida RFC 7208 järgi tuleb käsitleda täpselt nagu SPF-tulemuse puudumist. Kasutage ~all (pehme nurjumine, softfail) või -all (nurjumine, fail).

Kumba neist? Esialgne DMARC-i spetsifikatsioon (RFC 7489, jaotis 6.7) märgib, et SPF-i nurjumise korral tagasilükkamine takistab vastuvõtjal DKIM-i hindamast. See võib kahjustada edasisaadetud kirju, mille puhul SPF nurjub, kuid DKIM-allkiri on endiselt kehtiv. Kui DMARC on jõustatud, laseb ~all lõpliku otsuse teha DMARC-il.

Edasisaatmise ja postiloendite eiramine

Edasisaadetud kiri saabub edasisaatja IP-aadressilt, mida teie SPF-kirjes pole. DKIM-allkiri säilib edasisaatmisel tavaliselt, kui kirja ei muudeta. Postiloendid, mis muudavad teemarida või lisavad jaluse, võivad selle aga katki teha. Seetõttu on p=reject’ile üleminekul usaldusväärne DKIM-allkirjastamine teie enda domeeni all olulisem kui SPF.

ptr-i kasutamine

RFC 7208 järgi ei tohiks mehhanismi ptr avaldada. See on aeglane, vähem usaldusväärne ja läheb siiski päringute piiri sisse.

Jõustamine aruandeid lugemata

Otse p=reject’ile hüppamine on lihtne viis blokeerida oma paroolilähtestused, arved või kasutajatoe vastused. Aruanded näitavad, milliseid saatjaid te unustasite. Lugege neid enne jõustamist ja jätkake lugemist ka pärast seda, sest lisandub uusi teenuseid.

Kust alustada

• Kontrollige meie e-posti turvalisuse kontrolliga, mida teie domeen praegu avaldab.
• Koostage või korrastage oma kirjed SPF- ja DMARC-generaatoriga.
• Pange kirja kõik süsteemid, mis saadavad kirju teie domeeni nimel. Seda loendit on vaja enne jõustamist.
• Avaldage kohe p=none koos aruannete aadressiga ja määrake kuupäev esimeste aruannete ülevaatamiseks.
• Lisage v=spf1 -all ja p=reject DMARC-kirje igale teile kuuluvale domeenile, mis kirju ei saada.

Kui soovite aruannete analüüsi ja jõustamisele ülemineku kellelegi üle anda, aitab meie hallatud turbe teenus mõlemaga.