SPF, DKIM, DMARC beállítás: hogy ne a spam mappában végezzék a céges leveleid

Szlávik Péter
Szlávik Péter Közzétéve:
Levelezés

Elindítasz egy próbarendelést, a webshop elküldi a visszaigazolást, te pedig hiába frissíted a postaládát: a levél a spam mappában landol. Közben a hírlevélküldő és a számlázó másik szerverről küld ugyanazzal a feladócímmel. Az SPF DKIM DMARC beállítás abban segít, hogy a fogadó szerver felismerje: ezek a küldők valóban hozzád tartoznak.

Ebben a cikkben végigvesszük, mit ellenőriz az SPF, a DKIM és a DMARC, milyen sorrendben állítsd be őket, és hogyan olvasd ki a DMARC riportokból, melyik rendszer szorul javításra.

Sybell Hosting szuperhős három pajzs mögött: SPF, DKIM és DMARC szűri a hitelesítetlen leveleket, a többi biztonságosan megérkezik a postaládába

Miért kerülhet a céges e-mail a spam mappába?

A fogadó szerver három egyszerű kérdésre keresi a választ. Képzeld el úgy, mintha egy irodaház portása ellenőrizné a belépőt, a személyi pecsétjét és a házirendet.

  • SPF: szerepel ez a küldőszerver a domained engedélyezett listáján?
  • DKIM: tartozik a levélhez érvényes digitális aláírás, és változatlan maradt az út közben?
  • DMARC: összhangban van a látható feladó az SPF- vagy DKIM-azonosítással, és mi történjen, ha az ellenőrzés nem sikerül?

Az SPF és a DKIM bizonyítékot ad. A DMARC ehhez szabályt, domain-összhangot és visszajelzést kapcsol. Így a fogadó szolgáltató nem találgatja, mit kezdjen a domained nevében érkező, de nem hitelesített levéllel.

Ez az e-mail hitelesítés sokat javít a kézbesíthetőségen, de nem ígér automatikus inboxba kerülést. A feladói reputáció, az üzenet tartalma, a címzettek aktivitása és a spambejelentések ugyanúgy számítanak.

Miért fontos ez 2026-ban egy kisebb webshopnak is?

A nagy levelezőszolgáltatók már nem pusztán ajánlásként kezelik a hitelesítést. A Google személyes Gmail-címekre küldő minden feladónál SPF- vagy DKIM-hitelesítést vár el. A körülbelül napi 5000 vagy több üzenetet küldő feladóknak ezen felül SPF-et és DKIM-et együtt, legalább p=none DMARC-házirendet, domain-összhangot és marketingleveleknél egyszerű leiratkozást kell biztosítaniuk. A Google hivatalos küldői útmutatója szerint a spamjelzések arányát 0,3% alatt kell tartani, a biztonságos cél inkább 0,1% alatt van.

A Gmail 2025 novemberétől erősebben érvényesíti ezeket a követelményeket: a hiányos hitelesítés átmeneti korlátozást vagy végleges elutasítást is eredményezhet. Yahoo esetében nincs közzétett fix küszöbérték, de a Yahoo Sender Hub nagy mennyiségű küldésnél SPF-et, DKIM-et, legalább p=none DMARC-házirendet, domain-összhangot és működő leiratkozást vár el.

A Microsoft 2025. május 5-től szigorította az Outlook.com, Hotmail.com és Live.com címekre napi 5000-nél több levelet küldő domainek ellenőrzését. A követelmények között SPF, DKIM, DMARC és domain-összhang szerepel; a Microsoft hivatalos bejelentése a nem megfelelő levelek elutasítására is kitér.

Egy növekvő webshop egyetlen kampánnyal közel kerülhet ezekhez a mennyiségekhez. A rekordokat ezért akkor érdemes rendbe tenni, amikor még pontosan tudod, melyik rendszer küld a domained nevében.

Mielőtt rekordot állítasz be: térképezd fel az összes küldőt

Az első lépés nem a DNS-kezelő megnyitása. Előbb készíts teljes küldőlistát, különben a későbbi riportokból kell kitalálnod, mi hiányzik.

Jelöld meg, mely rendszerek küldenek a domaineddel:

  • céges postafiók és levelezőszerver;
  • weboldal vagy WooCommerce rendelési és kapcsolatfelvételi levelei;
  • számlázó- és ügyviteli rendszer;
  • hírlevélküldő és marketingautomatizációs platform;
  • CRM, ügyfélszolgálat vagy jegykezelő;
  • jelszó-visszaállító, értesítő és egyéb tranzakciós levelek.

Minden tételhez írd fel a feladócímet, a szolgáltató nevét, a használt küldési domaint és azt, ki fér hozzá a DNS-hez. A webshopod.hu címről küldött rendelés-visszaigazolás például nem biztos, hogy ugyanarról a szerverről indul, mint a hello@webshopod.hu postafiókból küldött üzenet.

SPF, DKIM, DMARC beállítás: milyen sorrendben haladj?

