Miért landol a levél a spamben? SPF, DKIM és DMARC érthetően

A webshop visszaigazolója nem érkezik meg, az ajánlatot a címzett a spam mappában találja meg három nap múlva, a kapcsolatfelvételi űrlap levelei pedig egyszerűen eltűnnek. Ilyenkor szinte mindig ugyanaz a háttér: a fogadó szerver nem tudta megállapítani, hogy a levelet valóban a domain gazdája küldte-e – és a kétséges levelet inkább félreteszi.

Az e-mail protokollja (SMTP) eredetileg semmilyen ellenőrzést nem tartalmazott. Bárki írhatott a feladó mezőbe bármilyen címet, ugyanúgy, ahogy egy borítékra is bárki ráírhat bármilyen feladót. Az elmúlt két évtizedben erre épült rá három DNS-alapú mechanizmus, amelyekkel a domain gazdája nyilvánosan kijelentheti, ki küldhet a nevében.

SPF: kik küldhetnek a domain nevében?

Az SPF (Sender Policy Framework) egy TXT rekord a domain zónájában, amely felsorolja azokat a szervereket, amelyek jogosan küldhetnek levelet a domainről. Egy egyszerű példa:

v=spf1 a mx include:_spf.levelezo-szolgaltato.example ~all

A fogadó szerver megnézi, melyik IP-címről érkezett a levél, és összeveti a listával. Néhány gyakorlati szabály, amelyen sokan elcsúsznak:

• Egy domainhez csak egy SPF rekord tartozhat. Ha két v=spf1 kezdetű TXT rekord van, az ellenőrzés hibát ad. Új küldőszolgáltatás bevonásakor a meglévő rekordot kell bővíteni.
• Legfeljebb 10 DNS-lekérdezés. Az include, a, mx és hasonló elemek mind lekérdezést okoznak; aki öt különböző szolgáltatást fűz egymás után, könnyen túllépi a korlátot.
• A végződés számít. A -all azt mondja, hogy minden más küldő jogosulatlan, a ~all csak gyanúsnak jelöli őket. Átállás idején a ~all a biztonságosabb.

Az SPF gyenge pontja, hogy a levél „boríték” feladóját vizsgálja, nem azt a címet, amit a címzett a levelezőprogramjában lát. Ezért önmagában kevés.

DKIM: aláírás a levélen

A DKIM (DomainKeys Identified Mail) digitális aláírást tesz a levél fejlécébe. A küldő szerver a saját privát kulcsával aláírja a levelet, a hozzá tartozó nyilvános kulcsot pedig egy TXT rekordban teszed közzé, egy úgynevezett szelektor alatt (például level2026._domainkey.cegem.hu).

A fogadó szerver lekéri a nyilvános kulcsot, és ellenőrzi az aláírást. Ha stimmel, biztos lehet benne, hogy a levelet a kulcs birtokosa küldte, és útközben nem módosították. A DKIM a továbbításokat is jobban bírja, mint az SPF, mert az aláírás a levéllel együtt utazik.

A kulcsot a levelezést kiszolgáló rendszer generálja; a te dolgod annyi, hogy a kapott rekordot pontosan, tördelés nélkül felvedd a zónába.

DMARC: mi történjen, ha az ellenőrzés elbukik?

A DMARC (Domain-based Message Authentication, Reporting and Conformance) összeköti a kettőt a látható feladóval. Egy _dmarc nevű TXT rekordban kijelented, hogy

1. a levélnek át kell mennie az SPF- vagy a DKIM-ellenőrzésen,
2. és az ellenőrzött domainnek egyeznie kell a látható feladó domainjével (ezt hívják igazításnak, angolul alignment),
3. valamint megmondod, mit tegyen a fogadó, ha ez nem teljesül: p=none (csak jelentsen), p=quarantine (tegye a spambe) vagy p=reject (utasítsa vissza).

v=DMARC1; p=none; rua=mailto:[email protected]

Érdemes p=none beállítással kezdeni, és néhány hétig olvasni a beérkező összesítő jelentéseket. Ezekből derül ki, hány olyan rendszer küld a domain nevében, amelyről nem is tudtál – a hírlevélküldő, a számlázó, a CRM, a webshop. Ha mindegyik rendben aláír, lehet szigorítani.

Amit a nagy postafiók-szolgáltatók ma elvárnak

2024 elején a Gmail és a Yahoo, 2025-ben a Microsoft fogyasztói levelezése is szigorított. A lényeg mindenkire vonatkozik, aki saját domainről küld:

• legyen SPF vagy DKIM (nagyobb, naponta több ezer levelet küldőknél mindkettő, plusz DMARC rekord),
• a küldő IP-címnek legyen érvényes fordított DNS-bejegyzése (PTR), amely visszafelé is egyezik,
• a kapcsolat legyen TLS-sel titkosítva,
• tömeges marketingleveleknél legyen egy kattintásos leiratkozás, és alacsony maradjon a spamjelentések aránya.

A tárhely szerepe

Megosztott tárhelyen a leggyakoribb hiba, hogy a weboldal űrlapja a webszerver beépített levélküldőjével (például a PHP mail() függvényével) küld, a feladó címe viszont egy külső levelezőszolgáltatónál kezelt domain. Ilyenkor a levél a tárhely IP-címéről indul, amely nincs benne az SPF-ben, és nincs rajta a domain DKIM-aláírása – vagyis éppen úgy néz ki, mint egy hamisítvány.

A megoldás: az űrlap hitelesített SMTP-kapcsolaton, a tényleges levelezőszerveren keresztül küldjön, vagy a tárhely küldőszerverét is fel kell venni az SPF-be és be kell állítani rajta a DKIM-aláírást.

Rövid ellenőrzőlista

• Egyetlen SPF rekord, amely minden valódi küldőt tartalmaz, és 10 lekérdezés alatt marad.
• DKIM-aláírás minden küldő rendszeren, a kulcsok a zónában.
• DMARC rekord legalább p=none szinttel és jelentési címmel.
• A weboldal levelei hitelesített SMTP-n mennek ki.
• Tárhely- vagy DNS-váltáskor ezek a rekordok is átkerülnek az új zónába – különben a költözés napján eltűnik a levelezés hitelessége.