DMARC (Domain-based Message Authentication, Reporting and Conformance)
Az SPF és a DKIM önmagában csak azt ellenőrzi, hogy egy levél valamilyen szervertől, valamilyen aláírással jött. Azt nem, hogy ez a szerver és aláírás köze van-e ahhoz a címhez, amelyet a címzett a „Feladó” mezőben lát. Ezt a rést zárja be a DMARC.
A lényeg: az egyezés (alignment)
Egy levél akkor megy át a DMARC-on, ha az SPF vagy a DKIM közül legalább az egyik sikeres, és az ellenőrzött domain egyezik a látható feladó domainjével. Ha egy csaló a bankod.hu nevével küld levelet a saját szerveréről, saját domainnel aláírva, az SPF és a DKIM akár „pass” is lehet, csak éppen nem a bankod.hu-ra. A DMARC ezt kiszűri.
Hogyan néz ki a rekord?
| Címke | Jelentés |
|---|---|
p=none | csak figyel, nem avatkozik be; a jelentések megérkeznek |
p=quarantine | a nem egyező levelek a spam mappába kerülnek |
p=reject | a nem egyező leveleket a fogadó szerver visszautasítja |
rua= | ide jönnek a napi összesítő jelentések (XML) |
pct= | a szabályzat a levelek hány százalékára vonatkozzon |
sp= | külön szabályzat az aldomainekre |
Bevezetés lépésről lépésre
A DMARC-ot nem érdemes egyből szigorú szabályzattal indítani, mert ha egy legitim küldő (számlázó, webshop, CRM) nincs rendesen beállítva, a saját leveleid tűnnek el. A biztonságos menet:
- Figyelés (2–4 hét):
p=noneés egyruacím. A jelentésekből kiderül, mely szolgáltatások küldenek a domained nevében. - Javítás: minden legitim küldőnél be kell állítani a saját domaines DKIM-et, és fel kell venni az SPF-be.
- Karantén, részben:
p=quarantine; pct=25, majd fokozatosan 100-ig. - Elutasítás:
p=reject, ha a jelentések hetekig tiszták.
A nyers XML-jelentéseket nehéz olvasni. Érdemes egy feldolgozó szolgáltatást használni; ha a domain DNS-e a Cloudflare-nél van, annak beépített DMARC-kezelője grafikusan mutatja, ki küld a nevedben, és melyik forrás bukik el.
Mennyibe kerül, ha nincs?
Nem a DMARC hiánya kerül sokba, hanem amit lehetővé tesz. Szemléltető számpélda: tegyük fel, valaki a cégneveddel hamis „díjbekérő” leveleket küld a partnereidnek. Ha csak egyetlen ügyfél fizet ki egy 380 000 Ft-os hamis számlát, a kár többszöröse egy rendes DMARC-bevezetés munkadíjának, nem beszélve a bizalomvesztésről. A p=reject szabályzattal az ilyen levelek nagy része meg sem érkezik a nagy postafiók-szolgáltatókhoz.
Gyakori hibák
- Örökre p=none. A figyelő mód csak az első lépés. Ha évekig ott marad, a domained ugyanúgy hamisítható, mintha nem is lenne rekord.
- Elfelejtett aldomainek. Ha a
hirlevel.cegem.hualdomainről küldesz, nézd meg, mit ír elő rá azsp=címke. - Továbbított levelek. Átirányításnál az SPF elbukik, ezért a DKIM-nek működnie kell; e nélkül a továbbított leveleket is megfogja a szigorú szabályzat.
- Két DMARC-rekord. Domainenként csak egy lehet; kettő esetén a fogadók egyiket sem veszik figyelembe.
Ha a DMARC már quarantine vagy reject állapotban van, a domain jogosulttá válhat a BIMI-re is. A teljes kép pedig az e-mail kézbesíthetőség oldalon áll össze.
Mit árul el egy DMARC-jelentés?
Az összesítő jelentés nem a levelek tartalmát mutatja, hanem a forrásukat: melyik IP-címről, hány levél ment a domained nevében, és ezek közül mennyi ment át az SPF- és a DKIM-ellenőrzésen. Az első hetekben szinte mindig kiderül valami meglepő, például egy régi számlázó, egy elfelejtett webshop-bővítmény vagy egy foglalási rendszer, amely évek óta hitelesítés nélkül küld. Ezek nem támadások, hanem a saját leveleid, és a szigorítás előtt mindet rendbe kell tenni.
A jelentésekben megjelenő ismeretlen, külföldi IP-címek viszont gyakran valódi hamisítási kísérletek. Ezek láttán dől el általában, hogy a figyelő mód után érdemes továbblépni.