SPF, DKIM és DMARC: védett-e e-mail-domainje a hamisítás ellen?

Miért működik még mindig az e-mail-hamisítás

Az e-maileket továbbító protokollt (SMTP) úgy tervezték, hogy nem ellenőrzi, ki a valódi feladó. Bárki küldhet levelet az Ön címével a Feladó mezőben, a világ bármely szerveréről. Ezért működnek még mindig olyan jól a hamis számlás csalások, a módosított bankszámlaszámot tartalmazó fizetési kérések és a vezérigazgató vagy egy beszállító nevében küldött adathalász levelek.

Ezt a rést három DNS-rekord zárja be. Az SPF meghatározza, mely szerverek küldhetnek levelet a domain nevében, a DKIM minden levelet kriptográfiai aláírással lát el, a DMARC pedig megmondja a fogadóknak, mit tegyenek az ellenőrzésen elbukó levelekkel, és jelentéseket küld erről Önnek. Egyik sem elég önmagában: valódi védelem csak akkor jön létre, ha mindhárom együtt működik, és a DMARC érvényesítő szabályt használ.

A fenti eszköz kiolvassa ezeket a rekordokat a nyilvános DNS-ből, és mindegyiknél megmutatja, rendben van-e, valamint melyik rekordot érdemes következőként közzétenni.

SPF rekord: ki küldhet az Ön nevében

Az SPF (RFC 7208) egy TXT rekord a domain gyökerén, például v=spf1 include:spf.protection.outlook.com -all. A fogadó szerver ellenőrzi, hogy a küldő IP-címe szerepel-e a listán. A legtöbb problémát három szabály okozza:

• Pontosan egy rekord. Két v=spf1 kezdetű rekord nem adódik össze, hanem tartós hibát (permerror) okoz, és az SPF minden levélnél sikertelen. Új szolgáltatás bevezetésekor a meglévő rekordot bővítse, ne hozzon létre másodikat.
• Legfeljebb 10 DNS-lekérdezés. Minden include, a, mx, exists és redirect, a beemelt rekordokban lévők is, beleszámít a 10-es korlátba. Néhány hírlevél- és CRM-szolgáltatás gyorsan túllépi. Az eszköz az include elemeket követve becsüli meg a számot.
• Értelmes lezárás. A -all (a nem felsorolt küldők elutasítása) és a ~all (gyanúsként jelölés) DMARC mellett egyaránt megfelelő. A ?all nem véd, a +all pedig az egész internetnek megengedi, hogy az Ön nevében küldjön.

Az SPF-nek van egy gyengesége: a technikai borítékfeladót ellenőrzi, nem a címzett által látott Feladó címet, és továbbításkor nem működik. Ezért van szükség DKIM-re és DMARC-ra.

DKIM: aláírás, amely túléli a továbbítást

A DKIM (RFC 6376) esetén a küldő szerver minden levelet privát kulccsal ír alá, a fogadó pedig a DNS-ben a <szelektor>._domainkey.cegnev.hu néven közzétett nyilvános kulccsal ellenőrzi az aláírást. Az aláírás a legtöbb továbbítást is túléli, ezért a DKIM általában megbízhatóbb alapja a DMARC-nak.

A szelektor a szolgáltató által választott tetszőleges név. A Microsoft 365 a selector1 és selector2 nevet használja, a Microsoftra mutató CNAME rekordként. A Google Workspace alapértelmezett szelektora a google. A hírlevél- és CRM-platformoknak saját szelektoruk van. Mivel a szelektorok nem listázhatók a DNS-ből, egy ellenőrző eszköz csak a gyakori neveket tudja kipróbálni. Ha nem talál semmit, nézze meg egy elküldött levél DKIM-Signature fejlécét: az s= címke az Ön szelektora, amelyet megadhat az eszközben.

Ahol a szolgáltató engedi, használjon 2048 bites RSA kulcsot. A Google a küldőknek szóló irányelveiben ezt javasolja, a Microsoft 365-ben pedig a következő kulcscserénél válthat 1024-ről 2048 bitre.

DMARC ellenőrzés: a szabály, amely mindent összeköt

