SPF, DKIM és DMARC – levélhitelesítés a saját domainjén

Az SPF, a DKIM és a DMARC három DNS-alapú beállítás. Ezekből tudja a fogadó levelezőszerver (Gmail, Outlook, Freemail stb.) eldönteni, hogy a levél tényleg az Ön domainjétől jön-e. Ha nincsenek jól beállítva, a levelei spambe kerülhetnek vagy vissza is pattanhatnak. A Gmail például 2024 óta minden feladótól megköveteli a hitelesítést (550-5.7.26 hiba). Ez az oldal leírja, mit állít be a Hidden, mit kell tudnia Önnek, és mi a teendő, ha külső szolgáltatón keresztül is küld leveleket.

Röviden: ha a levelezése és a weboldala is a Hidden-nél van, és a domain DNS-ét a Hidden kezeli (Cloudflare), akkor az SPF-et, a DKIM-et és a DMARC-ot a Hidden állítja be. Önnek csak akkor kell szólnia, ha új küldő rendszert (hírlevél, webshop, CRM, Microsoft 365) kapcsol be a domainhez.

A három rekord egy mondatban

A DNS-szerkesztés a vezérlőpulton (admin.hidden.hu) nem ügyfél-funkció. A rekordok módosítását a [email protected] címen kérheti.

SPF – ki küldhet a domain nevében

A Hidden által javasolt SPF rekord

Ha a leveleit a Hidden szerverein keresztül küldi (webmail, levelezőprogram a mail.securebox.hu szerveren, illetve a weboldal PHP mail() függvénye vagy SMTP-küldése), az SPF rekordban szerepelnie kell ennek:

include:spf.hidden.hu

Az spf.hidden.hu a Hidden összes kimenő levelezőszerverének és gateway-ének IP-címét tartalmazza. Ha a Hidden új szervert állít üzembe vagy IP-t cserél, csak ezt a rekordot frissíti, így az Ön domainjén nem kell utólag semmit módosítani.

A tipikus, ajánlott minimum:

example.hu.   TXT   "v=spf1 mx include:spf.hidden.hu ~all"

Ha a domain Cloudflare mögött van, az a mechanizmust nem kell felvenni. Az A rekord ilyenkor Cloudflare IP-re mutat, nem a levelezőszerverre.

Ha több rendszer is küld a domain nevében

Minden további küldő kap egy saját include: vagy ip4: elemet. Egy domainen csak egyetlen SPF rekord lehet. Két külön v=spf1 TXT rekord hibás, ilyenkor a fogadók az SPF-et érvénytelennek tekintik.

Példák (a pontos értéket mindig a szolgáltató dokumentációjából vagy a beállítási felületéről vegye):

Összevont példa (Hidden-levelezés + Microsoft 365 + egy fix IP-s ERP):

v=spf1 mx include:spf.hidden.hu include:spf.protection.outlook.com ip4:203.0.113.10 ~all

A 10 DNS-lekérdezéses korlát

Az SPF-szabvány szerint egy SPF rekord kiértékelése legfeljebb 10 DNS-lekérdezést okozhat. Ebbe minden include:, a, mx, exists: és redirect= beleszámít, a beágyazott include-ok lekérdezéseivel együtt. Ha a rekord ennél többet igényel, a fogadó permerror eredményt ad, és az SPF egyáltalán nem érvényes, mintha nem is lenne.

Gyakorlati tanácsok:

• Ne halmozzon include-okat „biztos, ami biztos” alapon. Csak azok a rendszerek szerepeljenek, amelyek ténylegesen küldenek a domain nevében.
• A megszűnt szolgáltatók (régi hírlevélrendszer, régi tárhely, régi ticketrendszer) include-ját töröltesse.
• Az ip4: és ip6: elemek nem számítanak bele a 10-be. Fix IP-s saját szervernél használja ezeket.
• A hírlevél- és kampányküldést tegye külön aldomainre (pl. hirlevel.example.hu). Annak saját SPF rekordja van, így nem terheli a fődomain korlátját. Lásd: Hírlevél és tömeges küldés.
• Ellenőrzés: az MXToolbox „SPF Record Lookup” eszköze kiírja a lekérdezések számát.

~all vagy -all?

• ~all (softfail): a Hidden ezt állítja be alapértelmezetten. Ha egy jogos küldő véletlenül kimaradt az SPF-ből, a levele így még eljuthat a címzetthez.
• -all (hardfail): szigorú, a nem engedélyezett forrásból jövő levelet a fogadó elutasíthatja. Csak akkor javasoljuk, ha a DMARC-riportok alapján biztos, hogy minden legitim küldő szerepel a rekordban.

