DMARC -- E-mail hitelesítés

DMARC szabályzat: Teljes védelem a levélhamisítás ellen

A DMARC (Domain-based Message Authentication, Reporting & Conformance) összekapcsolja az SPF-et és a DKIM-et, és utasításokat ad a fogadó szervereknek a nem hitelesített levelek kezeléséhez. Megfelelő beállítással megvédheted a domainedet a levélhamisítástól, és jelentősen javíthatod az e-mail kézbesíthetőséget.

domain védelem

Mi az a DMARC?

A DMARC (Domain-based Message Authentication, Reporting & Conformance) egy e-mail hitelesítési protokoll, amely az SPF (Sender Policy Framework) és a DKIM (DomainKeys Identified Mail) technológiákra épül. Míg az SPF meghatározza, mely szerverek küldhetnek levelet a domain nevében, a DKIM pedig kriptográfiai aláírással igazolja, hogy a levél tartalma nem változott az út során -- a DMARC összeköti ezt a két rendszert, és egy döntési szabályt (policy) ad a fogadó szervernek arra az esetre, ha a hitelesítés sikertelen.

A DMARC működésének kulcsa az alignment (igazítás) fogalma. Nem elég, hogy az SPF vagy a DKIM önmagában átmegy: a DMARC megköveteli, hogy a hitelesítés eredménye összhangban legyen a levél From: fejlécében szereplő domain névvel. Ez azt jelenti, hogy ha valaki meghamisítja a feladó címedet, de az SPF az ő szerverére mutat -- a DMARC ezt kiszűri, mert nincs alignment.

Miért fontos ez? 2024 februárjától a Google és a Yahoo megköveteli a DMARC rekordot minden olyan domaintől, amely napi 5000-nél több levelet küld. De a kisebb küldők számára is kritikus: a DMARC nélküli domainekről érkező levelek nagyobb eséllyel kerülnek spam mappába, és a domain reputáció is sérül, ha valaki visszaél az e-mail címeddel (phishing, spoofing).

A DMARC három pillére:

  • Hitelesítés: SPF és DKIM ellenőrzés a fogadó szerveren
  • Alignment: A From: fejléc domainjének egyezése az SPF/DKIM domainnel
  • Szabályzat (policy): Utasítás a fogadó szervernek, hogy mit tegyen sikertelen hitelesítés esetén

A DMARC három szintje

A DMARC szabályzat (p= paraméter) háromféle utasítást adhat a fogadó szervernek. Fontos, hogy fokozatosan haladj a legenyhébbtől a legszigorúbb felé, és közben figyeld a riportokat:

p=none -- Csak figyelés, nincs blokkolás

A p=none szint az ideális kiindulópont. Ebben az üzemmódban a fogadó szerver nem tesz semmit a sikertelen hitelesítésű levelekkel -- pontosan úgy kezeli őket, mintha nem lenne DMARC rekord. Viszont a rua és ruf címekre küldött riportokból láthatod, kik küldenek levelet a domainedről, és mely levelek buknak el az SPF/DKIM ellenőrzésen.

Tipp: Mindig a p=none szinttel kezdj, és 2-4 héten keresztül gyűjtsd a riportokat. Így feltérképezheted az összes legitim küldőt (hírlevél szolgáltató, CRM, számlázó rendszer, stb.), mielőtt szigorítanál.

p=quarantine -- Spam mappába irányítás

A p=quarantine szinten a fogadó szerver a nem hitelesített leveleket a spam (vagy karantén) mappába irányítja. Ez már aktív védelem: a hamisított levelek nem jelennek meg a címzett fő postaládájában. Ez a szint jó átmeneti megoldás, mert ha véletlenül egy legitim küldő konfigurációja nem stimmel, a levél nem veszik el teljesen -- a spam mappából még kimenthető.

Használhatod a pct= paramétert is a fokozatos bevezetéshez. Például a pct=25 azt jelenti, hogy a sikertelen levelek 25%-ára alkalmazd a karantén szabályt, a többit úgy kezeld, mintha p=none lenne.

p=reject -- Teljes elutasítás

A p=reject a legszigorúbb szint. A fogadó szerver teljes mértékben elutasítja azokat a leveleket, amelyek nem mennek át a DMARC ellenőrzésen. A levél nem kerül sem a bejövő, sem a spam mappába -- egyszerűen visszautasításra kerül. Ez a legerősebb védelem a domain hamisítás ellen, és egyben a legjobb jelzés a fogadó szerverek felé: komolyan vesszük az e-mail biztonságot.

Figyelem: Soha ne ugorj egyből p=reject-re a riportok elemzése nélkül! Ha egy harmadik feles küldőd (pl. hírlevél rendszer, CRM) nincs megfelelően konfigurálva az SPF/DKIM szempontjából, a levelei véglegesen elveszhetnek.

DMARC beállítás lépésről lépésre

