# DMARC beállítás lépésről lépésre — miért nem érkeznek meg a leveleid | RootCore LLC > SPF, DKIM és DMARC egyszerű nyelven: mit jelentenek a rekordok, mi a leggyakoribb hiba, és hogyan vezesd be a DMARC-ot úgy, hogy közben ne dobd ki a saját számláidat. Oldal: https://cyber-security.rootcr.com/tudastar/dmarc-beallitas/ Frissítve: 2026-08-20 --- # DMARC beállítás: miért nem érkeznek meg a leveleid > **Röviden:** Az SPF, a DKIM és a DMARC együtt mondja meg a fogadó levelezőrendszernek, hogy egy levél tényleg a te domainedről jött-e. A Gmail 2024. február 1. óta minden feladótól elvárja legalább az SPF vagy a DKIM meglétét, a napi 5000 levél feletti küldőktől pedig mindhármat. Ha ez nincs rendben, két dolog történik egyszerre: a saját leveleid a spam mappában landolnak, és bárki küldhet levelet a cégednév alatt. A beállítás egy-két nap, a szigorítás két-négy hét — az utóbbit nem szabad siettetni. ## A három rekord, egyszerű nyelven Képzeld el, hogy a leveled egy boríték, amit a portán ellenőriznek. | Rekord | Mit mond ki | Mi a szerepe a portán | |---|---|---| | **SPF** | Mely szerverek adhatnak fel levelet a domain nevében | „Ez a futár szerepel a listánkon" | | **DKIM** | Digitális aláírás a levélen | „A pecsét sértetlen, útközben nem nyúltak hozzá" | | **DMARC** | Mi a teendő, ha az előző kettő nem stimmel | „Ha nem stimmel: engedjük át, tegyük külön, vagy küldjük vissza?" | A DMARC önmagában nem véd: az SPF és a DKIM eredményére épül. Ezért kell mindhárom. ## Így néznek ki a valóságban **SPF** — TXT rekord magán a domainen: ``` example.com. TXT "v=spf1 include:_spf.google.com include:sendgrid.net -all" ``` **DKIM** — TXT rekord egy választó (selector) alatt; a kulcsot a levelezőszolgáltató adja: ``` selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..." ``` **DMARC** — TXT rekord a `_dmarc` aldomainen: ``` _dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r; pct=100" ``` A DMARC-rekord mezői, amiket ismerni érdemes: - **`p=`** — a szabály: `none` (csak figyelj és jelents), `quarantine` (spam mappába), `reject` (vissza se vedd). - **`rua=`** — ide jönnek az összesítő jelentések. Enélkül vakon dolgozol. - **`adkim=` / `aspf=`** — mennyire szigorúan kell egyeznie a domainnek: `r` (relaxed, aldomain is jó) vagy `s` (strict, pontos egyezés). - **`pct=`** — a levelek hány százalékára vonatkozzon a szabály. Fokozatos bevezetésnél hasznos. ## A négy leggyakoribb hiba ### 1. Két SPF-rekord egy domainen Ez a leggyakoribb, és azonnal érvénytelenné teszi az egészet. A szabvány egyetlen SPF-rekordot enged domainenként. Ha a levelezőszolgáltató is felvett egyet, meg a hírlevélrendszer is, akkor a kettőt **össze kell vonni**, nem egymás mellé tenni: ``` "v=spf1 include:_spf.google.com include:sendgrid.net -all" ``` ### 2. Túl sok DNS-lekérdezés Az SPF kiértékelése legfeljebb tíz DNS-lekérdezést végezhet. Minden `include:` legalább egyet elhasznál, és van, amelyik többet is, mert magában is hivatkozik tovább. A tizedik fölött a kiértékelés hibára fut, és a levél úgy jár, mintha nem is lenne SPF-ed. Ha sok szolgáltatód van, az `include`-okat ritkítani kell. ### 3. Elfelejtett küldő A klasszikus eset: a levelezés a Google-nél van, de a számlázóprogram, a webshop és a hírlevélrendszer máshonnan küld. Az SPF csak a Google-t sorolja fel, tehát a számlád akad el — pont az, ami a legfontosabb. Ezért kezdődik a munka mindig **számbavétellel**: melyik rendszer küld levelet a nevedben? ### 4. Azonnali `p=reject` Csábító rögtön a legszigorúbb szabályt beállítani. Ilyenkor viszont a még nem hitelesített jogos küldőid levelei is eltűnnek — és nem a spam mappában, hanem véglegesen. A DMARC bevezetése szándékosan lassú folyamat. ## A bevezetés menete ### 1. lépés — számbavétel Írd össze, mi küld levelet a nevedben: levelezőszolgáltató, webshop, számlázó, CRM, hírlevél, ügyfélszolgálati rendszer, monitoring-riasztás. Ez a lista lesz az SPF alapja. ### 2. lépés — SPF rendbetétele Egyetlen érvényes rekord, benne az összes jogos küldő. A zárás legyen `-all` (hard fail) vagy legalább `~all` (soft fail); a `+all` mindenkit átenged, tehát értelmetlen. ### 3. lépés — DKIM minden küldőnél Minden rendszerben külön be kell kapcsolni, mindegyik saját kulccsal és választóval. A legtöbb szolgáltatónál ez egy kapcsoló és egy DNS-rekord. ### 4. lépés — DMARC figyelő módban ``` "v=DMARC1; p=none; rua=mailto:dmarc@example.com" ``` Ilyenkor **semmi nem változik a kézbesítésben**, viszont naponta kapsz összesítő jelentéseket arról, ki küld levelet a nevedben, és melyik bukik el a hitelesítésen. Ez a legfontosabb szakasz: itt derül ki, mit felejtettél ki a listából. Két-négy hetet érdemes rászánni. ### 5. lépés — szigorítás Ha a jelentésekben már minden jogos küldő átmegy, jöhet a `quarantine`, majd egy-két hét után a `reject`. Aki óvatos, a `pct=` mezővel lépcsőzhet: előbb a forgalom negyedére, aztán felére, végül mindenre. ## Mit vársz a jelentésektől? A DMARC-jelentés XML, és nem embernek való olvasásra készült. Két dolgot keress benne: - **Jogos küldő, ami elbukik** — ezt javítani kell (hiányzó `include`, kikapcsolt DKIM). - **Idegen szerver, ami a nevedben küld** — ez vagy egy elfelejtett rendszered, vagy visszaélés. A legtöbb ügyfélnél ez a jelentés hozza az első meglepetést. Ha nem akarsz XML-t olvasni, van több szolgáltatás, ami emberi nyelvre fordítja; a jelentések fogadó címét ilyenkor arra állítod. ## Miért lett ez hirtelen fontos? Mert a nagy szolgáltatók szigorítottak. A Gmail 2024. február 1. óta **minden feladótól** elvárja legalább az SPF vagy a DKIM meglétét, érvényes PTR-rekordot és TLS-kapcsolatot. Aki naponta 5000-nél több levelet küld Gmail-címekre, annak **SPF, DKIM és DMARC is kell** (a DMARC-szabály lehet `p=none`), valamint egykattintásos leiratkozás a marketinglevelekben. A Postmaster Toolsban jelzett spam-arányt 0,3% alatt kell tartani — a Google ajánlása 0,1% alatt. A gyakorlati következmény: hitelesítés nélkül a leveled először a spam mappába kerül, aztán már el sem jut odáig. ## Ellenőrzés: hogyan tudod, hogy jó? 1. **Küldj tesztlevelet** egy Gmail- és egy Outlook-fiókba a saját rendszereidből — mindegyikből külön. 2. **Nézd meg a fejlécet** („Eredeti megjelenítése" a Gmailben): az `Authentication-Results` sorban `spf=pass`, `dkim=pass` és `dmarc=pass` kell álljon. 3. **Nézd meg, hogy a From-domain egyezik-e** az SPF vagy a DKIM domainjével. Ezt hívják igazításnak (alignment), és a DMARC ezen bukik el a leggyakrabban akkor is, ha az SPF és a DKIM külön-külön rendben van. 4. **Egy hét múlva nézd meg a DMARC-jelentést** — ez mutatja meg, amit a tesztleveleiddel nem látsz. ## Gyakori kérdések ### Ha nem küldök hírlevelet, akkor is kell? Igen, két okból. Egyrészt a számlák és az automatikus visszaigazolások is levelek, és ezeknek meg kell érkezniük. Másrészt a hitelesítés hiánya nem a te küldésedről szól, hanem arról, hogy más küldhet a nevedben. ### Van olyan domain, amiről soha nem küldök levelet. Az érdekes? Nagyon. Pont az ilyen „parkoló" domaineket használják hamisításra. Ezekre a legszigorúbb rekord való, mert nincs mit elrontani vele: ``` "v=spf1 -all" "v=DMARC1; p=reject;" ``` ### A hosting szolgáltatóm már beállított valamit. Az nem elég? Jellemzően egy alap SPF-rekordot ad a saját szerverére. Ez akkor elég, ha minden leveled onnan megy — de a webshop, a számlázó és a hírlevélrendszer általában máshonnan küld. Épp azok a küldők maradnak ki, amelyek a legfontosabbak. ### Mennyi idő az egész? A rekordok beállítása egy-két nap, plusz néhány óra DNS-terjedés. A figyelő szakasz két-négy hét — ezt nem lehet átugrani, mert ez védi meg a saját leveleidet. Utána a szigorítás napok kérdése. ### Mi történik, ha rosszul állítom be? A leggyakoribb következmény, hogy a saját leveleid akadnak el. Ezért kell a figyelő szakasz és a fejléc-ellenőrzés: mindkettő azelőtt mutatja meg a hibát, hogy a vásárlóid találkoznának vele. --- Ha nem szeretnél DNS-rekordokat szerkeszteni, [rendbe tesszük az e-mail-hitelesítésedet](/email-biztonsag/) — a számbavételtől a `reject` szintig, közben végig mérve, hogy a saját leveleid rendben mennek.