A DMARC beállítás ma már nem csak nagyvállalati extra: minden olyan cégnek érdemes foglalkoznia vele, amely saját domainről küld e-maileket. Ha például az ön cége a cegnev.hu domainről levelezik, a DMARC segít megakadályozni, hogy csalók ugyanezzel a domainnel visszaélve küldjenek megtévesztő üzeneteket ügyfeleknek, partnereknek vagy akár munkatársaknak.
A DMARC az e-mail hitelesítés egyik fontos eleme. Nem önmagában működik, hanem az SPF rekord és a DKIM beállítás eredményeire épít. Röviden: az SPF azt mondja meg, mely szerverek küldhetnek levelet az adott domain nevében, a DKIM kriptográfiai aláírással igazolja, hogy az üzenetet nem módosították útközben, a DMARC pedig szabályt ad a fogadó levelezőszervereknek arra, mit tegyenek a gyanús levelekkel.
Miért fontos a DMARC a céges e-mail védelemben?
Az adathalász támadások gyakran arra épülnek, hogy a feladó cím megbízhatónak tűnik. Egy támadó például küldhet olyan e-mailt, amely látszólag a pénzügyi osztálytól, az ügyvezetőtől vagy egy ismert beszállítótól érkezik. Ha a domain nincs megfelelően védve, a címzett levelezőrendszere nehezebben dönti el, hogy valódi vagy hamis üzenetről van szó.
A DMARC ebben ad plusz védelmet. Beállítható vele, hogy a fogadó rendszerek csak megfigyeljék a problémás leveleket, különítsék el őket spamként, vagy utasítsák el teljesen. Ez különösen fontos, ha a cég weboldala, webshopja, számlázórendszere, hírlevélküldője és munkatársai is ugyanarról a domainről kommunikálnak.
Az alapok: SPF rekord és DKIM beállítás ellenőrzése
DMARC előtt érdemes rendbe tenni az SPF-et és a DKIM-et, különben a szabály túl sok jogos levelet is érinthet. Az SPF rekord egy DNS TXT rekord, amelyben felsorolható, mely szolgáltatók küldhetnek levelet a domain nevében. Ilyen lehet például a tárhelyszolgáltató levelezőszervere, a Google Workspace, a Microsoft 365 vagy egy hírlevélküldő rendszer.
Egy leegyszerűsített SPF példa így nézhet ki:
v=spf1 include:_spf.example-szolgaltato.hu -all
A DKIM beállítás szintén DNS rekordot igényel. Ilyenkor a küldő rendszer egy privát kulccsal aláírja a levelet, a fogadó fél pedig a DNS-ben elérhető publikus kulccsal ellenőrzi azt. A DKIM rekord formája szolgáltatónként eltér, ezért ezt mindig az adott levelező- vagy hírlevélküldő rendszer adminfelületén megadott érték alapján kell felvenni.
Hogyan néz ki egy DMARC rekord?
A DMARC szintén DNS TXT rekordként kerül beállításra. A rekord neve jellemzően:
_dmarc.cegnev.hu
Egy óvatos, induló DMARC beállítás például így nézhet ki:
v=DMARC1; p=none; rua=mailto:[email protected]
Ebben a p=none azt jelenti, hogy a fogadó szerverek egyelőre ne tiltsanak vagy karanténozzanak semmit, csak küldjenek riportot. A rua mezőben megadott címre összesített jelentések érkezhetnek arról, hogy milyen rendszerek küldenek levelet a domain nevében, és ezek megfelelnek-e az SPF/DKIM ellenőrzéseknek.
Fontos: a DMARC riportok gépi feldolgozásra alkalmas XML formátumban érkezhetnek, ezért nagyobb forgalmú céges levelezésnél érdemes erre külön postafiókot vagy riportfeldolgozó eszközt használni.
Javasolt bevezetési lépések
- Térképezze fel a küldő rendszereket: céges levelezés, weboldal űrlapjai, webshop, számlázó, CRM, hírlevélküldő, helpdesk rendszer.
- Állítsa be vagy javítsa az SPF rekordot: csak azok a szolgáltatók szerepeljenek benne, amelyek valóban küldenek levelet a domain nevében.
- Kapcsolja be a DKIM aláírást: lehetőleg minden fontos küldő rendszernél, nem csak a fő levelezésnél.
- Indítson DMARC-ot megfigyeléssel: kezdésnek célszerű a
p=nonehasználata, hogy kockázat nélkül láthatóvá váljanak a hibák. - Elemezze a riportokat: derítse ki, van-e jogos, de rosszul hitelesített küldő rendszer.
- Szigorítson fokozatosan: ha minden jogos küldés rendben van, jöhet a
p=quarantine, majd később ap=reject.
Mit jelentenek a DMARC szabályok?
A DMARC három fő házirendet használ. A p=none csak megfigyel, ez a biztonságos kezdő lépés. A p=quarantine azt kéri a fogadó levelezőrendszerektől, hogy a nem megfelelő leveleket kezeljék gyanúsként, például tegyék spam mappába. A p=reject a legszigorúbb: a hibásan hitelesített leveleket a fogadó szerver elutasíthatja.
Érdemes óvatosan haladni. Ha egy számlázóprogram vagy weboldali űrlap nincs megfelelően beállítva, egy túl korán bekapcsolt reject szabály miatt jogos levelek sem érhetnek célba. Ezért a DMARC beállítás nem csak egy DNS rekord felvétele, hanem rövid audit és tesztelés is.
Gyakori hibák DMARC beállításkor
Az egyik gyakori probléma, hogy a cégnek több küldő szolgáltatója van, de az SPF-ben csak egy szerepel. Ilyenkor például a hírlevelek vagy automatikus webshop e-mailek elbukhatnak az ellenőrzésen. Szintén tipikus hiba, hogy a DKIM nincs bekapcsolva minden rendszerben, vagy a DNS-be hibásan kerül be a szolgáltató által megadott kulcs.
Figyelni kell az úgynevezett domain-illeszkedésre is. A DMARC nem pusztán azt nézi, hogy az SPF vagy DKIM technikailag sikeres-e, hanem azt is, hogy az ellenőrzött domain összhangban van-e a látható feladó domainnel. Ezért fordulhat elő, hogy egy levél látszólag átmegy SPF-en, DMARC szempontból mégsem megfelelő.
Mit nyer vele egy vállalkozás?
A helyes DMARC beállítás erősíti az e-mail biztonság szintjét, csökkenti a domainnel való visszaélés esélyét, és támogatja az adathalászat elleni védelem mindennapi működését. Emellett átláthatóbbá teszi, honnan mennek ki céges levelek, ami üzemeltetési szempontból is hasznos: hamarabb kiderülnek az elfelejtett, rosszul konfigurált vagy felesleges küldő rendszerek.
Ha saját domainről levelezik, a DMARC-ot érdemes mielőbb bevezetni, de nem kapkodva. Először legyen rendben az SPF és a DKIM, majd induljon megfigyeléssel a DMARC. A fokozatos szigorítás biztonságosabb, és kisebb eséllyel okoz kézbesítési problémát a napi üzleti kommunikációban.


