E-mailt küldeni (például egy marketing kampány során) tömeges méretben is egyszerű. De ha azt is szeretnénk, hogy a leveleink mind, biztosan célba is érjenek, ahhoz itt az ideje frissíteni az eddigi tudást – és tisztázni a biztonságra vonatkozó beállításokat, mivel éppen most változott a protokoll.

Kulcsszavak: DMARC

Mint minden fontos dologban az informatikában, itt is érkezzenek a 3-4 betűs szavak: DKIM, DMARC, SPF és BIMI.  Ezek közül most az újonnan bevezetett DMARC-ot vesszük górcső alá.

Ez is érdekelhet

Egy új szabvány, melyet a Google és a Yahoo dolgozott ki, 2024. február elsejétől ellenőrzést ír elő annak bizonyítására, hogy a fogadó oldalon megadott cím létezik. Hivatalosan ez úgy szól, hogy az eddig is széles körben alkalmazott  ESP és DKIM protokollokra építve, “a címzettek hitelesítési hibáinak kezelésére” szolgál. 

  • Ki érintett?

Mindenki, aki naponta 5000 vagy annál több üzenetet küld a Gmail vagy Yahoo Mail postafiók szolgáltatóinak valamelyikébe. Számukra előírás 2024. februártól, hogy a feladó e-mail domainjének DMARC házirenddel kell rendelkeznie a DNS-ben. Ezeknek az üzeneteknek át kell esni a DMARC ellenőrzésen, különben nem kézbesítődnek a levelek. Ez a protokoll magában foglalja a szervezet nevében az Ön e-mail tartományát használó harmadik fél e-mail szolgáltatói (ESP), például a Maileon, MailChimp, Salesforce stb. által küldött üzeneteket is.

Megjegyzés: Ha domainjét a Google Workspace-en is hosztolja, a belső üzenetmennyiség valószínűleg beleszámít ebbe a napi limitbe.

  • Miért vezették be?

A Google és a Yahoo lépésére azért volt szükség, mert a két cég – felismerve az e-mail fontosságát – szükségesnek látta, hogy lépéseket tegyen azok biztonságosabbá tétele érdekében.  Azzal, hogy az e-mail hitelesítésre összpontosítanak, segítenek megakadályozni például, hogy a nem kívánt spamek és a potenciális visszaélések eljussanak ügyfeleik postaládájába.

E-ker hírszemle

A DMARC-rendszerrel rendelkező domainről küldött emailek további előnye, hogy javítja a postaládákba való elhelyezést. A DMARC rekord segít az internetszolgáltatóknak azonosítani Önt, mint olyan feladót, aki komolyan veszi a bevett e-mail szabványok betartását, és csökkenti a spam-felelősségét. [A DMARC-ra vonatkozó általános kérdések és válaszok itt találhatók, aki pedig a további háttérre is kíváncsi, az itt lel fontos, hivatalos információkra.]

  • Mik a technikai követelmények?

Amennyiben a napi 5000 darab elektronikus levél kézbesítésre kerül az adott szolgáltatókhoz – vagy hamarosan potenciálisan van lehetőség ennek elérésére, például hírlevél feliratkozókat gyűjtünk  – , akkor az alábbiakat kell elvégeznünk:

A DNS-ben rendelkeznie kell DMARC-házirenddel. Bár a Google és a Yahoo számára elegendő a p=none felügyeleti módú házirend, ez csak az első lépés a biztonsági ellenőrzés teljes kihasználásához.

  • Először is ellenőrizzük a DMARC rekord meglétét DMARC ellenőrző segítségével.
  • Majdnem minden DMARC rekord p=none monitoros üzemmóddal indul. A varázslónk alapértelmezett beállítása ez az érték. Amennyiben ez megfelelő számunkra, akkor az alábbi rekordot vegyük fel a DNS-be: 
    • Típus: DMARC vagy TXT (szolgáltató függően)
    • Név: _dmarc.domain.hu
    • Adatok:  “v=DMARC1; p=none; sp=none”
  • A DMARC rekordot ezután közzé kell tenni a DNS-ben.
  • A DMARC-figyelés engedélyezése az első lépés, hogy betekintést nyerjünk abba, hogy vannak-e olyan e-mail források, amelyek nem felelnek meg a követelményeknek.
  • Amennyiben ennél mélyebbre szeretnénk menni, akkor használjunk egy DMARC rekord varázslót, hogy létrehozzunk egyet.

Ezeket az általános paramétereket kell tartalmaznia a DMARC rekordnak:

Mezők nevei Leírás Minta

v (kötelező)

 Protokoll verzió. Jelenleg a “DMARC1” érték az elfogadott, amennyiben ez hiányzik a DMARC rekord figyelmen kívül lesz hagyva. v=DMARC1

p (kötelező)

 Szabály a domain névre vonatkozóan. A megengedett értékek: „none”, „quarantine” vagy „reject”. 

