Hogyan állíts be helyes DMARC rekordot cold email küldéshez

Egyetlen rosszul beállított vagy hiányzó DMARC record elég ahhoz, hogy egy támadó a te domainedről küldjön hamisított levelet egy célzott partnernek — és onnantól a te domained reputációja bánja. Ez a cikk megmutatja, hogyan épül fel a DMARC record szintaxisa, hogyan hozz létre egy működő rekordot lépésről lépésre, és hogyan ellenőrizd egy dmarc record checker segítségével, hogy tényleg él-e.

Miért kell DMARC record minden cold email domainre

Az SPF és a DKIM önmagában nem véd meg attól, hogy valaki a te domainedről küldjön hamisított levelet — ezek csak azt igazolják, hogy egy adott kiszolgáló jogosult-e küldeni, illetve hogy a levél tartalma nem módosult útközben. A DMARC record az, ami összeköti a kettőt, és megmondja a fogadó levelezőszervernek: ha egy levél nem megy át az SPF vagy a DKIM ellenőrzésen és nincs alignmentben a feladó domainnel, mit tegyen vele — engedje át, karanténba tegye, vagy dobja el.

Célzott B2B cold email kampányoknál ez különösen fontos, mert a küldött volumen kicsi, minden levél egy konkrét céghez és egy konkrét kapcsolattartóhoz szól. Ha valaki ellopja vagy meghamisítja a domained, és azon keresztül próbál csalárd leveleket küldeni egy leendő ügyfélnek, az a bizalmat egy csapásra tönkreteszi — és a domain reputációja is zuhan, ami a valódi kampányaidat is magával rántja.

A DMARC record szintaxisa: mit jelentenek a tagek

A DMARC record syntax egy egyszerű, pontosvesszővel tagolt kulcs-érték lista, amit a domain _dmarc alnevén, TXT rekordként kell publikálni a DNS-ben. A fogadó szerverek ezt olvassák ki, amikor egy tőled érkező levelet ellenőriznek.

A legfontosabb tagek, amiket ismerned kell egy dmarc record setup során:

• v=DMARC1 — kötelező, jelzi hogy ez egy DMARC rekord
• p=none/quarantine/reject — a policy, ami megmondja mi történjen a hibás levelekkel
• rua=mailto:... — hova küldje a fogadó szerver az összesített (aggregate) napi riportokat
• ruf=mailto:... — hova küldje a forensic riportokat egy-egy konkrét elbukott levélről
• pct=100 — a policy hány százalékos arányban érvényesüljön (fokozatos bevezetéshez hasznos)
• adkim=s/r és aspf=s/r — szigorú vagy laza alignment mód DKIM-hez és SPF-hez
• sp=... — külön policy az aldomainekre

DMARC record setup lépésről lépésre

A DMARC record setup csak azután van értelme, ha az SPF és a DKIM már helyesen működik a küldő domainen — a DMARC ezekre épül, nem helyettesíti őket.

• 1. Ellenőrizd, hogy az SPF rekord tartalmazza az összes ténylegesen küldő rendszert (LDM, CRM, számlázó, támogatási levelek)
• 2. Ellenőrizd, hogy a DKIM aláírás minden küldő rendszernél be van kapcsolva és érvényes
• 3. Publikálj egy induló DMARC rekordot p=none policy-vel, csak megfigyelés céljából
• 4. Adj meg egy rua= címet, ahova a napi aggregate riportok érkeznek
• 5. Publikáld TXT rekordként a _dmarc alnéven a DNS-szolgáltatódnál
• 6. 1-2 hét riport után nézd meg, mely rendszerek buknak el az alignmenten, és javítsd ezeket
• 7. Csak ezután emeld a policy-t p=quarantine, majd végül p=reject szintre

Policy fokozatok és a leggyakoribb hibák

A legtöbb domain, amely most vezet be DMARC-ot, három fokozaton megy végig: megfigyelés, karantén, majd elutasítás. A gyakorlatban azt látjuk, hogy a cégek jelentős része hónapokig marad p=none szinten — ez önmagában nem hiba, csak akkor probléma, ha soha nem lép tovább, mert így a DMARC csak riportot gyűjt, de nem véd semmit.

A legdrágább hiba a túl gyors ugrás p=reject szintre a riportok elemzése nélkül. Ha egy legitim küldő rendszer — például a cold email platformod vagy egy marketing automatizációs eszköz — nincs benne az SPF-ben vagy nem alignmentben küldi a DKIM-et, akkor a saját, valódi leveleid is elutasításra kerülnek, nem csak a hamisítottak.

• p=reject bevezetése alignment-hibák javítása előtt — legitim levelek is elutasításra kerülnek
• sp= tag hiánya — az aldomainek védtelenek maradnak, miközben a fő domain már reject szinten van
• rua riportok elemzésének elhagyása — hetekig senki sem nézi meg, mi bukik el és miért
• strict alignment (adkim=s, aspf=s) beállítása, amikor a küldő rendszer subdomainről aláír — ez feleslegesen szigorú a legtöbb cold email setuphoz

DMARC record checker: hogyan ellenőrizd, hogy tényleg működik

A dmarc record check legegyszerűbb módja egy DNS lekérdezés a _dmarc alnévre — ez megmutatja, hogy a rekord egyáltalán publikálva van-e, és hogy a szintaxisa helyes-e. Emellett érdemes egy online dmarc record checker eszközt is használni, amely validálja a tageket és jelzi, ha valamelyik érték hibás vagy hiányzik.

A valódi visszajelzést azonban az aggregate (rua) riportok adják: ezek XML formátumban mutatják, mely küldő IP-k próbáltak a domain nevében levelet küldeni, és hogy átmentek-e az SPF/DKIM alignmenten. Ez az egyetlen módja annak, hogy lásd, mi történne, ha most azonnal p=reject-re váltanál — mielőtt ténylegesen megtennéd.

Checklist: hogyan állítja be az LDM a DMARC-ot ügyfeleknek

Célzott B2B cold email küldésnél a domain reputáció a legértékesebb eszközöd, ezért a DMARC beállítását sosem hagyjuk automatizmusra vagy egyszeri lépésre — folyamatosan monitorozzuk a riportokat, ahogy új küldő eszközök vagy aldomainek kerülnek be a rendszerbe.

• Dedikált küldő aldomain használata a cold email kampányokhoz, elkülönítve a fő céges levelezéstől
• SPF és DKIM ellenőrzése minden küldő rendszerre, mielőtt bármilyen DMARC policy élesedik
• Indulás p=none szinttel, minimum 2-3 hét megfigyeléssel és rua riport elemzéssel
• Fokozatos emelés pct= taggel, például 25%, majd 50%, majd 100% arányban p=quarantine alatt
• Csak validált, hibamentes riportok után váltás p=reject szintre
• Havi rendszerességű dmarc record check, hogy új küldő eszközök ne maradjanak ki az alignmentből

Gyakori kérdések