Így olvasd ki a DMARC aggregate riportokat percek alatt

Ha célzott B2B hideg leveleket küldesz saját domainről, a DMARC riportok az egyetlen visszajelzés arról, hogy valaki visszaél-e a domained nevével, vagy a saját küldő infrastruktúrád rosszul van beállítva. A gond az, hogy ezek nyers XML fájlokban érkeznek, amit kézzel szinte lehetetlen áttekinteni. Ebben a cikkben megmutatjuk, mit tartalmaz egy ilyen riport, hogyan válassz megfelelő dmarc report tool-t, és milyen arányok számítanak egészségesnek.

Miért kell egyáltalán DMARC riportokat olvasni cold B2B küldőknél

Ha B2B célzott hideg leveleket küldesz saját domainedről vagy egy aldomainről, a DMARC aggregate riportok az egyetlen visszajelzési csatorna arról, hogy a fogadó levelezőszerverek (Google, Microsoft, Yahoo) mit látnak a domained nevében kiküldött levelekből. A probléma az, hogy ezek a riportok nyers XML fájlokban érkeznek, naponta több tucat, gzip-be csomagolva — kézzel gyakorlatilag olvashatatlanok.

Egy jó dmarc report viewer pontosan ezt oldja meg: összegyűjti a beérkező XML fájlokat, IP-cím és küldő szerint csoportosítja őket, és emberi nyelven mutatja meg, melyik levél ment át SPF/DKIM ellenőrzésen, és melyik nem. Ez különösen fontos, ha több csatornán küldesz — saját SMTP, ESP, CRM-plugin —, mert bármelyik rosszul beállított komponens rontja a domain hírnevét, még akkor is, ha a tartalom teljesen legitim, célzott megkeresés.

Mi van egy DMARC aggregate riport belsejében

A DMARC aggregate riport (RUA) egy XML dokumentum, amit a fogadó szerver a policy_published blokkal kezd — ez mutatja, milyen DMARC szabályt (p=none, quarantine vagy reject) publikáltál a DNS-ben. Utána record blokkok következnek: soronként egy forrás IP-cím, hányszor küldött onnan levelet a domained nevében, a fogadó döntése (disposition: none, quarantine vagy reject), valamint hogy az adott levél átment-e a SPF és DKIM ellenőrzésen, és melyik domainhez volt igazítva (alignment).

Egy dmarc report parser feladata ennek a struktúrának a kibontása és olvasható táblázattá alakítása. Enélkül minden egyes riportot manuálisan kellene megnyitni és a nyers XML tageket böngészni, ami napi szinten, több küldő domain mellett gyorsan kezelhetetlenné válik.

Hogyan olvasd ki gyorsan — eszközválasztás lépésről lépésre

A gyakorlatban négy lépésben érdemes felépíteni a riport-olvasási folyamatot, függetlenül attól, hogy egy vagy több domaint futtatsz célzott B2B kampányokhoz.

A cél nem az, hogy minden egyes sort végigolvass, hanem hogy gyorsan kiszűrd azokat az IP-ket, amik nem szerepelnek az ismert küldő infrastruktúrád listáján, de mégis a domained nevében küldenek.

• Állíts be egy dedikált postafiókot a DMARC DNS rekord rua= címéhez, amit kizárólag riportok fogadására használsz.
• Válassz egy dmarc report tool-t, ami automatikusan letölti, kicsomagolja és forrás IP szerint összesíti a bejövő XML fájlokat.
• Egyszeri, alacsony volumenű ellenőrzéshez elég egy ingyenes dmarc report reader vagy egy dmarcian xml reader jellegű eszköz — csak töltsd fel a gzip fájlt, és táblázatban látod az eredményt.
• Rendszeres, több domain feletti felügyelethez válassz olyan platformot, ami heti-havi trendeket is mutat, nem csak egyetlen napi riportot.

Mit jelentenek a számok — egészséges arányok célzott B2B küldésnél

A gyakorlatban egy jól karbantartott küldő domainnél a riportsorok túlnyomó többsége a saját infrastruktúrádból származik, és SPF/DKIM alignment mellett pass státuszú. Az alábbi arányok tájékoztató jellegűek, célzott B2B kampányokat futtató domainek gyakorlati tapasztalata alapján.

Ha az ismeretlen forrás aránya tartósan 10-15% fölé megy, érdemes megvizsgálni, hogy valódi visszaélésről (domain spoofing) van-e szó, vagy egyszerűen egy elfelejtett, de legitim küldő rendszerről — például egy régi marketing eszközről vagy egy alvállalkozó CRM-jéről —, amit még nem vettél fel az SPF rekordba.

Tipikus hibák DMARC riportok elemzésénél

A legtöbb kezdő hiba nem a technikai olvasásban van, hanem az adatok félreértelmezésében.

• Minden fail disposition-t támadásnak tekinteni, miközben gyakran csak egy nem igazított, de legitim ESP-ről van szó, amit el kell adnod SPF-be vagy DKIM-be.
• Csak a fő domaint figyelni, az aldomaineket — például mail.cegneved.hu — nem, pedig a DMARC riportok subdomain policy szerint is generálódnak.
• Egyszer beállítani a rua= címet, majd hónapokig nem megnyitni a beérkezett riportokat.
• Elfelejteni, hogy a levéltovábbítás — mailing lista, egyes CRM-integrációk — legitim módon is megbukhat SPF-en; ilyenkor a DKIM alignment a döntő, nem a SPF.
• p=reject-re váltani úgy, hogy előtte nem néztek át legalább 2-4 hét riport adatot p=none vagy p=quarantine mellett.

Checklist — hogyan csinálja ezt az LDM

Az LDM gyakorlatában a domain-alapú célzott B2B küldésnél a DMARC riportok olvasása nem egyszeri audit, hanem visszatérő rutin — hiszen minden új küldő alcím, például egy subdomain rotáció, új forrás IP-ket visz be a riportokba.

Ez a rutin nem a spamszűrők kijátszásáról szól, hanem arról, hogy a valóban legitim, személyre szabott megkeresések ne akadjanak fenn azért, mert valaki más visszaél a domained nevével, vagy mert egy saját rendszered nincs megfelelően igazítva.

• Heti rendszerességgel átnézzük az aggregált riportokat, nem csak akkor, ha probléma jelentkezik.
• p=none módban indítunk minden új küldő domaint, és csak akkor lépünk quarantine-ra, ha a riportok 2-4 héten át stabil, tiszta képet mutatnak.
• Minden ismeretlen forrás IP-t vagy azonosítunk és felveszünk SPF-be, vagy jelentjük, ha valódi visszaélés gyanúja merül fel.
• A riport-elemzést összekötjük a válaszarány és a spam-panasz metrikákkal, mert a domain-hírnév és a kézbesíthetőség együtt mozog.

Gyakori kérdések