Mi történik, ha egy több millió forintos üzleti ajánlat azért nem ér célba, mert a fogadó szerver egyszerűen nem bízik a domain nevében? 2026-ban a nagy levelezőrendszerek szigorúbbak, mint valaha, és a hitelesítés hiánya már nem választható opció, hanem kritikus hiba. Ön is valószínűleg érezte már azt a feszültséget, amikor a bonyolult DNS rekordok között böngészve attól tartott, hogy egyetlen elütés miatt napokra leállhat a teljes céges kommunikáció. A spamba érkező fontos levelek nemcsak bosszantóak, hanem mérhető bevételkiesést és komoly presztízsveszteséget okoznak minden vállalkozásnak.
Ebből a részletes útmutatóból pontosan megtudhatja, hogyan végezhető el a szakszerű dmarc beállítás lépésről lépésre. Segítünk, hogy e-mailjei garantáltan a postaládákban landoljanak, és domainje végre teljes védelmet élvezzen a visszaélésekkel szemben. Átvesszük a helyes szintaktikát, a különböző házirendek típusait, és azt a folyamatot, amellyel elérheti a 100%-os kézbesítési arányt a legmodernebb biztonsági protokollok mellett. Tapasztalt szakértőink tanácsait követve magabiztosan kezelheti a hitelesítési folyamatokat, elkerülve a leggyakoribb technikai buktatókat.
Mi az a DMARC és miért kötelező a beállítása 2026-ban?
A DMARC nem egy új keletű technológia, de 2026-ra a vállalati levelezés megkerülhetetlen alapkövévé vált. Egyszerűen megfogalmazva: ez egy olyan protokoll, amely megmondja a fogadó fél szerverének, mit tegyen, ha egy levél látszólag a Te domainedről érkezik, de nem megy át az azonosítási folyamaton. A DMARC (Domain-based Message Authentication, Reporting, and Conformance) az SPF és a DKIM technológiákra építve ad egyértelmű utasítást a levelezőrendszereknek, ezzel lezárva a biztonsági réseket.
A fordulópontot a Google és a Yahoo 2024 februárjában bevezetett szigorításai jelentették. Ami akkor még csak a napi 5000-nél több e-mailt küldő “Bulk Senderekre” vonatkozott, az 2026-ra minden üzleti szereplő számára kötelező normává vált. Ha a dmarc beállítás hiányzik a DNS rekordjaid közül, a leveleid jelentős része, akár 30-40%-a is elveszhet a digitális zajban. A fogadó szerverek ma már bizalmatlanok az azonosítatlan forrásokkal szemben, így a hitelesítés hiánya közvetlenül rontja az üzleti kommunikáció hatékonyságát.
Mi történik, ha figyelmen kívül hagyod ezt a beállítást? A következmények azonnaliak és fájdalmasak:
- A leveleid nagy része automatikusan a spam mappába kerül.
- A kritikus üzleti ajánlatok vagy számlák egyáltalán nem érkeznek meg a címzetthez (hard bounce).
- A domained “hírneve” (sender reputation) romlani kezd, amit később hónapokig tarthat helyreállítani.
- A bűnözők könnyebben küldhetnek adathalász leveleket a céged nevében, rombolva a márkádba vetett bizalmat.
A DMARC jelentősége a kiberbiztonságban
A DMARC az első védelmi vonal az adathalászat (phishing) ellen. Megakadályozza, hogy illetéktelenek a Te domainedet használják “feladóként” megtévesztő levelek küldéséhez. Ez a technológia nemcsak a saját rendszereidet védi, hanem az ügyfeleidet is a nevedben elkövetett csalásoktól. A védekezés komplex folyamat, ezért érdemes átnézned a phishing védelem 2026 útmutatónkat is a teljes biztonság érdekében. A helyes konfigurációval eléred, hogy a szerverek azonnal elutasítsák a hamisított leveleket, mielőtt azok bárki postafiókjába eljutnának.
Kézbesíthetőség: A postafiókok kapuőrei
A fogadó szerverek 2026-ban szigorúbbak, mint valaha. A ‘Bulk Sender’ státusz már nem csak a hírlevélküldőket érinti; bármilyen domaint korlátozhatnak, ha a hitelesítés nem teljes körű. A pontos dmarc beállítás közvetlenül javítja a marketing e-mailek és a napi üzleti levelek megnyitási arányát. A hitelesített feladóktól érkező levelek magasabb bizalmi pontszámot kapnak, így nagyobb eséllyel landolnak az elsődleges beérkező levelek között, elkerülve a promóciós vagy spam füleket. A DMARC riportok segítségével ráadásul pontos látleletet kapsz arról, ki és honnan küld leveleket a domained nevében, így az árnyék-informatika is kontroll alá kerül.
Az e-mail hitelesítés szentháromsága: SPF, DKIM és DMARC
A modern üzleti levelezés biztonsága három technológiai pilléren nyugszik. Ezek a protokollok nem helyettesítik, hanem kiegészítik egymást. Az SPF (Sender Policy Framework) a lista, amely meghatározza, mely szerverek jogosultak az ön domainje nevében levelet küldeni. Ez a módszer az IP-címek ellenőrzésén alapul. A DKIM (DomainKeys Identified Mail) egyfajta digitális aláírást helyez el az üzenet fejlécében. Ez garantálja a fogadó fél számára, hogy a levél tartalma nem módosult a küldés óta. A titkosított kulcspár segítségével a szerver igazolja az üzenet integritását.
A DMARC tölti be a rendőrfőnök szerepét ebben a rendszerben. Míg az SPF és a DKIM csak adatot szolgáltat a hitelességről, a DMARC ad utasítást a fogadó szervernek, hogy mi történjen, ha a tesztek elbuknak. A DMARC.org szakmai útmutatásai alapján ez a protokoll teszi lehetővé a domain-tulajdonosok számára, hogy kontrollálják saját hírnevüket. Önmagában az SPF vagy a DKIM alkalmazása ma már kevés. Egy 2025-ös iparági elemzés szerint a célzott adathalász támadások 78%-a olyan domaineket érint, ahol hiányzik a teljes körű hitelesítési lánc. A dmarc beállítás hiánya miatt a levelek jelentős része a kukában landolhat.
Hogyan dolgoznak együtt a rekordok?
A hitelesítési folyamat a levél indításakor kezdődik. A fogadó szerver lekéri a DNS rekordokat, majd összeveti az érkező adatokat az elvárásokkal. Kulcsfontosságú fogalom itt az ‘Alignment’, azaz az igazítás. Ez azt jelenti, hogy a levél fejlécében látható feladói domainnek egyeznie kell az SPF és DKIM rekordokban szereplő domainnel. Gyakori hiba, amikor az SPF státusza ‘pass’, de a DMARC mégis ‘fail’ eredményt ad. Ez jellemzően akkor fordul elő, ha a technikai feladó (Envelope From) eltér a felhasználó által látott címtől, ami például rosszul konfigurált hírlevélküldő rendszereknél fordulhat elő.
Előfeltételek a DMARC beállítása előtt
A sikeres dmarc beállítás nem kezdhető el az alapok nélkül. Első lépésként ellenőrizze az SPF rekordot. Az AWH tárhelyein ez alapértelmezetten be van állítva, így ügyfeleinknek ezzel ritkán akad teendője. A második lépés a DKIM aláírás aktiválása a levelező szerveren, amely biztosítja a kriptográfiai védelmet. A precíz konfiguráció érdekében javasolt egy biztonságos email szolgáltató választása, ahol a technikai háttér támogatja ezeket a modern protokollokat. Az automatizáció és a több mint 10 éves szakmai tapasztalat nálunk garantálja, hogy a beállítás hibamentes legyen. A rendszerek 99,9%-os rendelkezésre állása mellett a levelek célba érkezése nem lehet szerencse kérdése. Ha biztosra akar menni, válasszon megbízható domaint a hitelesített levelezéséhez.
DMARC rekord szintaxis: A tagek és szabályok dekódolása
A DMARC rekord egy speciális TXT bejegyzés a domain DNS zónájában. Első ránézésre érthetetlen kódhalmaznak tűnhet, de a felépítése szigorúan logikus és moduláris. Minden dmarc beállítás alapja a v=DMARC1 tag; ez azonosítja a rekord típusát a fogadó szerverek számára. Ezt követik a pontos utasítások, amelyek meghatározzák a levelezés biztonsági szintjét és a visszajelzések módját.
A rekord felépítése kulcs-érték párokból áll, amelyeket pontosvessző választ el egymástól. Nézzük a legfontosabb összetevőket:
- v (Version): Mindig
DMARC1. Ez kötelező elem, ezzel indul a rekord. - p (Policy): Meghatározza, mi történjen azokkal a levelekkel, amelyek elbuknak az ellenőrzésen.
- rua (Reporting URI for Aggregate reports): Az az e-mail cím, ahová a napi összesített jelentéseket várjuk (pl.
mailto:admin@domain.hu). - ruf (Reporting URI for Forensic reports): Ide érkeznek a részletes, egyedi hibaüzenetek.
- pct (Percentage): A szabályozás alá vont levelek százalékos aránya.
- adkim / aspf (Alignment): A DKIM és SPF illeszkedés szigorúságát szabályozza (s = strict, r = relaxed).
A technikai részletek pontos konfigurálásához érdemes átnézni az AWH tudásbázisát, ahol további segítséget kaphatsz a DNS rekordok kezeléséhez.
A három fő DMARC irányelv (Policy)
A p paraméter értéke határozza meg a rendszer szigorúságát. A bevezetés során a fokozatosság elvét kell követni, hogy elkerüld a legitim levelek elvesztését.
- p=none (Monitorozás): Ebben a fázisban a szerverek nem avatkoznak be a kézbesítésbe. Csak adatot gyűjtünk és jelentéseket kapunk. A statisztikák szerint a tudatos cégek 85%-a ezen a szinten kezdi a munkát, hogy feltérképezze a saját levelezési forrásait.
- p=quarantine (Karantén): Ha egy levél gyanús, a fogadó fél a spam mappába teszi azt. Ez egy biztonságos középút, ahol a levél még megérkezik, de a felhasználó figyelmeztetést kap.
- p=reject (Elutasítás): A legmagasabb biztonsági szint. A nem hitelesített leveleket a fogadó szerver azonnal eldobja. 2026-ban ez az elvárt cél a kritikus üzleti kommunikáció védelmében.
Haladó beállítások: pct és alignment
A pct tag használata lehetővé teszi a kockázatkezelést. Ha például a p=reject; pct=20 beállítást alkalmazod, akkor a szerver csak a gyanús levelek 20%-át utasítja el, a többinél engedékenyebb marad. Ez segít abban, hogy éles környezetben, de kontrollált módon teszteld a szigorúbb szabályokat.
Az alignment (illeszkedés) beállításai határozzák meg, mennyire legyen precíz az ellenőrzés. Az aspf=s (strict) mód megköveteli, hogy a feladó domain karakterre pontosan egyezzen az SPF rekordban szereplővel. A relaxed (r) beállítás megengedőbb, így az aldomainekről küldött levelek is könnyebben átmennek a szűrőn. A ruf jelentéseket csak indokolt esetben kapcsold be, mert a részletes hibaüzenetek 2026-ban már komoly adatvédelmi kérdéseket vethetnek fel a levéltartalmak továbbítása miatt.
A sikeres dmarc beállítás titka a folyamatos finomhangolás. Kezdj monitorozással, elemezd a jelentéseket, és csak akkor válts szigorúbb irányelvre, ha biztos vagy benne, hogy minden jogos forrásod megfelelően hitelesítve van.
DMARC beállítás lépésről lépésre: cPanel és DNS útmutató
A dmarc beállítás folyamata technikainak tűnhet, de valójában egy logikus és jól strukturált műveletsor. A célunk, hogy elhelyezzünk egy speciális szöveges rekordot a domain név DNS zónájában, amely pontos utasításokat ad a fogadó szervereknek a leveleink hitelesítéséről. Ez a lépés elengedhetetlen ahhoz, hogy a céges e-mailek ne a spam mappában kössenek ki.
Beállítás aWh cPanel felületen
A legtöbb ügyfelünk az aWh cPanel felületét használja a kezeléshez. A belépés után keresse meg a ‘Zone Editor’ menüpontot a Tartományok szekcióban. Kattintson a ‘Manage’ gombra a módosítani kívánt domain mellett, majd válassza az ‘Add Record’ lehetőséget. A rekord típusánál válassza a ‘TXT’ opciót.
A név mezőbe írja be: _dmarc. A rendszer automatikusan kiegészíti ezt a teljes domain névvel. Az érték mezőbe illessze be a következő példát: v=DMARC1; p=none; rua=mailto:admin@domainod.hu. Ez a beállítás 2026-ban is a legbiztonságosabb kezdőpont, mivel a ‘none’ házirend lehetővé teszi az adatgyűjtést anélkül, hogy véletlenül blokkolná a jogos leveleket. Részletesebb útmutatóért látogasson el az aWh tudásbázisba, ahol további példákat is talál.
DMARC beállítás külső DNS szolgáltatónál
Ha Cloudflare vagy más külső DNS kezelőt használ, a folyamat alapjai megegyeznek, de a felület eltérő lehet. Cloudflare esetén ügyeljen arra, hogy a rekord neve csak _dmarc legyen, a ‘Proxy status’ pedig maradjon kikapcsolva, mivel a DNS rekordok ezen típusa nem igényel proxizást. A TTL (Time To Live) értéket állítsa 3600 másodpercre (1 óra), így a módosítások viszonylag gyorsan frissülnek a globális hálózaton.
A szintaktikai hibák elkerülése kritikus. Sok DNS kezelő felület automatikusan idézőjelek közé teszi a TXT értéket, ezért ne írjon manuálisan idézőjeleket a mezőbe, mert a dupla jelölés érvénytelenítheti a rekordot. A dmarc beállítás során mindig ellenőrizze, hogy a pontosvesszők a helyükön vannak-e a tagek között.
Ellenőrzés és validálás
A mentés után a módosítások nem válnak azonnal láthatóvá. A DNS propagáció ideje szolgáltatótól függően 15 perctől akár 24 óráig is tarthat, bár a modern rendszereknél ez általában egy órán belül lezajlik. A validáláshoz használja az MXToolbox vagy a DMARCian Inspector ingyenes eszközeit. Ezek a szoftverek azonnal jelzik, ha a szintaxis hibás vagy a rekord nem elérhető.
A végső tesztet érdemes a Mail-Tester.com segítségével elvégezni. Küldjön egy e-mailt a rendszer által generált egyedi címre, és nézze meg a pontszámot. Ha a hitelesítés rendben van, a DMARC szekció zöld jelzést kap. Ez a visszaigazolás garantálja, hogy a levelezőrendszere megfelel a 2026-os biztonsági elvárásoknak.
Azonnal javítaná levelei kézbesítési arányát? Válassza a biztonságos céges levelezés csomagjainkat a garantált sikerért.
A DMARC jelentések (RUA) értelmezése és finomhangolása
A DMARC beállítás nem egy egyszeri feladat, hanem egy folyamatos monitorozási ciklus kezdete. Az RUA (Aggregate Reports) jelentések olyan napi szintű XML fájlok, amiket a nagy levelező szolgáltatók, például a Google vagy a Microsoft küldenek a DNS rekordban megadott e-mail címre. Ezek a fájlok tartalmazzák az összes olyan IP-címet, amely az Ön domain nevében próbált levelet kézbesíteni, valamint azt is, hogy ezek az üzenetek átmentek-e az SPF és DKIM ellenőrzéseken.
Egy átlagos, 20-50 fős magyar kkv esetében havi szinten akár több száz ilyen XML fájl is érkezhet. Ezeket manuálisan, szövegszerkesztővel olvasni rendkívül időigényes. Ha mégis erre kényszerül, a fájlban a <row> és a <policy_evaluated> szekciókat keresse. Itt látható, hogy a fogadó fél hogyan kezelte a levelet, és pontosan hol bukott el a hitelesítés. A cél az, hogy a p=none irányelvet addig tartsuk fenn, amíg a jogos levelek 100%-a sikeresen nem vizsgázik.
Jelentéskezelő eszközök használata
Hosszú távon fenntarthatatlan, hogy a technikai jelentések a saját vagy a rendszergazda postafiókját terheljék. A napi több tucat nyers XML fájl csak felesleges zajt kelt és elrejti a valódi biztonsági incidenseket. Érdemes erre dedikált aggregátor szolgáltatásokat használni.
- Ingyenes megoldások: A Postmark DMARC Monitoring vagy a Cloudflare beépített eszközei kiválóak az induláshoz. Ezek vizuális grafikonokká alakítják a bonyolult kódot.
- Fizetős szoftverek: A Dmarcian vagy a Valimail részletesebb elemzést és azonnali riasztásokat kínál, ha valaki visszaél a domainnel.
- Azonosítás: Az aggregált adatokból azonnal látszik, ha egy ismeretlen, távoli szerver próbálja használni a céges identitását. Ilyenkor a jelentés segít eldönteni, hogy egy elfelejtett belső szolgáltatásról vagy valódi adathalász támadásról van-e szó.
Gyakori hibák és javításuk
A tapasztalatok szerint a dmarc beállítás során a legtöbb hiba a külső szolgáltatók integrációjánál csúszik be. Gyakori, hogy a cég marketing csapata Mailchimp vagy HubSpot rendszert kezd használni, de elfelejtik frissíteni az SPF rekordot vagy beállítani a DKIM kulcsokat. Emiatt a hírlevelek a p=reject bevezetés után azonnal a kukában landolnak.
Kritikus hiba a több DMARC rekord jelenléte is. A DNS zónában szigorúan csak egyetlen _dmarc kezdetű TXT rekord szerepelhet. Ha kettő van, a fogadó szerverek gyakran mindkettőt figyelmen kívül hagyják, így a védelem megszűnik. Szintén kerülendő a túl korai szigorítás. A p=none szintről a p=quarantine-ra való váltás előtt legalább 14-30 napnyi hibamentes adatot gyűjtsön.
Következő lépések a teljes biztonságért
A DMARC bevezetése és a p=reject szint elérése után megnyílik az út a BIMI (Brand Indicators for Message Identification) előtt. Ez a technológia lehetővé teszi, hogy a hitelesített levelek mellett a cég logója is megjelenjen a címzettek postaládájában. Ez 2026-ban már nem csak biztonsági kérdés, hanem a vállalati imázs és a bizalomépítés alapköve.
A biztonságos levelezés alapja a stabil infrastruktúra. Fedezze fel webtárhely csomagjainkat a maximális biztonságért és a zökkenőmentes adminisztrációért. A professzionális DMARC felügyelet nem csupán IT feladat, hanem a cég digitális vagyonának védelme.
Kezdje el a felkészülést a 2026-os e-mail biztonsági szabványokra
A hitelesített levelezés ma már nem csupán egy választható opció, hanem az üzleti folytonosság alapfeltétele. Az SPF, a DKIM és a DMARC technológiai hármasa 2026-ra a Gmail és az Outlook rendszereiben is kötelező alapkövetelménnyé válik minden vállalkozás számára. A helyes dmarc beállítás elvégzése garantálja, hogy a kiküldött ajánlatok és számlák ne a spam mappában kössenek ki. Több mint 10 éves tapasztalatunk alapján a precíz DNS konfiguráció és a RUA jelentések rendszeres elemzése akár 99 százalékkal is csökkentheti a domain névvel való visszaélések esélyét.
Díjnyertes cPanel infrastruktúránk és szakértő magyar ügyfélszolgálatunk minden technikai segítséget megad a váltáshoz. Levesszük a válláról a szintaxis dekódolásának és a szabályok finomhangolásának terhét, miközben modern és stabil környezetet biztosítunk levelezésének. Váltson biztonságos aWh email tárhelyre és segítünk a beállításban!
A professzionális digitális jelenlét a biztonságos technikai alapoknál kezdődik. Hozza meg a döntést időben, és biztosítsa cége zavartalan kommunikációját a jövőben is.
Gyakran ismételt kérdések a DMARC használatáról
Mi történik, ha elrontom a DMARC beállítást?
Ha hibás a DMARC beállítás, a leveleid jelentős része, akár a kiküldött üzenetek 100 százaléka is a spam mappában köthet ki vagy végleg elveszhet. Szigorú p=reject irányelv mellett a fogadó szerverek azonnal elutasítják a hitelesítetlen e-maileket, így az üzleti partnereid semmit nem kapnak meg tőled. Érdemes kezdetben p=none beállítással indítani a tesztelést, hogy elkerüld a kommunikációs blokkolást.
Mennyi idő, amíg a DMARC rekord érvénybe lép?
A DMARC rekord érvénybe lépése általában 24 és 48 óra közötti időt vesz igénybe a globális DNS propagáció miatt. A technikai módosítás után a legtöbb levelezőszerver 1 órán belül látja az új adatokat, de a teljes átfutáshoz türelem kell. A folyamat sebessége a korábbi DNS rekordoknál beállított TTL értéktől függ, ami meghatározza a frissítési gyakoriságot.
Minden domainemhez külön DMARC rekord kell?
Igen, minden egyes fődomainhez önálló DMARC rekordot kell létrehoznod a DNS zónában a teljes védelem érdekében. Az aldomainek alapértelmezés szerint öröklik a fődomain beállításait, kivéve, ha külön sp címkével mást határozol meg nekik. A 2024-es Google és Yahoo szigorítások óta ez a lépés elengedhetetlen a megbízható kézbesítéshez minden használt címednél.
Ingyenes a DMARC beállítása?
A DMARC rekord beállítása teljesen ingyenes, hiszen csak egy szöveges bejegyzést kell elhelyezned a saját DNS kezelőfelületeden. Költségek akkor merülhetnek fel, ha professzionális elemző szoftvert használsz a napi több ezer XML jelentés feldolgozására. Ezek az automatizált eszközök havi 3500 és 18000 Ft közötti összegbe kerülhetnek a forgalom mértékétől és a funkcióktól függően.
Hogyan kaphatok kevesebb e-mail jelentést a DMARC-tól?
A jelentések mennyiségét a pct címke használatával vagy az összesített jelentések (rua) gyakoriságának módosításával szabályozhatod hatékonyan. Ha a pct=20 értéket adod meg, akkor a fogadó szerverek csak az üzenetek 20 százalékáról küldenek részletes visszajelzést. Ez a módszer jelentősen csökkenti a beérkező levelek számát, miközben továbbra is elegendő adatot biztosít a hitelesítési hibák javításához.
Kell DMARC, ha csak Gmailt vagy Outlookot használok céges levelezésre?
Igen, a DMARC beállítás akkor is kötelező, ha külső felhőszolgáltatókat használsz a céges levelezésedhez a saját domaineddel. A Google 2024 februárjától előírja ezt minden tömeges feladónak, aki napi 5000-nél több levelet küld a rendszerein keresztül. Megfelelő rekord nélkül a Gmail és az Outlook szerverei gyanúsnak jelölhetik a saját domainedről érkező, egyébként hiteles üzeneteket is.
Mi a különbség a p=quarantine és a p=reject között?
A p=quarantine beállítás a spam mappába irányítja a gyanús leveleket, míg a p=reject teljesen megakadályozza azok kézbesítését a címzettnek. A karantén egyfajta biztonsági háló a tesztelési fázisban, ahol a levelek 100 százaléka még elérhető marad az ellenőrzéshez. A reject szint a legmagasabb biztonsági fokozat, amit csak a hitelesítési folyamatok teljes stabilizálása után javasolt élesíteni a domainen.
Hogyan ellenőrizhetem, hogy van-e már DMARC rekordom?
A legegyszerűbben online diagnosztikai eszközökkel, például az MXToolbox vagy a dmarcian felületén ellenőrizheted a rekordod aktuális állapotát. Parancssorból a nslookup -type=txt _dmarc.domainneved.hu utasítással kérdezheted le a beállítást másodpercek alatt bármilyen operációs rendszeren. Ha nem kapsz v=DMARC1 kezdetű választ a lekérdezés során, akkor a domained még nem rendelkezik ezzel a kritikus védelemmel.
2026-04-06