Így állítsd be az SPF-et, DKIM-et és DMARC-ot Google Workspace-ben cold emailhez
Ha egy gondosan personalizált cold email a spam mappában landol, a legjobb célzás is kárba vész. Ez a cikk lépésről lépésre végigvezet az SPF, DKIM és DMARC beállításán Gmailben és Google Workspace-ben, hogy a küldő domained hitelesnek számítson a fogadó szerverek szemében, mielőtt elindítasz egy célzott B2B kampányt.
- Az SPF, DKIM és DMARC együtt igazolja a fogadó szervernek, hogy a leveled valóban a domainedtől jött.
- A DMARC-ot mindig p=none monitorozással kezdd, csak utána szigorítsd quarantine-ra vagy reject-re.
- Egy rossz SPF rekord (kettő is a domainen) gyakoribb hiba, mint a hiányzó DKIM.
- Az egészséges célzott B2B cold email válaszarány 3-8% - hitelesítés nélkül ez a szám gyakorlatilag nullára esik, mert a levelek be sem érnek.
- A Google Postmaster Tools és egy google spf dkim dmarc checker eszköz segít ellenőrizni, mielőtt élesben elindítod a kampányt.
Miért kritikus az SPF/DKIM/DMARC egy célzott B2B kampányban
A célzott B2B cold email lényege, hogy egy konkrét döntéshozónak írsz egy konkrét cégnél - nem egy vásárolt listát öntesz ki tömegesen. Ha viszont a fogadó domain hitelesítetlennek látja a küldő domained, a gondosan megírt, személyre szabott levél ugyanúgy a spam mappában végezheti, mint egy tömeges hírlevél. Az SPF, DKIM és DMARC nem a szűrők átverésére szolgál - éppen ellenkezőleg, ezek azok a jelzések, amik igazolják, hogy a levél valóban attól a cégtől jött, akitől állítja.
Aki rákeres arra, hogyan kell set up spf dkim and dmarc gmail, tipikusan azért teszi, mert már megtapasztalta a problémát: a válaszarány hirtelen a töredékére esett, vagy a Google Postmaster Tools piros sávot mutat a domain reputációjánál. A Google és a Yahoo szigorúbb elvárásokat vezetett be minden olyan feladóval szemben, aki naponta több tucat levelet küld egy domainről - ez gyakorlatilag minden aktív B2B kampányra igaz, még akkor is, ha napi 20-30 levélről beszélünk, nem tömeges kiküldésről.
SPF rekord beállítása Google Workspace-ben
Az SPF (Sender Policy Framework) egy DNS TXT rekord, ami felsorolja, mely szerverek jogosultak leveleket küldeni a domained nevében. Google Workspace esetén ez azt jelenti, hogy a domain-szolgáltatód admin felületén hozzáadsz egy TXT rekordot a gyökér domainhez.
- Gyűjtsd össze az összes küldő rendszert: Google Workspace, az esetleges cold email eszköz, a marketing automatizáció, ha van.
- Lépj be a DNS-kezelő felületre, és keresd meg a TXT rekordok szekciót a domain gyökerénél.
- Add hozzá: v=spf1 include:_spf.google.com ~all - ha más eszköz is küld a nevedben, azt is fel kell venni include-ként ugyanabba az egy sorba.
- Csak egyetlen SPF rekord lehet domainenként - ha kettő van, egyik szolgáltató sem fog átmenni az ellenőrzésen.
- Figyelj a 10 DNS-lookup limitre: minden include egy lookupot jelent, ennél többől az SPF érvénytelenné válik.
Egy fiktív B2B cég, a Pannon Gépipari Kft. (pannongepipari.hu) esetén, ha csak Google Workspace-ből és az LDM küldő infrastruktúrájából megy ki levél, a rekord így néz ki: v=spf1 include:_spf.google.com include:_spf.ldm-platform.hu ~all - tesztidőszakban ~all (soft fail), utána -all (hard fail).
DKIM aktiválása a Google Admin konzolban
A DKIM (DomainKeys Identified Mail) egy titkosítási aláírás, amit a Google Workspace minden kimenő levélhez hozzáad, és amit a fogadó szerver a DNS-ben publikált nyilvános kulccsal ellenőriz. Ellentétben az SPF-fel, ez nem a küldő szervert, hanem magát a levél tartalmát hitelesíti - ha bárki módosítja a levelet továbbítás közben, az aláírás érvénytelenné válik.
- Admin console (admin.google.com) > Apps > Google Workspace > Gmail > Authenticate email.
- Válaszd ki a domained, és kattints a Generate new record gombra - 2048 bites kulcsot válassz, ha a DNS-szolgáltatód támogatja.
- Másold be a kapott TXT rekordot a DNS-be a megadott selector néven, például google._domainkey.pannongepipari.hu.
- Várj 24-48 órát a propagációra, majd térj vissza az Admin konzolba, és kattints a Start authentication gombra.
DMARC beállítása és a fokozatos szigorítás
A DMARC (Domain-based Message Authentication, Reporting and Conformance) az SPF és a DKIM tetejére épül: megmondja a fogadó szervernek, mit tegyen, ha egy levél nem megy át az ellenőrzésen, és emellett napi riportokat küld arról, ki próbál a domained nevében levelet küldeni. A rekordot a _dmarc.domained.hu néven kell publikálni, TXT típusként.
Sose kezdd p=reject-tel. Az első 2-4 hétben állítsd p=none-ra, és figyeld a rua címre érkező aggregált riportokat - ezek megmutatják, ha egy régóta használt eszköz nem megy át az igazításon. Csak ezután lépj p=quarantine, majd p=reject szintre, lehetőleg pct paraméterrel fokozatosan növelve a lefedettséget.
- v=DMARC1; p=none; rua=mailto:dmarc-reports@domained.hu; pct=100 - kezdő rekord, csak megfigyelés.
- v=DMARC1; p=quarantine; pct=25; rua=... - 2-4 hét után, ha a riportok tiszták.
- v=DMARC1; p=reject; rua=... - végállapot, amikor minden küldő forrás igazoltan átmegy.
A számok tájékoztató jellegűek, célzott B2B kampányok gyakorlatából származnak.
Ellenőrzés és mérhető hatás a kézbesítésre
Miután beállítottad a rekordokat, ne higgy vakon a DNS-nek - ellenőrizd ténylegesen. Egy gyors dig TXT paranccsal (dig TXT domained.hu, dig TXT _dmarc.domained.hu) megnézheted, hogy a rekordok tényleg élnek-e. Emellett érdemes egy google spf dkim dmarc checker típusú online eszközt is használni, mert ezek egyszerre validálják mind a hármat, és jelzik a szintaktikai hibákat.
A legmegbízhatóbb teszt, ha küldesz egy próba levelet egy mail-tester.com jellegű szolgáltatásnak, és megnézed a fejlécben (Authentication-Results) az spf=pass, dkim=pass, dmarc=pass sorokat. Ha bármelyik fail vagy none státuszt mutat, azt a kampány indítása előtt javítani kell - ne élesben derüljön ki.
A számok jellemző tartományok célzott B2B kampányokból, nem konkrét mérési garanciák.
Egy jól beállított domainnél a fejlécben ez látszik: Authentication-Results: mx.google.com; spf=pass smtp.mailfrom=pannongepipari.hu; dkim=pass header.i=@pannongepipari.hu; dmarc=pass header.from=pannongepipari.hu.
Gyakori hibák, amik semlegesítik a hitelesítést
A DNS rekordok elkészítése önmagában nem elég - a leggyakoribb hibák a beállítás után derülnek ki, amikor a domain reputációja mégis romlik.
- Két SPF rekord a domainen - csak egy TXT SPF rekord lehet, kettő esetén egyik szolgáltató sem validál.
- A marketing vagy CRM aldomain kimarad a DKIM/SPF beállításból, miközben onnan is mennek levelek.
- A From domain nem egyezik az SPF/DKIM domainjével - ez DMARC szempontból bukás, még ha az SPF technikailag átmegy is.
- Egyből p=reject-re állítják a DMARC-ot monitorozás nélkül, és egy elfelejtett integráció miatt hetekig eltűnnek a legális levelek is.
- Senki nem nézi a DMARC aggregált riportokat - pedig ezek jelzik, ha valaki más próbál a domain nevében küldeni.
- Új domain azonnal nagy volumennel indul hitelesítés és warmup nélkül - ez még tökéletes SPF/DKIM/DMARC mellett is reputációs problémát okoz.
Checklist és hogyan kezeli ezt az LDM
Mielőtt elindítasz egy célzott B2B kampányt, fusd végig ezt a listát: SPF egyetlen, helyes rekord; DKIM aktiválva és authenticating státuszban; DMARC legalább p=none szinten riportokkal; a riportok 1-2 hete tiszták; a küldő domain nem vadonatúj, van rajta pár hetes szervezett forgalom.
Az LDM platformon ez a folyamat be van építve a kampányindításba: minden ügyfél domainjét ellenőrizzük SPF/DKIM/DMARC szempontból az első kampány előtt, dedikált küldő aldomaint javaslunk a fő céges domain védelmére, és a DMARC riportokat folyamatosan figyeljük, hogy a célzott, kis volumenű, személyre szabott kiküldés végig a beérkező levelek közt maradjon, ne a spam mappában.
Gyakori kérdések
Mennyi idő alatt lép életbe egy új SPF, DKIM vagy DMARC rekord?
A DNS-propagáció jellemzően néhány órán belül lezajlik, de biztonságosan 24-48 órát érdemes rá szánni, mielőtt a Google Admin konzolban elindítod a DKIM authentikációt vagy szigorítod a DMARC policy-t.
Kell-e külön DKIM/SPF rekord az aldomainekre?
Igen, ha egy aldomainről is mennek levelek, azt külön kell hitelesíteni - az SPF és a DKIM nem öröklődik automatikusan a fő domainről az aldomainre.
Mi a különbség p=none, p=quarantine és p=reject között?
A p=none csak megfigyel és riportot küld, nem blokkol semmit; a p=quarantine a nem hitelesített leveleket spam mappába teszi; a p=reject teljesen elutasítja őket - ezért csak akkor váltasz reject-re, ha a riportok szerint minden legális forrás átmegy az igazításon.
Legális-e a cold email B2B kontextusban Magyarországon?
Igen, a GDPR jogos érdek (legitimate interest) jogalapon lehetővé teszi a célzott B2B megkeresést cégek felé, feltéve, hogy releváns az üzleti kapcsolat és van egyértelmű leiratkozási lehetőség - érdemes a NAIH ajánlásait is átnézni, ha bizonytalan vagy.
Mit jelent, ha a DMARC riportban ismeretlen IP-címeket látok?
Ez azt jelenti, hogy valaki, vagy egy elfelejtett integráció, a domained nevében próbál levelet küldeni anélkül, hogy az SPF-ben szerepelne - ilyenkor vagy hozzáadod a legitim forrást az SPF-hez, vagy ha nem ismered fel, domain spoofing gyanúja áll fenn, amit érdemes kivizsgálni.
Számít-e, hogy Google Workspace-t vagy más levelezőrendszert, például Exchange Online-t használok?
A logika ugyanaz - SPF, DKIM, DMARC mindhárom rendszernél DNS TXT rekordokon alapul -, csak a DKIM-kulcs generálásának felülete más: Google Workspace-ben az Admin konzolban, Exchange Online-ban a Microsoft 365 Defender portálon éred el.
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