1. lépés: állítsd össze az SPF rekordot

Az SPF, vagyis a Sender Policy Framework, azt mondja meg, mely szerverek küldhetnek levelet a domained nevében. Olyan, mint egy beléptetőlista: a fogadó oldal összeveti a küldő IP-címét a DNS-ben közzétett engedélyekkel.

Így haladj:

  1. Nyisd meg a domain DNS-kezelőjét, és keresd meg a meglévő TXT rekordokat.
  2. Kérd ki minden küldőszolgáltató hivatalos SPF-elemét. Ne másolj be találomra egy internetes mintát.
  3. Egyetlen összevont SPF rekordot használj ugyanahhoz a domainhez. Két külön v=spf1 rekord nem két védelmi réteg, hanem hibás konfiguráció.
  4. Ellenőrizd, hogy a weboldal, a számlázó, a hírlevélküldő és a levelezés is szerepel-e benne.
  5. Küldj tesztlevelet, majd a fogadott üzenet technikai fejlécében keresd az SPF: pass eredményt.

Szemléltető példa:

v=spf1 include:_spf.pelda-szolgaltato.hu include:_spf.masik-rendszer.hu ~all

A ~all úgynevezett soft fail: a felsoroláson kívüli küldő gyanús, de a fogadó oldal még saját szabályai szerint dönt. A -all határozottabb tiltás. Bevezetéskor a ~all megfontolható, de csak akkor válts szigorúbbra, amikor minden legitim küldődet ellenőrizted.

Az SPF rekord legfeljebb tíz DNS-lekérdezési műveletet használhat fel. Az egymásba ágyazott include elemek gyorsan elfogyasztják ezt a keretet, és a limit átlépésekor az SPF teljes ellenőrzése hibára futhat. Ha sok szolgáltatód van, egyszerűsítsd a küldési struktúrát, vagy kérj segítséget a DNS kezelőjétől.

2. lépés: kapcsold be a DKIM-aláírást

A DKIM a DomainKeys Identified Mail rövidítése. A küldőrendszer egy privát kulccsal aláírja a levelet, a fogadó szerver pedig a DNS-ben közzétett nyilvános kulccsal ellenőrzi az aláírást. Így látszik, hogy az üzenet a megjelölt domainhez kapcsolódik, és a tartalma nem változott meg az út közben.

A szolgáltató jellemzően egy selector._domainkey nevű TXT rekordot ad. A selector azt jelzi, melyik kulccsal kell ellenőrizni az adott aláírást. A rekord értékét mindig a levelezési, hírlevél- vagy tranzakciós szolgáltatótól vedd át; ne próbáld saját magad kitalálni.

Ellenőrzőlista:

  • Kapcsold be a DKIM-et minden küldőrendszerben, amely a domaineddel küld.
  • A hírlevélküldő és a számlázó külön selectort és külön rekordot is kérhet.
  • Ahol a szolgáltató támogatja, használj 2048 bites kulcsot.
  • Kulcsrotációnál ne töröld azonnal a régi selectort; előbb győződj meg róla, hogy már nem írnak alá vele aktív levelek.
  • A fogadott levél fejlécében keresd a DKIM: pass eredményt, valamint a d= domaint és az s= selectort.

A DKIM továbbítás után is stabilabb bizonyíték lehet, mint az SPF, mert nem a fogadó szerverhez kapcsolódó IP-címre épül. Ettől még a látható feladó és az aláíró domain összhangját külön ellenőrizned kell.

3. lépés: indítsd el a DMARC-ot

A DMARC a Domain-based Message Authentication, Reporting and Conformance rövidítése. A rekordot általában a _dmarc.sajatdomain.hu név alatt kell létrehozni. Itt adod meg, mit tegyen a fogadó oldal a sikertelen ellenőrzésekkel, és hová küldje az összesített riportokat.

Kezdő, szemléltető példa:

v=DMARC1; p=none; rua=mailto:dmarc-riport@sajatdomain.hu

A rua címre külön riportpostafiókot hozz létre. Az XML-összefoglalók gépi adatok, és néhány nap alatt eláraszthatják a napi levelezésre használt fiókot.

A DMARC-nál a domain-összhang (alignment) a döntő rész. A látható From: cím domainjének össze kell illenie legalább az SPF által hitelesített envelope domainnel vagy a DKIM d= domainjével. Egy levél tehát átmehet SPF-en és DKIM-en, mégis elbukhat DMARC-on, ha mindkét hitelesítés egy szolgáltatói domainre mutat, miközben a címzett a saját domainedet látja feladóként.

A három policy jelentése:

  • p=none: megfigyelési mód. A fogadó szerver kézbesít, te pedig riportokból gyűjtesz adatot.
  • p=quarantine: a DMARC-ot elbukó levelet a fogadó szolgáltató jellemzően spambe vagy karanténba teszi.
  • p=reject: a hibásan hitelesített levelet elutasíthatja.