Az alábbi lépésekkel biztonságosan és fokozatosan vezetheted be a DMARC-ot a domaineden:

  1. 1. lépés: Győződj meg róla, hogy az SPF és DKIM működik

    A DMARC az SPF-re és a DKIM-re épül -- ha ezek nincsenek beállítva, a DMARC nem tud mit ellenőrizni. Ellenőrizd, hogy a domainded rendelkezik érvényes SPF rekorddal (TXT rekord a domain gyökerén), és hogy a DKIM aláírás aktív a leveleidben. Használj online eszközöket, mint a MXToolbox vagy a Mail-tester az ellenőrzéshez.

  2. 2. lépés: Hozd létre a DMARC rekordot

    A DMARC rekord egy TXT típusú DNS bejegyzés, amelyet a _dmarc.domain.hu aldomainre kell elhelyezni. Íme egy példa kiinduló rekord:

    v=DMARC1; p=none; rua=mailto:dmarc@domain.hu; ruf=mailto:dmarc@domain.hu; fo=1

    A paraméterek jelentése:

    • v=DMARC1 -- a DMARC verzió azonosítója (kötelező, mindig ez az első)
    • p=none -- a szabályzat (policy): none, quarantine vagy reject
    • rua=mailto:... -- az összesített (aggregate) riportok fogadó címe
    • ruf=mailto:... -- a forensic (részletes) riportok fogadó címe
    • fo=1 -- forensic riport generálása már egyetlen sikertelen ellenőrzésnél is
  3. 3. lépés: Indulj p=none-nal és figyelj (2-4 hét)

    A p=none beállítással a DMARC nem befolyásolja a levelek kézbesítését, de elkezdi gyűjteni a riportokat. Ez az időszak arra szolgál, hogy feltérképezd az összes forrást, ahonnan a domainedet használva e-mail érkezik: saját mailszerver, Google Workspace, Microsoft 365, hírlevél szolgáltató (Mailchimp, SendGrid, stb.), CRM rendszer, számlázó szoftver, és bármilyen más rendszer.

  4. 4. lépés: Elemezd a DMARC riportokat (rua/ruf)

    A fogadó szerverek (Gmail, Outlook, Yahoo, stb.) napi rendszerességgel küldenek XML formátumú riportokat a rua címre. Ezek tartalmazzák az összes, a domainedről küldött levél hitelesítési eredményét. Használj riport-elemző eszközöket a feldolgozáshoz (lásd az "DMARC riportok értelmezése" szekciót).

  5. 5. lépés: Fokozatosan szigorítsd: none → quarantine → reject

    Ha a riportok alapján minden legitim küldő átmegy az SPF/DKIM ellenőrzésen és az alignment rendben van, fokozatosan léphetsz tovább. Először állítsd p=quarantine-re, opcionálisan alacsony pct= értékkel (pl. pct=10), majd növeld fokozatosan. Végül, ha stabilan minden rendben, válts p=reject-re.

Tipp: A teljes folyamat -- a p=none-tól a p=reject-ig -- általában 4-8 hetet vesz igénybe. Ne siess! Jobb lassabban haladni, mint elveszíteni fontos leveleket.

DMARC alignment (igazítás)

Az alignment a DMARC egyik legfontosabb -- és leggyakrabban félreértett -- koncepciója. A lényege egyszerű: a DMARC megköveteli, hogy az SPF vagy a DKIM által hitelesített domain egyezzen a levél From: fejlécében szereplő domainnel. Két típusa van:

SPF alignment

Az SPF alignment azt vizsgálja, hogy a levél Return-Path: (más néven "envelope from") fejlécében szereplő domain megegyezik-e a From: fejlécben szereplő domainnel. Ha a levelet a info@ceg.hu címről külditek, de a Return-Path bounce@mailservice.com, az SPF ugyan átmehet (mert a mailservice.com szerepel az SPF rekordban), de az SPF alignment nem teljesül, mert a két domain eltér.

DKIM alignment

A DKIM alignment azt vizsgálja, hogy a DKIM aláírásban szereplő d= domain megegyezik-e a From: fejlécben szereplő domainnel. Ha a levelet info@ceg.hu címről külditek, és a DKIM aláírás d=ceg.hu értékkel van aláírva, akkor a DKIM alignment teljesül. A legtöbb hírlevél szolgáltató lehetőséget ad arra, hogy a saját domainedet használd a DKIM aláírásban (ún. custom DKIM).

Relaxed vs. Strict mód

Az alignment kétféle módban működhet:

  • Relaxed (alapértelmezett): A From: domain és az SPF/DKIM domain szervezeti szinten (organizational domain) egyezhet. Tehát a news.ceg.hu és a ceg.hu is átmegy. A DMARC rekordban: aspf=r és adkim=r.
  • Strict: A domaineknek pontosan egyezniük kell. A news.ceg.hu nem felel meg a ceg.hu-nak. A DMARC rekordban: aspf=s és adkim=s.

Példa DMARC rekord strict alignment-tel:

v=DMARC1; p=quarantine; rua=mailto:dmarc@ceg.hu; aspf=s; adkim=s

Javaslat: Kezdetben használj relaxed módot (aspf=r; adkim=r), mert ez kevésbé törékeny. Strict módra csak akkor válts, ha pontosan tudod, hogy az összes legitim küldőd milyen domaint használ az SPF és DKIM oldalon.