DKIM – digitális aláírás

Hidden-levelezés: a DKIM-et a Hidden állítja be

A Hidden levelezőszervere (mail.securebox.hu) az Ön domainjéről kimenő leveleket DKIM-mel aláírja.

• Selector: mail. A DNS-ben a rekord neve mail._domainkey.example.hu (TXT, nyilvános kulcs).
• A kulcspárt a Hidden generálja. A privát kulcs a levelezőszerveren marad, a nyilvános rész kerül a DNS-be.
• A DKIM-kulcs a vezérlőpulton nem látható. Ha szüksége van rá (pl. egy auditor kéri), írjon a supportnak.

Ha nem biztos benne, hogy a domainjén van-e DKIM, küldjön egy levelet egy Gmail-címre, és nézze meg az eredeti forrását (lásd lent, „Ellenőrzés”). Ha nem látja a DKIM: PASS sort, írjon a [email protected] címre, és a Hidden pótolja a kulcsot.

Külső szolgáltató DKIM-je (Mailchimp, Mailgun, Microsoft 365, webshop, CRM)

A külső szolgáltató saját kulccsal írja alá a leveleket. A kulcsot vagy a CNAME-célokat a szolgáltató felületén kapja meg, ezeket kell eljuttatnia a Hidden-hez:

1. Lépjen be a szolgáltató felületére, és keresse meg a „Domain authentication”, „Sender authentication” vagy „DKIM” menüpontot.
2. Adja meg a domaint (vagy a küldéshez használt aldomaint).
3. A felület kiír 1–4 DNS rekordot: típus (TXT vagy CNAME), név és érték.
4. Másolja ki pontosan (ne kép formájában!), és küldje el a [email protected] címre a domain nevével.
5. Miután a Hidden jelezte, hogy felvette a rekordokat, a szolgáltató felületén nyomja meg a „Verify” vagy „Ellenőrzés” gombot. A Cloudflare-ben a változás általában perceken belül él.

Tipikus rekordok:

Jó tudni:

• A DKIM nem a feladó e-mail-címhez, hanem a küldő rendszerhez kötődik. Minden rendszernek, amely a domain nevében küld, saját selectorral és saját kulccsal kell aláírnia.
• Több DKIM rekord is lehet egy domainen (különböző selectorokkal), ezek nem zavarják egymást.
• Ha saját levelezőszervert üzemeltet (irodai Exchange, saját Linux szerver), a DKIM-aláírást azon kell bekapcsolni. A nyilvános kulcsot a Hidden felveszi a DNS-be, akár az első aláírt levél előtt is.

DMARC – szabály és riportok

Mit csinál a DMARC?

A DMARC két dolgot ad:

1. Szabályt (policy): megmondja, mit tegyen a fogadó a domain nevében érkező, de SPF/DKIM-ellenőrzésen elbukó levéllel:
   • none: semmi különöset, csak jelentsen
   • quarantine: tegye spambe
   • reject: utasítsa el
2. Riportokat: a nagy fogadók (Gmail, Microsoft, Yahoo stb.) rendszeresen elküldik, hogy honnan, hány levél érkezett a domain nevében, és ezek közül mennyi ment át az SPF/DKIM-ellenőrzésen. A Hiddennél ezeket a riportokat a Cloudflare DMARC Management fogadja és összesíti, így Önnek nem kell velük foglalkoznia.

Az „alignment” (egyezés) azt jelenti, hogy az SPF- vagy DKIM-ellenőrzött domainnek egyeznie kell a levél látható From címének domainjével. Ha egy rendszer [email protected] feladóval küld, de a saját domainjével írja alá a levelet, az SPF/DKIM ugyan „pass” lehet, a DMARC mégis elbukik.

A Hidden alapbeállítása: p=none

A Hidden a DMARC-ot megfigyelő módban állítja be:

_dmarc.example.hu.   TXT   "v=DMARC1; p=none; rua=mailto:<a Cloudflare DMARC Management riportcíme>"

• A p=none nem rontja a kézbesítést. Semmilyen levél nem vész el miatta.
• A riportokból kiderül, ki mindenki küld a domain nevében: a Hidden szerverei, a webshop, egy CRM, egy elfelejtett hírlevélrendszer, vagy éppen spammerek hamisított feladóval.
• A Hidden a riportokat a Cloudflare Email > DMARC Management felületén követi. Kérésre megosztja Önnel a lényeget: mely források küldenek, és milyen arányban mennek át az ellenőrzésen. Ha hozzáfér a domain Cloudflare-fiókjához, ott Ön is megnézheti.
• Saját e-mail-címre érkező DMARC-riportokat nem javaslunk: a nyers riportok naponta érkező XML-fájlok, emberi olvasásra nem alkalmasak, és csak feleslegesen bonyolítják a dolgot. A Cloudflare összesítése ugyanezt áttekinthetően mutatja.

