Live Direct Marketing
Kezdőlap → Blog → Kézbesíthetőség

Hogyan validáld az SPF, DKIM és DMARC rekordokat, mielőtt élesítesz egy küldő domaint

2026. július 12. · 8 perc olvasás · Útmutató: Kézbesíthetőség

Egy új küldő domain aktiválása előtt szinte mindig kiderül, hogy az SPF, DKIM vagy DMARC rekord hiányzik, hibás szintaxisú, vagy ütközik egy másik bejegyzéssel. Ez az útmutató megmutatja, hogyan ellenőrizd ezeket a DNS rekordokat parancssorból és a regisztrátorod (pl. GoDaddy) felületén, mielőtt az első cold email kimegy. A cél nem a spamszűrők kijátszása, hanem hogy a leveled ugyanúgy nézzen ki a fogadó szerver szemében, mint bármely legitim céges üzenet.

Röviden
  • SPF, DKIM és DMARC nélkül a fogadó szerverek gyanúsnak tekintik a domaint, függetlenül a levél tartalmától
  • A dig vagy nslookup parancsok másodpercek alatt megmutatják, hogy egy rekord létezik-e és szintaktikailag helyes-e
  • GoDaddy-n és más regisztrátoroknál a leggyakoribb hiba a duplikált SPF rekord vagy a rossz DKIM selector
  • A DMARC policy-t fokozatosan (p=none, majd quarantine, majd reject) érdemes szigorítani, nem azonnal reject-tel indulni
  • Új domain esetén a rekordok ellenőrzése az első lépés, a warm-up csak utána következhet

Miért nem indulhat cold outreach domain-hitelesítés nélkül

Amikor egy céges csapat új domaint vagy aldomaint állít be kifejezetten a cold email kampányokhoz (például mail.cegnev.hu formában, hogy a fő domain reputációja védve maradjon), a levélkiszolgálók – a Gmail, a Microsoft 365 és a hazai levelezőrendszerek egyaránt – az első pillanattól kezdve ellenőrzik, hogy a küldő szerver valóban jogosult-e az adott domain nevében levelet küldeni. Ezt a jogosultságot az SPF, a DKIM és a DMARC rekordok bizonyítják a DNS-ben.

Ha ezek a rekordok hiányoznak vagy hibásak, a levél nem feltétlenül landol azonnal a spam mappában – gyakran csak alacsonyabb reputációs pontszámot kap, ami a promóciók fülre vagy a kevésbé látható tartományba tereli. Cold outreach esetén ez különösen fájó, mert a válaszarány gyakorlatilag nullára esik, ha a címzett meg sem nyitja a levelet.

Ezért mielőtt bármilyen kampányt indítanál egy új domainről, a domain SPF/DKIM/DMARC ellenőrzése az első technikai lépés – nem opció, hanem előfeltétel.

Lépésről lépésre: SPF, DKIM és DMARC rekordok ellenőrzése DNS-ben

Az SPF, DKIM és DMARC rekordok ellenőrzésének legmegbízhatóbb módja a parancssor, mert az mindig a valós, publikus DNS-t kérdezi le – nem a regisztrátor felületén cache-elt nézetet.

A GoDaddy-n és más regisztrátoroknál (pl. hazai szolgáltatóknál is) a DNS Management vagy Domains > DNS menüpont alatt lehet közvetlenül szerkeszteni a TXT rekordokat, de a mentés után mindig érdemes parancssorból is visszaellenőrizni, mert a propagáció (a rekord globális terjedése) néhány perctől akár néhány óráig is tarthat.

Mit jelentenek a helyes értékek – kritériumok és tartományok

A rekordok puszta létezése nem elég – a tartalmuknak is helyesnek kell lennie. Az SPF rekordban a záró mechanizmus (~all vagy -all) azt jelzi, mennyire szigorúan kezelje a fogadó szerver az illetéktelen küldést; cold outreach domainnél a ~all (soft fail) ajánlott az elején, mert egy elgépelt include miatt nem akarod, hogy a saját leveleid is elutasításra kerüljenek.

A DKIM esetében a kulcshossz (2048 bit ajánlott, ne 1024) és a selector egyedisége számít – ha ugyanazt a selectort több szolgáltatás is használja, a rekord felülíródhat. A DMARC policy fokozatos szigorítása (p=none → p=quarantine → p=reject) lehetővé teszi, hogy a rua jelentésekből lásd, mennyi legitim levél bukna el egy szigorúbb policy mellett, mielőtt ténylegesen bevezeted.

Az alábbi ábra azt mutatja, hogyan változik a beérkező postafiókba jutás valószínűsége a hitelesítési szint teljességétől függően, tapasztalati B2B kampányadatok alapján.

