SPF, DKIM és DMARC érthetően: a DNS-rekordok, amelyek távol tartanak a spamtől

Van saját domained és egy olyan címed, mint a nev@ceg.hu, az ügyfeleidnek küldött üzeneteid mégis a spam mappában kötnek ki, vagy egyáltalán meg sem érkeznek. Nem a te hibád, és nem is az ügyfélé. A probléma szinte mindig az, hogy a leveledet fogadó szerverek nem tudják megerősíteni, hogy valóban te vagy te.

A Gmail, az Outlook és a többiek minden beérkező üzenetet három mechanizmuson keresztül ellenőriznek: SPF, DKIM és DMARC. Ez három rekord, amelyet a domained DNS-éhez adsz hozzá — nyilvános szabályok halmaza, amely megmondja a szervereknek, mely rendszerek küldhetnek a nevedben. Nélkülük a leveled hátrányból indul. Ebben a cikkben egyesével, közérthető nyelven veszem sorra őket, és pontosan megmutatom, mit kell hozzáadnod és milyen sorrendben, felesleges szakzsargon nélkül.

Miért is landolnak a leveleid a spamben

Amikor elküldesz egy üzenetet, a címzett szervere nem tudhatja, hogy az valóban tőled származik-e, vagy valakitől, aki a domained nevét használja. Olyan ez, mint egy levél, amelynek a borítékjára bárki ráírhatja, hogy „feladó: ceg.hu”.

Hogy ne verjék át, a nagy szolgáltatók bizonyítékot kérnek. A domained DNS-ében három nyilvános aláírást keresnek:

• SPF — mely szerverek küldhetnek levelet a nevedben
• DKIM — egy aláírás, amely bizonyítja, hogy az üzenetet nem módosították továbbítás közben
• DMARC — mit tegyen a szerver, ha egy üzenet megbukik az SPF- vagy DKIM-ellenőrzésen

Ha ezek hiányoznak, a leveledet nem feltétlenül tiltják le, de könnyen a spamben landol. Ha helyesen vannak beállítva, sokkal nagyobb bizalommal jutsz át a szűrőn. A jó hír: egyszer állítod be őket, és a helyükön maradnak.

SPF — a küldésre jogosult szerverek listája

Az SPF (Sender Policy Framework) egyetlen TXT rekord a DNS-edben. Felsorolja azokat a szervereket, amelyek jogosultak a domainedről küldeni: Google Workspace, Microsoft 365, egy hírlevél-eszköz, a tárhelyszervered.

Egy tipikus érték így néz ki:

v=spf1 include:_spf.google.com ~all

• v=spf1 kijelenti, hogy ez egy SPF-házirend
• include:... hozzáad egy szolgáltató szervereit (itt a Google-t)
• ~all azt jelenti: „a többit kezeld gyanúsan, de ne utasítsd el keményen”

Két csapda, amelyet érdemes elkerülni: domainenként csak egy SPF-rekordod lehet (ha több szolgáltatót használsz, mindet ugyanarra a sorra tedd, több include utasítással), és az SPF legfeljebb tíz lekérdezést enged meg — ne zsúfolj be tucatnyi szolgáltatást. Ha csak a Google-ön vagy csak a Microsoftön keresztül küldesz, a fenti érték testreszabva minden, amire szükséged van.

DKIM — az aláírás, amely bizonyítja, hogy az üzenet valódi

A DKIM (DomainKeys Identified Mail) minden e-mailhez hozzáad egy, a címzett számára láthatatlan digitális aláírást. A fogadó szerver a DNS-edből származó nyilvános kulcs segítségével erősíti meg, hogy az üzenet valóban tőled származik, és útközben nem módosították.

A gyakorlatban a kulcsot nem te írod meg. Az e-mail-szolgáltatód (Google, Microsoft, a hírlevél-eszköz) generálja, te pedig egyszerűen hozzáadod a DNS-hez — általában TXT vagy CNAME rekordként, olyan névvel, mint selector._domainkey.ceg.hu.

• A Google Workspace-ben az Adminban engedélyezed, az Alkalmazások > Gmail > E-mail hitelesítése alatt
• A Microsoft 365-ben a Defenderből, az e-mail-házirend szakaszban

Fontos, hogy a tömeges küldésre használt eszközökhöz (hírlevelek, számlázás) is engedélyezd a DKIM-et, ne csak a fő postafiókodhoz. Mindegyiknek saját selectora van, tehát saját rekordja is.

DMARC — a szabály, amely összeköti az egészet és jelentéseket ad

A DMARC az, ami az SPF-et és a DKIM-et elszigetelt ellenőrzésekből valódi házirenddé alakítja. Megmondja a címzett szervereknek, mit tegyenek, ha egy üzenet megbukik a hitelesítésen — és ráadásul jelentéseket küld arról, ki küld a domainedről.

A rekord szintén egy TXT, _dmarc.ceg.hu néven:

v=DMARC1; p=none; rua=mailto:jelentesek@ceg.hu

• p=none — csak megfigyelsz, semmit sem utasítanak el (így kezdesz)
• p=quarantine — a megbukott üzenetek a spamba kerülnek
• p=reject — a megbukott üzeneteket teljesen elutasítják
• rua= — a cím, ahová a jelentéseket kapod

Az aranyszabály: kezdd p=none értékkel néhány héten át, olvasd a jelentéseket, hogy megbizonyosodj: a jogos leveleid átmennek, majd fokozatosan lépj feljebb quarantine-ra, és csak legvégül reject-re. Ha egyből reject-re ugrasz ellenőrzés nélkül, azzal kockáztatod, hogy a saját leveleidet blokkolod.

A helyes sorrend, és ki állíthatja be neked

Röviden, az egészséges sorrend: először SPF, aztán DKIM, majd DMARC p=none értéken, és csak amint a jelentések azt mutatják, hogy minden tiszta, emeled a DMARC-ot quarantine-ra, majd reject-re. A domained DNS-paneljében adod hozzá őket (a regisztrátornál vagy a tárhelynél), és a változások néhány perctől akár egy napig terjedő idő alatt terjednek szét.

Úgy tesztelsz, hogy küldesz egy levelet egy Gmail-címre: nyisd meg az üzenetet, válaszd az „Eredeti megjelenítése” lehetőséget, és keresd a PASS feliratot az SPF, DKIM és DMARC mellett.

Ha mindez halandzsának tűnik, az teljesen normális — egyetlen rossz helyre tett vessző mindent tönkretehet. Az MPO Web Studiónál az SPF, DKIM és DMARC beállítása a weboldal átadásának része, teljesen távolról, anélkül, hogy bárhová el kellene menned. Ha csak egy gyors ellenőrzést szeretnél a domainedről, írj nekünk WhatsAppon, és együtt megnézzük, mi hiányzik.