Mikor és hogyan szigorítson?

A szigorítás (quarantine / reject) csak akkor biztonságos, ha minden legitim küldő átmegy az ellenőrzésen. Különben a saját jogos levelei (számlák, webshop-értesítők, hírlevelek) vesznek el.

Javasolt menet:

1. p=none legalább 2–4 hétig, riportgyűjtéssel.
2. A riportok alapján minden legitim forrást rendbe kell tenni: SPF include és DKIM-aláírás. A Hidden saját szervereiről (mail.securebox.hu, smtp.hidden.hu) küldött levelek a tapasztalat szerint gyakorlatilag 100%-ban átmennek a DMARC-on. A külső rendszerek (webshop-motor, CRM, régi SMTP) viszont gyakran DKIM nélkül küldenek.
3. p=quarantine, esetleg pct= résszel fokozatosan, újabb néhány hét megfigyeléssel.
4. p=reject, ha minden forrás tiszta.

A Hidden alapértelmezetten nem állít be szigorú szabályt. Ha szigorítani szeretne, írjon a supportnak, és a riportok alapján együtt döntenek.

Mit nem csinál a DMARC?

• A DMARC önmagában nem javítja a kézbesítést. Az, hogy egy levél az Inboxba vagy a spambe kerül, a tartalomtól, a címzett korábbi viselkedésétől és a küldő hírnevétől is függ.
• A DMARC hiánya nem biztonsági rés. Ha valaki pénzért „sebezhetőség-jelentést” küld Önnek DMARC hiánya miatt, az szinte biztosan kéretlen ajánlat, figyelmen kívül hagyhatja.
• A DMARC nem akadályozza meg, hogy valaki hasonló domainről (pl. examp1e.hu) küldjön adathalász leveleket.

Külső küldő szolgáltatás bekapcsolása – ellenőrzőlista

Ha Mailchimp-et, Mailgunt, Brevót, Microsoft 365-öt, egy webshop-motort vagy CRM-et kezd használni a domainje nevében, mindig az alábbi 4 dologra van szükség:

Microsoft 365

• SPF: include:spf.protection.outlook.com. Ha a weboldal továbbra is a Hidden szerveréről küld, az include:spf.hidden.hu is maradjon benne. Gyakori hiba, hogy a Microsoft 365-re költözéskor az új SPF-ből kimarad a tárhely, és onnantól a webshop levelei spambe kerülnek.
• DKIM: két CNAME (selector1, selector2), majd a Microsoft Defender portálon a DKIM bekapcsolása.
• MX: a Microsoft által megadott …mail.protection.outlook.com. Ilyenkor a postafiókok már nem a Hidden-nél vannak.
• A Microsoft 2026-tól fokozatosan kivezeti az alapszintű SMTP AUTH-ot. Ha a weboldala eddig a Microsoft 365 SMTP-jén keresztül küldött, érdemes visszaállni a Hidden-tárhely saját küldésére (PHP mail() vagy a Hidden SMTP), az include:spf.hidden.hu mellett.

Mailchimp / Mandrill

• A Mailchimp „Domains” oldalán a domain hitelesítése: CNAME DKIM rekordok és a megadott SPF-elem.
• Ha a domainen már van pontosabb DMARC rekord, azt a Hidden megtartja.

Mailgun

A Mailgunt mindig aldomainen használja (pl. mg.example.hu). Tipikus rekordok:

A feladó címe legyen az aldomainen (pl. [email protected]), vagy a fődomain SPF-ébe is kerüljön be a Mailgun include-ja. Különben egyes szűrők az eltérés (alignment) miatt visszadobják a levelet. A Hidden saját Mailgun-fiókjáról lásd: Hírlevél és tömeges küldés.

Saját levelezőszerver / irodai Exchange

• SPF: ip4:<a szerver publikus IP-je>.
• A szerveren legyen helyes reverse DNS (PTR) rekord, amely a szerver nevére mutat, és ez a név oldódjon vissza ugyanarra az IP-re. Ezt az internetszolgáltatója állítja be.
• DKIM: kulcspár a szerveren, a nyilvános kulcsot a Hidden veszi fel.