Az alapértelmezett érték a „none”, amely nem lép fel a nem hitelesített e-mailekkel szemben. Ez csak a DMARC-jelentések összegyűjtésében segít, és betekintést nyerhet az aktuális e-mail-áramlásokba és azok hitelesítési állapotába. 

A „quarantine” a sikertelen e-maileket gyanúsnak jelöli, míg az „elutasítás” blokkolja azokat.

 p=quarantine

rua

 Aggregált jelentések küldése a megadott URI-re. 

Ez az a „mailto:” URI, amelyet az ESP-k a hibajelentések küldésére használnak. A címke opcionális, de ha kimarad, nem kapunk jelentéseket.

 rua=mailto:aggregmail@domain.hu

ruf

 Hivatalos jelentések küldése a megadott URI-re. 

Ez a „mailto:” URI, amelyet az ESP-k a hibajelentések küldésére használnak. A címke opcionális, de ha kimarad, nem kapunk jelentéseket.

 ruf=mailto:authfailmail@domain.hu

sp

 Szabály a domain név alatt létrehozott aldomain nevekre vonatkozóan.

Az aldomain örökli a fentebb ismertetett domain házirend taget (p=), kivéve, ha itt külön nem definiáljuk. A tartományi házirendhez hasonlóan a megengedett értékek a „none”, „quarantine” vagy „reject”. 

Ezt az opciót manapság nem használják széles körben.

 sp=reject

adkim

 Igazítási mód az DKIM rekordhoz.

Ez a címke követi a DKIM-tartomány és a szülő Header From tartomány közötti összehangolást. A megengedett értékek az „r” (laza) vagy az „s” (szigorú). 

Az „r” az alapértelmezett érték, amely lehetővé teszi a részleges egyezést, míg az „s” címke megköveteli, hogy a tartományok megegyezzenek.

 adkim=s

aspf

 Igazítási mód az SPF rekordhoz.

Ez a címke az SPF-tartomány (a feladó) és a Header From tartomány közötti összehangolást követi. A megengedett értékek az „r” (laza) vagy az „s” (szigorú). 

Az „r” az alapértelmezett érték, amely lehetővé teszi a részleges egyezést, míg az „s” címke megköveteli, hogy a tartományok pontosan megegyezzenek.

 aspf=r

fo

 Meghatározza a hibajelentési szabályt.

A megengedett értékek: „0”, „1”, „d” és „s”. 

A „0” az alapértelmezett érték, amely hivatalos jelentést generál, ha mind az SPF, mind a DKIM nem eredményez összehangolt passzust. Ha valamelyik protokoll eredménye nem passzol, használjuk az „1” értéket. 

A „d” jelentést generál, ha a DKIM érvénytelen, míg az „s” ugyanezt teszi az SPF esetében. 

Akkor definiáljuk a ruf címkét amennyiben a hivatalos jelentéseket meg akarjuk kapni.

 fo=0

rf

 A hibajelentések jelentési formátuma. 

A megengedett értékek az „afrf” és az „iodef”.

 rf=afrf

pct

 százalékos arány az üzenetek szűrésére vonatkozóan.

Ez a címke csak a „quarantine” vagy „reject” házirenddel rendelkező domaineken működik. 

A sikertelen e-mailek százalékos arányát jelöli, amelyre az adott házirendet alkalmazni kell. A többi egy alacsonyabb szintű házirend alá tartozik. Például, ha a „pct=70” egy „quarantine” házirenddel rendelkező tartományon, akkor csak az esetek 70%-ában alkalmazza. A fennmaradó 30% a „p=none” alá kerül. Hasonlóképpen, ha „p=reject” és „pct=70”, akkor az „reject” a sikertelen e-mailek 70%-ára vonatkozik, a 30% pedig a „quarantine” kerül.

 pct=20

ri

 Meghatározza a jelentés készítés időtartamát.

Megjelöli a fogadott XML-jelentések gyakoriságát másodpercben. Az alapértelmezett érték 86400 (naponta egyszer). 

A beállított intervallumtól függetlenül a legtöbb esetben az internetszolgáltatók különböző időközönként küldik a jelentéseket (általában naponta egyszer).

 ri=3600

 

Végszó

Ahogy olvasható, gyorsan és könnyen is meg lehet úszni a beállítást, de el lehet veszni a részletekben is. Első körben mindenkinek a gyors beállítást javasoljuk, hogy biztos célba érkezzenek a levelek. Utána el lehet veszni a módosításokban.

Fontos kiemelni, hogy ha Shopify rendszert használunk és beállítjuk a DMARC rekordot, akkor ellenőrizzük a Settings / Notification menüpontot. Legtöbb esetben a DMARC rekord beállítása után domain validációt kér a Shopify és négy darab CNAME értéket fel kell még vennünk a DNS rekordba. Felvétel után a validáció gombot se felejtsük el, melyet ugyanitt érhetünk el.

LinkedIn