DMARC policy mód: mikor válts none-ról quarantine-re vagy reject-re cold email küldésnél
Sok B2B cég domainje évek óta dmarc policy not enabled állapotban áll, vagyis csak megfigyel, de semmit nem véd. Amikor végre szigorítanak és p=reject-re váltanak felkészülés nélkül, a következő cold email kampány levelei is elakadhatnak, mert a saját alignment-jük sem stabil. Ez a cikk megmutatja, hogyan válaszd ki és vezesd be a megfelelő DMARC policy módot úgy, hogy a targeted outreach deliverability ne sérüljön.
- A dmarc policy not enabled (p=none) állapot önmagában nem árt a küldésnek, de semmilyen védelmet sem ad a domain ellen.
- A p=quarantine és a p=reject csak akkor biztonságos, ha az SPF/DKIM alignment minden küldő forrásnál (ESP, CRM, cold email eszköz) stabilan 90% fölött van.
- A pct paraméterrel fokozatosan, hetekre elosztva érdemes bevezetni a szigorúbb módot, nem egyből 100%-on.
- A cold email küldést érdemes külön subdomainre tenni, hogy a root domain reject policy-ja ne kockáztassa a fő céges levelezést.
- A rua riportok rendszeres olvasása nélkül a policy váltás vakrepülés.
Miért számít a DMARC policy mód cold email küldőknél
A DMARC a SPF és a DKIM eredményét köti össze a látható feladó domainnel, és megmondja a fogadó szervereknek, mit tegyenek, ha egy levél nem illeszkedik a domain hitelesített forrásaihoz. Cold email esetében ez különösen fontos, mert a napi küldött mennyiség kicsi, tehát a domain reputáció minden egyes hibás vagy meghamisítottnak tűnő levélre érzékenyebben reagál, mint egy nagy volumenű hírlevél listánál.
A legtöbb magyar KKV domainje ma is dmarc policy not enabled állapotban van, vagyis vagy nincs DMARC rekord, vagy p=none van beállítva, ami csak monitoroz, de nem avatkozik be. A Gmail és a Yahoo bulk sender szabályai óta ez a minimum elvárás, de önmagában nem elég ahhoz, hogy a fogadó szerver megbízzon a domainben — a p=none állapot semmilyen jelzést nem ad a küldő szándékáról hibás levelek esetén.
Amikor egy cég úgy dönt, hogy szigorít és p=reject-re vált, a cél gyakran a phishing és a domain spoofing elleni védelem, nem a cold email korlátozása. A gyakorlatban mégis ez történik, ha a saját cold email eszköz vagy CRM autoresponder nincs megfelelően illesztve az SPF/DKIM alignment-hez.
A három DMARC policy mód: none, quarantine, reject — és a helyes szintaxis
A DMARC rekordot TXT bejegyzésként kell közzétenni a _dmarc.pelda-cegdomain.hu néven, és a dmarc policy syntax alapstruktúrája mindig ugyanaz: a v=DMARC1 kötelező tag után jön a p= érték, majd opcionálisan a riportcímek és a százalékos lefedettség.
A p=none mód csak megfigyel: a fogadó szerver továbbra is kézbesíti a levelet a saját belátása szerint, függetlenül az alignment eredményétől, de a rua riportokban látod, mely forrásokból mennek ki DMARC-kompatibilis és inkompatibilis levelek a domain nevében.
A dmarc policy quarantine mód a nem illeszkedő leveleket a spam vagy junk mappába irányítja, de nem dobja el őket teljesen. Ez a köztes lépés, ahol már van tétje a hibáknak, de még van esély a felfedezésre és a javításra, mielőtt a levelek teljesen elvesznének.
A dmarc policy of reject a legszigorúbb mód: a nem illeszkedő leveleket a fogadó szerver a kézbesítés előtt elutasítja. Ide csak akkor érdemes eljutni, ha minden legitim küldő forrás — beleértve a cold email platformot, a marketing ESP-t és a tranzakciós levelező szolgáltatást — stabilan átmegy az alignment-en.
- v=DMARC1 — kötelező verziójelző, mindig az első elem
- p= — a fő policy mód: none, quarantine vagy reject
- sp= — külön policy az alldomain(ok)ra, ha eltér a fő domainétől
- pct= — a szabály hány százalékára vonatkozzon (fokozatos bevezetéshez)
- rua=mailto:… — összesített (aggregate) riportok címzettje
- ruf=mailto:… — részletes (forensic) riportok címzettje, ritkán támogatott
- adkim= és aspf= — szigorú (s) vagy laza (r) illesztés a DKIM/SPF-hez
Hogyan lépj none-ból reject-be úgy, hogy a cold email küldés ne törjön meg
A biztonságos átállás első lépése minimum két-négy hét megfigyelés p=none mellett, amíg a rua riportokból kirajzolódik, mely IP-k és rendszerek küldenek a domain nevében, és melyik nem illeszkedik az SPF/DKIM-hez. Cold email eszközöknél (pl. Instantly, Lemlist, vagy az LDM saját küldő infrastruktúrája) ez az a pont, ahol kiderül, ha a DKIM aláírás vagy az SPF include hiányzik egy alküldőnél.
Ezután a pct paraméterrel érdemes fokozatosan bevezetni a szigorúbb módot: elsőnek p=quarantine; pct=10, majd a hibaarány stabilizálódása után pct=25, pct=50, végül pct=100. Csak ha a quarantine fázis több hétig stabil, érdemes p=reject-re váltani, és ott is ugyanígy fokozatosan.
Cold email küldéshez erősen ajánlott külön subdomaint használni (pl. outreach.cegdomain.hu) a root domain helyett. Így a root domain akár azonnal mehet p=reject-re a phishing védelem miatt, míg a cold email subdomain saját, lazább policy alatt melegedhet be és bővülhet, amíg a metrikák nem indokolják a szigorítást.
az arányok tájékoztató jellegűek, célzott B2B cold email kampányok gyakorlatából származnak, domainenként eltérhetnek
Milyen alignment arányokra számíthatsz küldő forrásonként
Mielőtt bármelyik domain p=reject-re vált, érdemes forrásonként megnézni az alignment pass rátát a rua riportokban. A tapasztalat szerint a fő céges levelezés (Google Workspace vagy Microsoft 365 natívan) szinte mindig magas arányban illeszkedik, míg a harmadik féltől bérelt eszközök gyakran maradnak le, ha nincs pontosan beállítva az SPF include és a DKIM selector.
Ez az egyik leggyakoribb ok, amiért egy cold email kampány deliverability-je hirtelen romlik, miután a marketing csapat a fő domainen bevezeti a reject policy-t anélkül, hogy egyeztetett volna a sales/outreach csapattal.
az arányok tájékoztató jellegűek, célzott B2B cold email kampányok gyakorlatából származnak
Gyakori hibák a DMARC policy beállításánál
A leggyakoribb hiba az, hogy a cég egyből p=reject-et állít be minden monitorozás nélkül, mert egy biztonsági audit ezt írta elő. Ez papíron rendben van, a gyakorlatban viszont blokkolja a saját, legitim leveleit is, ha bármelyik küldő forrás alignment-je hiányos.
- Egyből p=reject bevezetése rua riportok elemzése nélkül
- A cold email subdomain elhagyása — a root domain szigorítása véletlenül elviszi az outreach leveleket is
- Harmadik féltől bérelt eszközök (CRM autoresponder, naptárfoglaló, e-aláírás szolgáltatás) kihagyása a SPF/DKIM leltárból
- Szintaxis hiba a rekordban — pl. hiányzó pontosvessző vagy rossz idézőjel, ami miatt a rekord érvénytelen és a domain valójában dmarc policy not enabled állapotban marad
- A rua riportok címzettjének soha nem ellenőrzése, így a hibák hetekig észrevétlenek maradnak
Checklist: hogyan kezeli az LDM a DMARC policy-t targeted B2B kampányokban
Az LDM minden ügyfél cold email kampányát dedikált küldő subdomainen indítja, amit a fő céges domaintől függetlenül lehet melegíteni és monitorozni, így a root domain DMARC policy-ja szabadon szigoríthat anélkül, hogy az outreach leveleket veszélyeztetné.
Mielőtt bármelyik domainen javasoljuk a p=reject-re váltást, minimum két-három hetes rua riport adatot nézünk át, hogy minden forrás alignment aránya stabil legyen — ez a targeted B2B megközelítés lényege: nem a tömeges kiküldés mennyiségét, hanem a domain hitelesség minőségét optimalizáljuk.
- Külön subdomain a cold email küldéshez, elkülönítve a fő céges levelezéstől
- Minimum 2-4 hét p=none megfigyelés induláskor
- Fokozatos pct emelés quarantine, majd reject felé
- Rua riportok heti szintű átnézése minden aktív kampánynál
- Minden harmadik fél küldő forrás SPF include és DKIM selector ellenőrzése policy váltás előtt
Gyakori kérdések
Mit jelent, ha a domainem dmarc policy not enabled státuszú?
Ez azt jelenti, hogy nincs érvényes DMARC rekordod, vagy p=none van beállítva. Utóbbi esetben van rekord, de az csak megfigyel, nem utasítja a fogadó szervert semmire hibás levél esetén.
Mikor érdemes p=quarantine helyett p=reject-et használni?
Akkor, ha a rua riportok alapján minden legitim küldő forrásod — cold email eszköz, ESP, tranzakciós levelező — hetekig stabilan magas arányban illeszkedik az SPF/DKIM-hez. Reject nélkül ezen adatok nélkül kockázatos.
Hogyan ellenőrizhetem a saját domainem DMARC policy syntax-át?
Egy egyszerű dig vagy nslookup lekérdezéssel a _dmarc.dominenem.hu TXT rekordra megnézheted a nyers szöveget, és ellenőrizheted, hogy a v=DMARC1 tag, a p= érték és a rua cím helyesen, pontosvesszőkkel elválasztva szerepel-e.
Árt-e a cold email deliverability-nek, ha a root domainen reject policy van?
Csak akkor, ha a cold email leveleket ugyanarról a root domainről küldöd, és az alignment nem stabil. Külön subdomain használatával ez a kockázat gyakorlatilag megszűnik.
Kell-e külön DMARC policy a cold email subdomainhez?
Igen, érdemes. Az sp= taggel a root domain rekordjában külön policy adható meg az alldomainekre, így a fő domain szigoríthat, miközben a cold email subdomain saját ütemben melegedhet be.
Mennyi ideig tartson a p=none megfigyelési szakasz?
Gyakorlatban két-négy hét elegendő ahhoz, hogy minden rendszeres küldő forrás legalább egyszer megjelenjen a rua riportokban, és látszódjon, hol van alignment hiba.
Alkalmazná ezt a saját outreach-folyamatában?
A munka megkezdése előtt megmutatjuk, hogyan működik ez az Ön szegmensénél és termékénél.
Beszéljünk