Ellenőrzés: átment-e a levél az SPF/DKIM/DMARC-on?

1. Küldjön egy levelet a saját domainjéről (abból a rendszerből, amelyet tesztelni szeretne!) egy Gmail-címre.

2. A Gmailben nyissa meg a levelet → ⋮ (Továbbiak) → Eredeti megjelenítése.

3. A fejlécben ezt kell látnia:

   Sor	Elvárt
   SPF	PASS
   DKIM	PASS (és a domain az Öné)
   DMARC	PASS

4. Ha valamelyik FAIL vagy NEUTRAL, küldje el a teljes „Eredeti” szöveget (vagy a .eml fájlt) a [email protected] címre.

Hasznos külső eszközök:

• MXToolbox: SPF/DKIM/DMARC lookup, tiltólista-ellenőrzés
• mail-tester.com: egy tesztcímre küldött levelet pontoz

Gyakori hibák

Gyakori kérdések

Mit kell beírnom az SPF-be, ha a weboldalam a saját domainem nevében küld leveleket? Az include:spf.hidden.hu elemet. A tipikus teljes rekord: v=spf1 mx include:spf.hidden.hu ~all. Ha a domain DNS-ét a Hidden kezeli, ezt a supporttól kérheti. Ha más szolgáltatónál van a DNS, ott kell módosítani, vagy átköltöztetheti a névszerver-kiszolgálást a Hidden által kezelt Cloudflare-fiókba.

Érdemes szigorítani a DMARC-ot (quarantine/reject)? Csak a riportok alapján, fokozatosan. Előbb minden legitim küldőnek (hírlevélrendszer, webshop, CRM, irodai szerver) szerepelnie kell az SPF-ben, és DKIM-mel kell aláírnia. Ha ez megvan, a szigorítás megakadályozza, hogy mások hamisított feladóval, az Ön domainje nevében küldjenek leveleket.

Spam jön a saját domainem nevében. Feltörték a postafiókomat? Nem feltétlenül. A feladó címét bárki hamisíthatja. A Hidden a naplóból meg tudja nézni, hogy volt-e bejelentkezés és küldés az adott fiókból. Ha nem volt, a feladó hamisított, és a DMARC szigorítása segít. Ha volt, lásd: Feltört postafiók.

A külső szolgáltató DKIM-rekordot kér. Honnan szerzem be? A szolgáltatótól. A kulcsot ő generálja, és a felületén kiírja a felveendő TXT vagy CNAME rekordokat. Ezeket küldje el a supportnak. A privát kulcs a szolgáltatónál marad, csak a nyilvános rész kerül a DNS-be.

Hidden-levelezésnél be kell állítanom a DKIM-et? Nem. A Hidden levelezőszervere (mail selector) aláírja a leveleket. Ha mégsem látja a DKIM: PASS eredményt, szóljon, és a Hidden pótolja a kulcsot.

Az SPF, DKIM és DMARC 100%-ban rendben van, mégis spambe kerülök. Miért? A technikai beállítás szükséges, de nem elégséges. A fogadók a tartalmat (marketingjelleg, linkek, képarány), a címzettek viselkedését (megnyitják, válaszolnak-e, jelölték-e korábban spamnek) és a küldési volument is figyelik. Lásd: Nem érkezik meg a levél és Hírlevél és tömeges küldés.

Kaphatok közvetlen hozzáférést a domain DNS-éhez? A DNS-t a Hidden kezeli. Változtatást a supporttól kérhet. Indokolt esetben (pl. egy fejlesztő sok rekordot állít be) egyeztessen a supporttal a hozzáférés módjáról.

Mennyi idő, amíg egy SPF/DKIM-változás érvénybe lép? A Cloudflare-ben általában perceken belül. A fogadók a régi értéket a TTL lejártáig (jellemzően néhány perc vagy legfeljebb néhány óra) gyorsítótárazhatják. A DMARC-riportokban a hatás 1–2 nap múlva látszik.

Kell DNSSEC, DANE vagy MTA-STS? Nem kötelező. A DNSSEC a Cloudflare-ben egyszerűen bekapcsolható, kérésre a Hidden beállítja. DANE-t és MTA-STS-t a Hidden nem javasol alapértelmezetten, mert kevés előnnyel és több üzemeltetési kockázattal járnak. Biztonsági audit esetén a javasolt sorrend: DMARC riportmódban, majd az SPF/DKIM finomítása, végül szigorítás.

Nem találta, amit keresett? Kérdezze az asszisztenst, vagy írjon a [email protected] címre.