DMARC riportok értelmezése

A DMARC riportok jelentik a protokoll "szemét" -- nélkülük vakon navigálnál. Két típusú riport létezik:

Aggregate riportok (rua)

Az összesített riportokat a nagy levelezőszolgáltatók (Gmail, Outlook, Yahoo, stb.) naponta egyszer küldik XML formátumban a rua= paraméterben megadott e-mail címre. Ezek a riportok tartalmazzák:

  • A küldő szerver IP-címét
  • Az ellenőrzött domain nevét
  • Az SPF és DKIM eredményét (pass/fail)
  • Az alignment eredményét
  • Az alkalmazott DMARC szabályzatot
  • Az adott forrásból érkezett levelek számát

Forensic riportok (ruf)

A forensic riportok egyedi, sikertelen levelekről szólnak, és részletesebb információt tartalmaznak (pl. a levél fejléceinek másolatát). Fontos: nem minden szolgáltató küld forensic riportot, és a GDPR miatt egyes európai szolgáltatók korlátozzák az ilyen adatok megosztását.

Riport-elemző eszközök

Az XML riportok kézi olvasása nehézkes és időigényes. Az alábbi eszközök segítenek a feldolgozásban:

  • DMARC Analyzer -- átlátható dashboard a riportok vizualizálásához
  • dmarcian -- részletes elemzés, alignment problémák feltárása, ingyenes szint is elérhető
  • Postmark DMARC -- teljesen ingyenes heti összesítő riportok
  • MXToolbox DMARC -- gyors ellenőrzés és riport-feldolgozás

Tipp: Ha nem szeretnél külön riport-feldolgozó szolgáltatást, a Postmark ingyenes DMARC eszköze kiváló kiindulópont. Csak állítsd a rua címet a Postmark által megadott e-mail címre, és heti rendszerességgel kapsz áttekinthető összesítést.

Gyakori DMARC hibák

A DMARC bevezetése során az alábbi hibákat követik el leggyakrabban a domain tulajdonosok és a rendszergazdák:

  • Egyből p=reject-re ugrás riportok nélkül: A leggyakoribb és legsúlyosabb hiba. Ha nem gyűjtöttél riportokat a p=none fázisban, nem tudhatod biztosan, hogy az összes legitim küldőd megfelelően van-e konfigurálva. Az azonnali p=reject bevezetése azt eredményezheti, hogy a hírleveled, a számlázó rendszered vagy a CRM-ed e-mailjei nem jutnak el a címzettekhez -- véglegesen.
  • Harmadik feles küldők elfelejtése: A legtöbb vállalkozás nem csak a saját szerveréről küld e-mailt. Mailchimp, SendGrid, Amazon SES, számlázó rendszerek, helpdesk szoftverek -- mindezeket be kell állítani az SPF rekordba, és lehetőleg DKIM custom domain aláírást is konfigurálni. Egyetlen kihagyott szolgáltató is DMARC hibát okoz.
  • Alignment probléma (subdomain vs. organizational): Ha a hírleveledet a news.ceg.hu subdomainről küldöd, de a DMARC rekord a ceg.hu gyökér domainen van strict módban (aspf=s), a subdomain levelei nem fognak alignment-et teljesíteni. Ilyenkor vagy relaxed módot használj, vagy hozz létre külön DMARC rekordot a subdomainre.
  • A rua/ruf cím elhagyása: Ha nem adod meg a riport címeket, a DMARC technikai szempontból működik (a policy érvényesül), de semmilyen visszajelzést nem kapsz arról, mi történik a leveleiddel. Ez olyan, mintha sötétben lőnél: nem tudod, mi működik és mi nem.
  • A DMARC rekord szintaktikai hibái: A DMARC rendkívül szigorú a szintaxist illetően. Egyetlen felesleges szóköz, hiányzó pontosvessző, vagy elírt paraméternév (pl. rua helyett rui) azt eredményezi, hogy a rekord érvénytelen, és a fogadó szerverek figyelmen kívül hagyják. Mindig ellenőrizd az új rekordot egy online validátor eszközzel.
  • DNS propagáció figyelmen kívül hagyása: A DNS módosítások nem azonnal lépnek érvénybe. A TTL (Time to Live) értéktől függően 1-48 óra is eltelhet, mire az új DMARC rekord mindenhol elérhető lesz. Ne módosítsd a policy-t és ne vonj le következtetéseket közvetlenül a DNS változtatás után.

Ellenőrző lista a DMARC bevezetés előtt:

  • SPF rekord érvényes és tartalmazza az összes küldő szervert
  • DKIM aláírás aktív és a saját domainedre mutat
  • Harmadik feles szolgáltatók (hírlevél, CRM, számlázó) konfigurálva
  • DMARC rekord szintaktikailag helyes (v=DMARC1 az első tag)
  • rua cím megadva a riportok fogadásához
  • Kiinduló policy: p=none

Következő lépés

Ismerd meg, hogyan javíthatod az e-mailjeid spam pontszámát, vagy fedezd fel a teljes Tudástárat:

Spam pontszám javítása Vissza a Tudástárba