Kezdj p=none móddal, majd figyeld legalább egy-két teljes küldési cikluson át a riportokat. Javítsd a legitim forrásokat, ezután lépj fokozatosan quarantine, végül indokolt esetben reject irányba. A p=none jó indulópont az adatgyűjtéshez, de önmagában nem akadályozza meg a domained utánzását.

Hogyan olvasd a DMARC riportot?

A nyers XML-t ne próbáld elsőként kézzel értelmezni. Használj DMARC-riport szolgáltatást vagy olyan levelezési felületet, amely forrásonként összefoglalja az adatokat.

Ezeket az oszlopokat keresd:

  • melyik IP-cím vagy küldőszolgáltató küldött a domained nevében;
  • hány levél érkezett onnan;
  • átment-e az SPF és a DKIM;
  • melyik domain szerepelt SPF-en, illetve a DKIM d= mezőjében;
  • teljesült-e a domain-összhang;
  • milyen döntést alkalmazott a fogadó oldal.

Ismeretlen forrásnál mindig ugyanazt a sorrendet kövesd:

  1. Azonosítsd az IP-címet vagy szolgáltatót.
  2. Keresd meg, kapcsolódik-e hozzá webshopos, számlázási vagy marketingfolyamat.
  3. Ha legitim, javítsd az SPF-et, a DKIM-et vagy a feladó domainjét.
  4. Ha nem legitim, ne add hozzá automatikusan az SPF rekordhoz. Hagyd, hogy a DMARC-policy kezelje a hitelesítetlen küldést.

A fail eredmény nem mindig támadást jelent. Továbbítás, rosszul beállított külső szolgáltató, hiányzó domain-összhang vagy egy frissen bevezetett rendszer is okozhatja. A riport feladata éppen az, hogy megmutassa, melyik folyamatot kell ellenőrizned.

Gyakori hibák és élesítés előtti ellenőrzőlista

A leggyakoribb hibák röviden:

  • több SPF rekord ugyanazon a domainen;
  • kimarad a hírlevélküldő, a számlázó vagy a webshop SMTP-je;
  • az SPF túllépi a tíz DNS-lekérdezéses limitet;
  • a DKIM rekord rossz selector alatt vagy elgépelve kerül a DNS-be;
  • a szolgáltató saját domainjével ír alá, miközben a From: cím a te domainedet mutatja;
  • a DMARC reject móddal indul, mielőtt minden legitim küldő bekerült volna a térképre;
  • a teszt csak a céges postafiókból történik, az éles rendelési levél viszont másik rendszeren át megy;
  • a DNS-módosítást azonnal késznek tekinted, anélkül hogy valódi levelek fejlécében és riportokban is ellenőriznéd.

Webshopnál ezt a tesztsort futtasd végig:

  1. Küldj levelet a céges postafiókból.
  2. Indíts próbarendelést, és ellenőrizd a rendelés-visszaigazolást.
  3. Küldj kapcsolatfelvételi űrlapot és számlázótesztet.
  4. Indíts tesztkampányt a hírlevélküldőben.
  5. Ellenőrizd legalább két különböző fogadó szolgáltatónál a fejlécben az SPF, DKIM és DMARC eredményét.
  6. Nézd meg, hogy minden feladó a védett saját domainhez tartozik-e.
  7. Marketinglevélnél próbáld ki a leiratkozást is, ne csak a technikai rekordokat.

A beállítás akkor tekinthető stabilnak, ha minden legitim küldő azonosítható, legalább az SPF vagy a DKIM átmegy és illeszkedik a látható feladóhoz, a DMARC-riportban pedig nincs magyarázat nélküli forrás.

Összegzés: így legyen működő SPF, DKIM és DMARC beállításod

A jó sorrend egyszerű: először listázd az összes küldőrendszert, utána állíts össze egyetlen teljes SPF rekordot, kapcsold be a DKIM-et minden legitim platformon, végül indíts DMARC-ot p=none módban. A riportokból javítsd a hiányzó forrásokat és a domain-összhang hibáit, majd fokozatosan szigoríts.

A DMARC nem egyszeri DNS-kapcsoló. Minden új számlázó, hírlevélküldő vagy webshopos integráció új küldési útvonalat jelent, ezért a változás után ismét ellenőrizd a valódi levelek fejlécét és a riportokat.

Ha nem szeretnéd több szolgáltató között felderíteni a saját domaines levelezést és a DNS-beállításokat, nézd meg a Sybell Hosting e-mail tárhelycsomagjait. cPanel tárhelyeinken a saját levelezésed SPF, DKIM és DMARC rekordjai automatikusan létrejönnek a tárhelyhez, így neked már csak finomítani kell rajtuk, ha szükséges. A külső küldőrendszereket és a riportcímet innen már saját magad veszed fel, a DNS-t pedig egy helyen kezeled; ha elakadsz, az ügyfélszolgálatunkon készséggel segítünk neked.

Nézd meg e-mail tárhely csomagjainkat »