SPF: ki küldhet
Az RFC 7208 egy megállapításból indul ki: a levelezési protokollban semmi sem akadályozza meg, hogy egy szerver bármilyen feladócímet bejelentsen. Az SPF lehetővé teszi a domain tulajdonosának, hogy a DNS-ben közzétegye a nevében küldésre jogosult szerverek listáját, a fogadó szervernek pedig azt, hogy ellenőrizze ezt a jogosultságot.
Két pontosítás mindent megváltoztat:
- Az SPF a borítékcímet (a szerverek közötti párbeszédben használt, úgynevezett „MAIL FROM” címet) és a szerver által bejelentett nevet ellenőrzi, nem azt a címet, amelyet a címzett a „Feladó” mezőben olvas.
- Az SPF az üzenetet utolsóként kézbesítő szervert ítéli meg. Ha egy üzenetet egy másik szerver továbbít, már nem az eredeti domain által engedélyezett szerver kézbesíti: az ellenőrzés sikertelen lehet, pedig az üzenet jogos.
Egy domain csak egyetlen SPF-rekordot tesz közzé. Ebben minden küldési forrásnak szerepelnie kell: levelezőrendszer, számlázó szoftver, hírlevélküldő eszköz, CRM, e-mailbe szkennelő fénymásoló.
DKIM: az üzenet alá van írva
Az RFC 6376 szerint a DKIM lehetővé teszi az aláíró domain tulajdonosának, hogy egy kriptográfiai aláírással felelősséget vállaljon egy üzenetért. A nyilvános kulcs a DNS-ben található. Az aláírás ellenőrzése igazolja, hogy az aláírt részek az aláírás óta nem változtak.
Az aláírás az üzenettel együtt utazik. Ezért jobban túléli az átjátszást vagy a továbbítást, mint az SPF, mindaddig, amíg a köztes szerver nem módosítja a tárgyat vagy a törzset. Egy levelezőlista, amely megjegyzést fűz az üzenet aljához, érvényteleníti.
Amit a DKIM ugyanezen RFC szerint nem tesz: nem titkosítja az üzenetet, a sikertelen ellenőrzés nem írja elő az elutasítást, és az aláíró domainnek nem kell megegyeznie a „Feladó” mezőben megjelenített domainnel. Pontosan ezt a rést tölti be a DMARC.
DMARC: az illeszkedés és a szabályzat
Az RFC 7489 a DMARC-ot olyan eszközként határozza meg, amellyel egy domain tulajdonosa domainszintű szabályzatot fogalmazhat meg. A mechanizmus az illeszkedésen alapul: a „Feladó” mezőben megjelenített cím domainjének meg kell felelnie az SPF vagy a DKIM által hitelesített domainnek. Ha egyik sem illeszkedik, a DMARC-ellenőrzés sikertelen.
A domain ekkor közzéteszi, mit kér:
- none: semmilyen intézkedést nem kér, csak megfigyel;
- quarantine: az üzenetet gyanúsként kell kezelni;
- reject: az üzenetet el kell utasítani.
A DMARC jelentéseket is előír: összesített jelentéseket, amelyek összefoglalják, mely szerverek küldtek a domain nevében és milyen eredménnyel, valamint hibajelentéseket, üzenetenként. Ezek teszik lehetővé, hogy felfedezzen egy elfelejtett eszközt, amely az Ön nevében küld, vagy valakit, aki visszaél a domainjével.
| Mechanizmus | Mit ellenőriz | Mit nem vizsgál |
|---|
| SPF | Az üzenetet kézbesítő szerver jogosult-e a borítékdomain nevében küldeni | A megjelenített címet, a tartalmat |
| DKIM | Az aláírt üzenet nem módosult; egy domain felelősséget vállal érte | A megjelenített címet, a tartalom tisztességét |
| DMARC | A megjelenített domain illeszkedik az SPF-hez vagy a DKIM-hez; szabályzat hiba esetén | A hasonló domaineket, a megjelenített nevet, a szöveget |
Megállítja-e a DMARC az adathalászatot?
A domainnel való visszaélés egy részét megállítja, az adathalászatot általában nem. Az RFC 7489 ezt kifejezetten kimondja: a DMARC nem foglalkozik a vizuálisan hasonló domainnevekkel, sem a megjelenített névvel való visszaéléssel, és a tartalom elemzése kívül esik a hatókörén. Nem törekszik a csalárd levelek összes problémájának megoldására.
A gyakorlatban a DMARC nem látja:
- a hasonmás domaint: a csaló tökéletesen hitelesíti saját domainjét, amely az Önéhez hasonlít;
- a hamisított megjelenített nevet: „Könyvelés” egy azzal semmilyen kapcsolatban nem álló címről;
- a kompromittált fiókot, amely helyesen ír alá, hiszen a valódi szerver küld;
- az Ön domainjéhez nem kapcsolódó üzenetet: egy fuvarozó hamis értesítése olyan domainről érkezik, amelynek semmi köze az Önéhez;
- a szabályzat nélküli domaint: ha az utánzott domain „none” szabályzatot tesz közzé, a címzett nem kap utasítást az elutasításra.
Ezek az esetek más elemzésekre tartoznak: a domainek hasonlósága, hírnév, tartalom, viselkedés. Lásd: Kéretlen levelek, adathalászat, kártevők és kompromittált fiók.
Továbbítás és levelezőlisták: ARC
A továbbítás gyakran érvényteleníti az SPF-et, az üzenetet módosító lista a DKIM-et, és a DMARC ilyenkor egy jogos üzeneten bukik el. Az RFC 8617-ben leírt ARC (kísérleti státuszú) lehetővé teszi, hogy minden közvetítő igazolja az általa megállapított hitelesítési eredményt. A végső szerver dönthet úgy, hogy ezt figyelembe veszi.
A saját domain védelme és a beérkező levelek szűrése
Ezt a két témát gyakran összekeverik.
- A küldő domain védelme: az SPF, a DKIM és a DMARC közzététele az Ön domainjére, hogy mások elutasíthassák a vele visszaélő üzeneteket. Ön teszi közzé; a címzettek alkalmazzák.
- A beérkező levelek szűrése: a többi domain rekordjainak ellenőrzése a kapott leveleken, majd az összes többi elemzés alkalmazása.
Fokozatos bevezetés
- Minden olyan forrás leltára, amely a domain nevében küld.
- Egyetlen SPF-rekord, amely engedélyezi őket; DKIM-aláírás minden olyan szolgáltatáshoz, amely képes aláírni.
- DMARC „none” szabályzattal, a jelentések fogadására szolgáló címmel.
- A jelentések olvasása több héten át; az elfelejtett források javítása.
- Átállás „quarantine”, majd „reject” szabályzatra, amikor már minden jogos küldés illeszkedik.
Példa, szemléltetésképpen. Egy iroda „none” szabályzattal teszi közzé a DMARC-ot, és elolvassa első jelentéseit. Három forrást fedez fel: levelezőrendszerét, amely megfelelően illeszkedik; számlázó szoftverét, amely DKIM-aláírás nélkül, az iroda domainjével küldi a számlákat; és egy ismeretlen külföldi szervert, amely több száz üzenetet küld a nevében. Kijavítja a számlázó szoftvert, megvár egy hibátlan jelentési ciklust, majd „quarantine” szabályzatra áll át: a DMARC-ot alkalmazó címzettek ettől kezdve gyanúsként kezelik az ismeretlen szerver üzeneteit.
Amikor levelezőrendszert vált, ezeket a rekordokat az MX módosítása előtt kell előkészíteni. A levelezés migrálása megszakítás nélkül útmutató ezt a pillanatot írja le; itt nem ismételjük meg.
Gyakori kérdések
Véd-e a „none” DMARC-szabályzat?
Nem. A jelentések révén megfigyelést tesz lehetővé. A védelem a „quarantine” vagy a „reject” szabályzattal kezdődik.
Miért bukik el egy jogos üzenet a DMARC-ellenőrzésen?
Leggyakrabban: továbbítás, levelezőlista, vagy egy olyan szolgáltatás miatt, amely az Ön nevében küld anélkül, hogy szerepelne az SPF-ben, vagy DKIM-aláírást használna.
Levelezőrendszerünk nem ír alá DKIM-mel: mi a teendő?
A küldések útjába helyezett átjáró aláírhat helyette. Lásd: A már meglévő levelezőrendszer védelme.
Hol olvasható ezeknek az ellenőrzéseknek az eredménye egy kapott üzeneten?
Az üzenet fejléceiben. A Klytic MTA esetében lásd: A szűrő egy döntésének olvasása és exportálása.
Hol helyezkedik el a Klytic
A Klytic MTA mindkét témát kezeli, bármely levelezőrendszer előtt:
- Essential és Advanced: SPF-, DKIM- és MX-ellenőrzés; DMARC-ellenőrzés, az ARC-nak köszönhetően a továbbított üzenetekre is; a kimenő levelek DKIM-aláírása, akkor is, ha levelezőrendszere ezt nem teszi meg.
- Advanced: DMARC-konzol, domainjei jelentéseivel, riasztásokkal és javítási javaslatokkal, a „reject” szabályzatra való fokozatos átálláshoz.
A DMARC csak egy réteg: a Klytic MTA ehhez hozzáadja a hasonmás domainek, a megjelenített név és a csalási forgatókönyvek felismerését, amelyet a Megszemélyesítés és CEO-csalás útmutató ír le.
Ha a Klytic Mailt használja, az SPF, a DKIM és a DMARC be van állítva a domainjére: ez a küldő domain védelme. A Klytic MTA Klytic Maillel vagy anélkül is megrendelhető.
Források
Megtekintve 2026 októberében.
- RFC 7208, SPF: a domain tulajdonosa közzéteszi azokat a gépeket, amelyek domainjét a „MAIL FROM” vagy a „HELO” azonosítóban használhatják, a fogadó pedig ellenőrzi ezt a jogosultságot. rfc-editor.org
- RFC 6376, DKIM: egy domain kriptográfiai aláírással vállal felelősséget egy üzenetért; nincs titkosítás, nincs előírt elutasítás, az aláíró domain eltérhet a megjelenített szerzőtől. rfc-editor.org
- RFC 7489, DMARC: a „From” domainjének illeszkedése az SPF-hez vagy a DKIM-hez, none, quarantine és reject szabályzatok, összesített és hibajelentések; a vizuálisan hasonló domainek, a megjelenített név és a tartalomelemzés kívül esik a hatókörén. rfc-editor.org
- RFC 9989 (2026. május), amely felváltja az RFC 7489-et: ugyanazok a szabályzatértékek és ugyanazok a kizárások (hasonló domainek, megjelenített név). rfc-editor.org
- RFC 8617, ARC (kísérleti): hitelesített továbbítási lánc; egy DMARC-fogadó elfogadhatja az érvényes ARC-lánc által hordozott értékeléseket. rfc-editor.org
- Klytic, Klytic MTA oldal: hitelesítési ellenőrzések, kimenő DKIM-aláírás és DMARC-konzol az Essential és az Advanced csomagban, opciók, telepítési módok, üzembe helyezés az MX-en keresztül. klytic.com