A DMARC egy TXT rekord a _dmarc.cegnev.hu néven. Egy levél akkor megy át a DMARC-ellenőrzésen, ha az SPF vagy a DKIM sikeres, és az általuk ellenőrzött domain egyezik (igazított) a látható Feladó cím domainjével. A rekord azt is meghatározza, mi történjen az elbukó levelekkel:

Az rua címke az összesítő jelentések címét adja meg. Ezek XML-fájlok, amelyekben a fogadók felsorolják, mely szerverek küldtek levelet az Ön nevében, és átmentek-e az ellenőrzésen. Nélkülük vakon dolgozik, ezért mindig p=none szabállyal és rua címmel kezdjen, például: v=DMARC1; p=none; rua=mailto:dmarc-reports@cegnev.hu. Egy DMARC-jelentésszolgáltatás olvashatóvá teszi az XML-t.

2026 májusában az IETF közzétette az RFC 9989-et, amely felváltja az eredeti DMARC-specifikációt, az RFC 7489-et. A meglévő v=DMARC1 rekordok továbbra is működnek. A leglátványosabb változás, hogy a pct címkét megszüntették, helyette a t=y tesztcímke szolgál, és az új np címke a nem létező aldomainekre vonatkozó szabályt adja meg.

Mit követel a Gmail és a Yahoo

A Gmail 2024 februárja óta minden küldőtől SPF-et vagy DKIM-et követel meg. Aki naponta több mint 5000 levelet küld Gmail-fiókokra, annak SPF és DKIM, DMARC rekord (a szabály lehet none), az SPF-fel vagy DKIM-mel igazított Feladó domain, marketinglevelekhez egykattintásos leiratkozás és 0,3% alatti spamarány szükséges. A Yahoo a tömeges küldőkre gyakorlatilag ugyanezeket a szabályokat alkalmazza. Ha kevesebbet küld, ezek a szabályok akkor is mutatják az irányt: a hitelesítés nélküli levelek egyre gyakrabban kerülnek a spambe, vagy a fogadó elutasítja őket.

Gyakori hibák

• Elfelejtett küldők. Az ERP számlát küld, a webáruház rendelés-visszaigazolást, az ügyfélszolgálati rendszer jegyértesítőt, és egyik sem szerepel az SPF-ben, és nem ír alá DKIM-mel. A DMARC-jelentésekben azonnal megjelennek, amint elkezdi olvasni őket.
• Évekig p=none. A megfigyelés egy szakasz, nem védelem. A quarantine és reject szabályra való váltást dátumokkal tervezze meg.
• Gyenge aldomain-szabály. A p=reject melletti sp=none lehetővé teszi, hogy a támadók kitalált aldomainekről küldjenek.
• Védtelen parkoltatott domainek. A levelet nem küldő domaineknek v=spf1 -all és v=DMARC1; p=reject rekord kell, különben ideálisak a hamisításhoz. Ez a cégnévváltás után megmaradt régi domainekre is érvényes.
• Két SPF rekord szolgáltatóváltás után, illetve a lekérdezési korlátot túllépő SPF rekordok.

Biztonságos út a p=reject szabályig

1. Gyűjtse össze az összes szolgáltatást, amely az Ön nevében levelet küld.
2. Tegyen közzé egyetlen SPF rekordot, és kapcsolja be a DKIM-et a fő levelezőrendszerben és minden szolgáltatásnál.
3. Tegye közzé a DMARC-ot p=none szabállyal és rua címmel, és két-négy hétig olvassa a jelentéseket.
4. Javítsa ki a nem igazított küldőket, majd váltson p=quarantine szabályra.
5. Ha a jelentések tiszták maradnak, váltson p=reject szabályra, és továbbra is kövesse őket.

A domain hamisítás elleni védelme észszerű része azoknak a kiberkockázat-kezelési intézkedéseknek, amelyeket a NIS2 előír. Hogy az irányelv vonatkozik-e Önre, a NIS2 kiberbiztonsági törvény útmutatóban ellenőrizheti, védekezőképessége átfogóbb felméréséhez pedig a kibertámadásra való felkészültség felmérését ajánljuk.

A Humanfrog beállítja és üzemelteti a Microsoft 365-öt és az e-mail-biztonságot, beleértve az SPF-et, a DKIM-et, a DMARC-jelentéseket és a fokozatos átállást a p=reject szabályra levélvesztés nélkül. Ha eredményét szakértővel szeretné átnézni, írjon nekünk.