DMARC beállítás: miért nem érkeznek meg a leveleid
A három rekord, egyszerű nyelven
Képzeld el, hogy a leveled egy boríték, amit a portán ellenőriznek.
| Rekord | Mit mond ki | Mi a szerepe a portán |
|---|---|---|
| SPF | Mely szerverek adhatnak fel levelet a domain nevében | „Ez a futár szerepel a listánkon" |
| DKIM | Digitális aláírás a levélen | „A pecsét sértetlen, útközben nem nyúltak hozzá" |
| DMARC | Mi a teendő, ha az előző kettő nem stimmel | „Ha nem stimmel: engedjük át, tegyük külön, vagy küldjük vissza?" |
A DMARC önmagában nem véd: az SPF és a DKIM eredményére épül. Ezért kell mindhárom.
Így néznek ki a valóságban
SPF — TXT rekord magán a domainen:
`` example.com. TXT "v=spf1 include:_spf.google.com include:sendgrid.net -all" ``
DKIM — TXT rekord egy választó (selector) alatt; a kulcsot a levelezőszolgáltató adja:
`` selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..." ``
DMARC — TXT rekord a _dmarc aldomainen:
`` _dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r; pct=100" ``
A DMARC-rekord mezői, amiket ismerni érdemes:
p=— a szabály:none(csak figyelj és jelents),quarantine(spam mappába),reject(vissza se vedd).rua=— ide jönnek az összesítő jelentések. Enélkül vakon dolgozol.adkim=/aspf=— mennyire szigorúan kell egyeznie a domainnek:r(relaxed, aldomain is jó) vagys(strict, pontos egyezés).pct=— a levelek hány százalékára vonatkozzon a szabály. Fokozatos bevezetésnél hasznos.
A négy leggyakoribb hiba
1. Két SPF-rekord egy domainen
Ez a leggyakoribb, és azonnal érvénytelenné teszi az egészet. A szabvány egyetlen SPF-rekordot enged domainenként. Ha a levelezőszolgáltató is felvett egyet, meg a hírlevélrendszer is, akkor a kettőt össze kell vonni, nem egymás mellé tenni:
`` "v=spf1 include:_spf.google.com include:sendgrid.net -all" ``
2. Túl sok DNS-lekérdezés
Az SPF kiértékelése legfeljebb tíz DNS-lekérdezést végezhet. Minden include: legalább egyet elhasznál, és van, amelyik többet is, mert magában is hivatkozik tovább. A tizedik fölött a kiértékelés hibára fut, és a levél úgy jár, mintha nem is lenne SPF-ed. Ha sok szolgáltatód van, az include-okat ritkítani kell.
3. Elfelejtett küldő
A klasszikus eset: a levelezés a Google-nél van, de a számlázóprogram, a webshop és a hírlevélrendszer máshonnan küld. Az SPF csak a Google-t sorolja fel, tehát a számlád akad el — pont az, ami a legfontosabb. Ezért kezdődik a munka mindig számbavétellel: melyik rendszer küld levelet a nevedben?
4. Azonnali p=reject
Csábító rögtön a legszigorúbb szabályt beállítani. Ilyenkor viszont a még nem hitelesített jogos küldőid levelei is eltűnnek — és nem a spam mappában, hanem véglegesen. A DMARC bevezetése szándékosan lassú folyamat.
A bevezetés menete
1. lépés — számbavétel
Írd össze, mi küld levelet a nevedben: levelezőszolgáltató, webshop, számlázó, CRM, hírlevél, ügyfélszolgálati rendszer, monitoring-riasztás. Ez a lista lesz az SPF alapja.
2. lépés — SPF rendbetétele
Egyetlen érvényes rekord, benne az összes jogos küldő. A zárás legyen -all (hard fail) vagy legalább ~all (soft fail); a +all mindenkit átenged, tehát értelmetlen.
3. lépés — DKIM minden küldőnél
Minden rendszerben külön be kell kapcsolni, mindegyik saját kulccsal és választóval. A legtöbb szolgáltatónál ez egy kapcsoló és egy DNS-rekord.
4. lépés — DMARC figyelő módban
`` "v=DMARC1; p=none; rua=mailto:dmarc@example.com" ``
Ilyenkor semmi nem változik a kézbesítésben, viszont naponta kapsz összesítő jelentéseket arról, ki küld levelet a nevedben, és melyik bukik el a hitelesítésen. Ez a legfontosabb szakasz: itt derül ki, mit felejtettél ki a listából. Két-négy hetet érdemes rászánni.
5. lépés — szigorítás
Ha a jelentésekben már minden jogos küldő átmegy, jöhet a quarantine, majd egy-két hét után a reject. Aki óvatos, a pct= mezővel lépcsőzhet: előbb a forgalom negyedére, aztán felére, végül mindenre.
Mit vársz a jelentésektől?
A DMARC-jelentés XML, és nem embernek való olvasásra készült. Két dolgot keress benne:
- Jogos küldő, ami elbukik — ezt javítani kell (hiányzó
include, kikapcsolt DKIM). - Idegen szerver, ami a nevedben küld — ez vagy egy elfelejtett rendszered, vagy visszaélés. A legtöbb ügyfélnél ez a jelentés hozza az első meglepetést.
Ha nem akarsz XML-t olvasni, van több szolgáltatás, ami emberi nyelvre fordítja; a jelentések fogadó címét ilyenkor arra állítod.
Miért lett ez hirtelen fontos?
Mert a nagy szolgáltatók szigorítottak. A Gmail 2024. február 1. óta minden feladótól elvárja legalább az SPF vagy a DKIM meglétét, érvényes PTR-rekordot és TLS-kapcsolatot. Aki naponta 5000-nél több levelet küld Gmail-címekre, annak SPF, DKIM és DMARC is kell (a DMARC-szabály lehet p=none), valamint egykattintásos leiratkozás a marketinglevelekben. A Postmaster Toolsban jelzett spam-arányt 0,3% alatt kell tartani — a Google ajánlása 0,1% alatt.
A gyakorlati következmény: hitelesítés nélkül a leveled először a spam mappába kerül, aztán már el sem jut odáig.
Ellenőrzés: hogyan tudod, hogy jó?
- Küldj tesztlevelet egy Gmail- és egy Outlook-fiókba a saját rendszereidből — mindegyikből külön.
- Nézd meg a fejlécet („Eredeti megjelenítése" a Gmailben): az
Authentication-Resultssorbanspf=pass,dkim=passésdmarc=passkell álljon. - Nézd meg, hogy a From-domain egyezik-e az SPF vagy a DKIM domainjével. Ezt hívják igazításnak (alignment), és a DMARC ezen bukik el a leggyakrabban akkor is, ha az SPF és a DKIM külön-külön rendben van.
- Egy hét múlva nézd meg a DMARC-jelentést — ez mutatja meg, amit a tesztleveleiddel nem látsz.
Gyakori kérdések
Ha nem küldök hírlevelet, akkor is kell?
Igen, két okból. Egyrészt a számlák és az automatikus visszaigazolások is levelek, és ezeknek meg kell érkezniük. Másrészt a hitelesítés hiánya nem a te küldésedről szól, hanem arról, hogy más küldhet a nevedben.
Van olyan domain, amiről soha nem küldök levelet. Az érdekes?
Nagyon. Pont az ilyen „parkoló" domaineket használják hamisításra. Ezekre a legszigorúbb rekord való, mert nincs mit elrontani vele:
`` "v=spf1 -all" "v=DMARC1; p=reject;" ``
A hosting szolgáltatóm már beállított valamit. Az nem elég?
Jellemzően egy alap SPF-rekordot ad a saját szerverére. Ez akkor elég, ha minden leveled onnan megy — de a webshop, a számlázó és a hírlevélrendszer általában máshonnan küld. Épp azok a küldők maradnak ki, amelyek a legfontosabbak.
Mennyi idő az egész?
A rekordok beállítása egy-két nap, plusz néhány óra DNS-terjedés. A figyelő szakasz két-négy hét — ezt nem lehet átugrani, mert ez védi meg a saját leveleidet. Utána a szigorítás napok kérdése.
Mi történik, ha rosszul állítom be?
A leggyakoribb következmény, hogy a saját leveleid akadnak el. Ezért kell a figyelő szakasz és a fejléc-ellenőrzés: mindkettő azelőtt mutatja meg a hibát, hogy a vásárlóid találkoznának vele.
Ha nem szeretnél DNS-rekordokat szerkeszteni, rendbe tesszük az e-mail-hitelesítésedet — a számbavételtől a reject szintig, közben végig mérve, hogy a saját leveleid rendben mennek.