Tipikus hibák GoDaddy-n és más regisztrátoroknál

A legtöbb hiba nem az elmélet hiányából, hanem apró technikai félrelépésekből fakad – ezek szinte mindig kiderülnek, amint futtatod a dig parancsot.

Egy gyakori eset: a cég korábban már használt egy másik levélküldő szolgáltatást a domainhez, és annak SPF include-ja bent maradt a rekordban egy új szolgáltatás bevezetése után is. Két külön SPF TXT rekord esetén a DNS szabvány szerint egyik sem érvényes – ezeket egyetlen sorba kell egyesíteni, egyetlen v=spf1 kezdettel.

Checklist és hogyan kezeli ezt az LDM

Az LDM-nél minden új küldő domaint ugyanazzal a checklist-tel futtatunk végig, mielőtt egyetlen cold email is kimegy róla: SPF egyediségének és szintaxisának ellenőrzése, DKIM selector és kulcshossz validálása, DMARC rekord jelenléte legalább p=none policy-val és aktív rua jelentéssel. Csak ezután kezdődik a domain warm-up, ami fokozatosan növeli a napi küldési volument, hogy a levélkiszolgálók megbízható küldőként ismerjék meg.

Egy konkrét példa: egy hazai IT-szolgáltató cég (nevezzük Nagy Solutions Kft.-nek) új aldomaint vezetett be a cold outreach csapatának, mail.nagysolutions.hu néven. Az első dig lekérdezés kiderítette, hogy a DKIM rekord hiányzott – a levélküldő platform ugyan generálta a kulcsot, de a TXT rekord soha nem került be a GoDaddy DNS-be. A hiba pótlása után, 24 órás propagációs idő és fokozatos warm-up után a domain elérte a stabil, magas postafiók-elhelyezési arányt.

Gyakori kérdések

Mennyi idő alatt terjed el egy új DNS rekord GoDaddy-n?

A legtöbb esetben 15–60 percen belül látható a világ nagy részén, de a TTL beállítástól függően akár 24 óráig is eltarthat, amíg minden szerver frissíti a cache-ét. Ezért érdemes a rekord mentése után várni, majd csak azután dig-elni és kampányt indítani.

Kell-e DMARC rekord, ha csak napi néhány tucat cold email megy ki?

Igen, a küldött mennyiségtől függetlenül érdemes beállítani, mert a fogadó szerverek reputációs döntéseinél a hitelesítés megléte számít, nem a volumen. Alacsony volumen mellett is p=none policy-val, jelentéssel érdemes kezdeni.

Miért nem működik a DKIM, ha a rekord létezik a DNS-ben?

Leggyakrabban a selector nem egyezik meg a levélküldő platform tényleges beállításával, vagy a nyilvános kulcs formátuma sérült mentés közben (pl. idézőjelek vagy sortörés). Egy egyszerű dig txt selector._domainkey.domain lekérdezéssel gyorsan kiderül, hogy a rekord tartalma megegyezik-e a platform által elvárttal.

Mi történik, ha két SPF rekordot hagyok egy domainen?

A DNS szabvány szerint egyetlen SPF (v=spf1) TXT rekord lehet érvényes domainenként; ha kettő van, a fogadó szerverek gyakran egyiket sem fogadják el érvényesnek, ami PermError-t eredményez. A megoldás mindig az összes include egyetlen sorba való egyesítése.

Elég a p=none DMARC policy induláskor?

Igen, ez a biztonságos kezdőpont, mert csak megfigyel és jelentést küld, anélkül hogy bármilyen legitim levelet elutasítana. A policy-t csak akkor érdemes quarantine-re vagy reject-re szigorítani, ha a jelentésekből látszik, hogy minden legitim küldő forrás megfelelően hitelesített.

Használhatok ugyanolyan DKIM selectort több küldő domainhez?

Technikailag lehetséges, de nem ajánlott, mert egy selector rotáció vagy visszavonás minden domaint egyszerre érint. Célzott B2B kampányoknál domainenként külön selectort érdemes generálni a jobb kontroll érdekében.

Fontos: ez nem tömeges levélküldés és nem spam. Célzottan dolgozunk: minden üzenet egy konkrét cég konkrét képviselőjének kerül kiküldésre, jogos üzleti okból, kis napi mennyiségben, a címzettre szabva. Minden e-mail feltünteti a feladót és egykattintásos leiratkozást tartalmaz; a leiratkozások és tiltólisták kivétel nélkül érvényesek minden későbbi kampányra.

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

További anyagok a témában: Kézbesíthetőség