Defaults.Exposed

Defaults.ExposedJavításokGuides

A DKIM átmegy, de a DMARC megbukik: A gappssmtp.com / onmicrosoft.com alapértelmezett aláírás csapdája (2026)

Közzétéve 2026-07-08

Adatok: 2026-06-29 · 7. módszertan. Összesített népszámlálási adatok 261 millió értékelt domain alapján. Lásd: hogyan értékelünk.

A levele átmegy a DKIM-en a szolgáltató alapértelmezett aláírásával — a d= a gappssmtp.com-ra (Google Workspace) vagy az onmicrosoft.com-ra (Microsoft 365) végződik —, de ez a domain nem egyezik a Feladó domainjével, így a DMARC nem kap igazított átmenetet. Engedélyezze az egyéni domainre szóló aláírást a javításhoz. A 261,086,232 értékelt domain Defaults.Exposed-népszámlálása szerint a Google levelezőszervereit engedélyező 12,145,313 domain közül csupán 18.5% érvényesíti a DMARC-ot.

A javítás az e-mail-hitelesítés egyik legegyszerűbbje: kapcsolja be az egyéni domainre szóló DKIM-aláírást. Google Workspace esetén ez az Admin konzol „E-mail hitelesítése” képernyője — generálja a kulcsot, tegyen közzé egy TXT-rekordot, kapcsolja be. Microsoft 365 esetén a Defender-portál DKIM-oldala — tegyen közzé két selector CNAME-et, engedélyezze. Húsz perces munka, és a DMARC végre megkapja a rég várt igazított átmenetet.

Miért megy át a DKIM, de bukik meg a DMARC?

Mert a DMARC nem azt kérdezi: „van érvényes DKIM-aláírás?” — azt kérdezi: „van érvényes DKIM-aláírás a Feladó fejlécben szereplő domainhez?” Ezt a második feltételt igazításnak nevezik, és ez a DMARC teljes lényege: annak bizonyítása, hogy az a domain, amelyet a vevő lát, az a domain, amely aláírt.

Alapból a Google Workspace egy olyan domainnel írja alá a leveleit, mint sajatdomain-hu.20230601.gappssmtp.com (a dátumbélyeg domainenként változik), a Microsoft 365 pedig a sajatberlo.onmicrosoft.com értékkel. Mindkét aláírás kriptográfiailag érvényes — a DKIM-ellenőrzők átmentet mutatnak —, de a d= domain a Google-é vagy a Microsofté, nem az Öné. A DMARC laza igazítása alatt is, amely csak a szervezeti domaineket egyeztetni kénytelen, a gappssmtp.com nem azonos a sajatdomain.hu-val. Nincs egyezés, nincs igazított átmenet, és ha az SPF sem igazodik (ami sokszor nem lehetséges — a vevők a Return-Path domain ellen értékelik az SPF-et, nem a Feladó fejléc ellen, és a továbbítás teljesen megtöri), a DMARC megbukik.

Ez a szolgáltatói alapértelmezések meghatározó csapdája: az alapértelmezés kézbesíthetőséget ad, nem védelmet — az igazítás a hiányzó kulcsfordítás. A népszámlálás megmutatja, hány küldő áll meg az alapértelmezésnél: a 12,145,313 domain közül, amelyek a _spf.google.com-on keresztül engedélyezik a Google levelezőszervereit (az összes 138,927,207 SPF-közzétevőből világszerte), csak 18.5% érvényesíti a DMARC-ot. A Microsoft képe ugyanolyan: 10,205,070 domain engedélyezi az spf.protection.outlook.com-ot, 85.0% rendelkezik az M365-beállítás által megadott szigorú SPF-rekorddal — és csupán 21.7% érvényesíti a DMARC-ot. Teljes összehasonlítás az e-mail-szolgáltatói SPF-bajnoki táblázatunkban.

A csapda láthatatlan a napi használatban: a levelek kézbesülnek, a postafiók-tesztek jók, semmi nem hibázik — egészen addig, amíg közzétesz egy DMARC-szabályzatot, és a saját levelei kezdenek megbukni rajta. Az ingyenes vizsgálatunk pontosan ezt a rést tárja fel.

Hogyan veszem észre az alapértelmezett aláírás csapdáját az Authentication-Results fejlécben?

Nyisson meg egy elküldött üzenetet (egy Gmail- vagy Outlook-postafiókban), tekintse meg az eredeti/nyers forrást, és keresse meg az Authentication-Results fejlécet. Az árulkodó jel egy DKIM-átmenet a rossz d= értékkel — Gmail által fogadott példa:

Authentication-Results: mx.google.com;
       dkim=pass [email protected];
       spf=pass smtp.mailfrom=sajatdomain.hu;
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=sajatdomain.hu

Olvassa el három kérdés formájában:

FejlécrészletMit jelentÍtélet
dkim=pass header.d=sajatdomain.huAz aláírás érvényes ÉS egyezik a Feladó domainjévelIgazított — ez a cél
dkim=pass header.d=…gappssmtp.com vagy …onmicrosoft.comAz aláírás érvényes, de a szolgáltató alapértelmezett domainje — a DMARC igazítás szempontjából figyelmen kívül hagyjaA csapda: átmenet védelem nélkül
dkim=fail (bármilyen d=)Az aláírás érvénytelen — eltérő problémaLásd: hogyan javítsa a DKIM-et

Microsoft által fogadott levélen ugyanez a dkim=pass (signature was verified) header.d=sajatberlo.onmicrosoft.com értékként jelenik meg a compauth=fail mellett — az Outlook visszautasítási útmutatóban ismertetett minta.

Ha a fejléce ehelyett mindkét dkim=pass és spf=pass értéket mutatja DMARC-megbukással, a tágabb igazítási esetben van — a DMARC megbukik, de az SPF és a DKIM átmegy útmutató végigvezeti a laza és szigorú igazítást teljes részletességgel.

Hogyan engedélyezem az egyéni domainre szóló DKIM-aláírást?

  1. Futtassa az ingyenes vizsgálatot a defaults.exposed oldalon, mielőtt hozzányúl bármihez. Megmutatja, hogy a domainje rendelkezik-e igazított DKIM-mel, mi a DMARC-szabályzata valójában, és van-e más dolog (SPF, DMARC-rekordszintaxis), amely még mindig blokkolná e javítás után — így egyszerre végzi el az egész munkát.
  2. Azonosítsa, melyik alapértelmezéssel ír alá. Ellenőrizze a header.d= értékét az Authentication-Results fejlécben a fentiek szerint: gappssmtp.com = Google Workspace alapértelmezés, onmicrosoft.com = Microsoft 365 alapértelmezés.
  3. Google Workspace: generálja és tegye közzé a saját kulcsát. Az Admin konzolban menjen az Alkalmazások → Google Workspace → Gmail → E-mail hitelesítése menüpontra, válassza ki a domainjét, és kattintson az Új rekord generálása gombra (2048 bites, hacsak a DNS-gazdagép nem tudja tárolni). Tegye közzé az adott TXT-rekordot a google._domainkey.sajatdomain.hu névnél, várjon a DNS-re (legfeljebb 48 óra), majd — a lépés, amelyet mindenki kihagyott — kattintson a Hitelesítés indítása gombra. A rekord generálása semmit sem csinál, amíg be nem kapcsolja az aláírást. Teljes útmutató: DKIM beállítása Google Workspace-en.
  4. Microsoft 365: tegye közzé mindkét selector CNAME-et, és engedélyezze. A Defender-portálban menjen az E-mail és együttműködés → Szabályzatok és szabályok → Veszélyzeti szabályzatok → E-mail hitelesítési beállítások → DKIM menüpontra, válassza ki az egyéni domainjét, és hozza létre a kulcsokat. Tegyen közzé mindkét CNAME-et — selector1._domainkey és selector2._domainkey, amelyek a Microsoft által megjelenített célokra mutatnak (másolja át a pontos célokat a portálról — a 2025. május előtt engedélyezett domainek a bérlő .onmicrosoft.com-jára végződnek; az újabbak .dkim.mail.microsoft-ra) —, majd kapcsolja be az aláírást. Két selector nem opcionális: a Microsoft közöttük rotálja a kulcsokat. Teljes útmutató: DKIM beállítása Microsoft 365-ön.
  5. Ellenőrizze az új aláírást. Küldjön egy friss üzenetet egy külső postafiókba, és ellenőrizze újra az Authentication-Results fejlécet: a dkim=pass most a header.d=sajatdomain.hu értéket kell, hogy mutassa. Ha a DNS-panel automatikusan hozzáfűzte a zónát a CNAME-célhoz, vagy megrongálta a hosszú TXT-értéket, az aláírás nem vált át — panelfurcsaságok, nem a szolgáltató okozza a legtöbb hibát.
  6. Futtassa újra a vizsgálatot, és hasznosítsa az igazított átmenetet. Erősítse meg, hogy a vizsgálat igazított DKIM-et mutat, majd használja fel: a p=none DMARC-szabályzat semmit sem véd. Az összes 261,086,232 értékelt domain közül csupán 10.59% érvényesíti a DMARC-ot (adatok: 2026-06-29) — az igazított DKIM az, ami biztonságossá teszi az érvényesítést. Kezdje a DMARC javítása oldalon.

Az egyéni DKIM engedélyezése tönkretesz-e valamit?

Nem — ez az e-mail-hitelesítés egyik ritka javítása, amelynek lényegében nincs határa: az alapértelmezett aláírással kimenő levelek egyszerűen jobb aláírással mennek ki, és a szolgáltató kezeli tovább a kulcsokat (a Microsoft automatikusan rotálja a két selector között). A valódi hibamód a félkész megvalósítás — a Google TXT-jének közzéteszi, de soha nem kattint a Hitelesítés indítása gombra, vagy csak az egyik M365 selectort teszi közzé mindkettő helyett. Ne törölje a DNS-rekordokat később a „rendbetétel” jegyében; az aláírás azonnal leáll, amint a kulcs eltűnik.

Egy terjedelmi megjegyzés: ez a Google-on vagy Microsofton keresztül küldött leveleket javítja. A hírlevéleszközök és CRM-ek is aláírnak a saját alapértelmezéseikkel, és mindegyikhez be kell kapcsolni az egyéni domainre szóló DKIM-et — ezt a mintát, és a Gmail tömeges küldőkre vonatkozó szabályait, amelyek most ezt követelik meg, a 550-5.7.26 útmutató ismerteti.

Gyakran ismételt kérdések

A DKIM minden teszteszközön „átmegy” — miért kell bármit javítani? Mert az eszközök szűkebb kérdést válaszolnak meg, mint a DMARC. Az aláírás érvényes — de a gappssmtp.com-é vagy az onmicrosoft.com-é, nem az Öné, tehát a DMARC-igazítás szempontjából semmit sem ér. Ezért állnak meg annyian az alapértelmezésnél: a 12,145,313 Google-t engedélyező domain közül csupán 18.5% érvényesíti a DMARC-ot (adatok: 2026-06-29).

A laza DMARC-igazítás átengedi-e az alapértelmezett aláírást? Nem. A laza igazítás csak a szervezeti domainekhez lazítja az egyezést — a mail.sajatdomain.hu igazodik a sajatdomain.hu-hoz. Az alapértelmezett aláírás szervezeti domainje a gappssmtp.com vagy az onmicrosoft.com, amelynek semmi köze az Önéhez. Egyetlen igazítási mód sem menti meg a harmadik féltől származó d= értéket.

A gappssmtp.com / onmicrosoft.com aláírás rossz? El kellene távolítanom? Nem rossz — biztosítja, hogy a levele valamilyen érvényes aláírást hordozzon, ami segít a spam-szűrésben. Csak nem az Öné. Nem eltávolítja, hanem felváltja, ha engedélyezi az egyéni domainre szóló aláírást.

A domainjem Microsoft 365-ön van szigorú SPF-fel — már védett vagyok? Valószínűleg nem: az a szigorú rekord az M365 alapértelmezésének egész munkája. A 10,205,070 domain közül, amelyek engedélyezik az spf.protection.outlook.com-ot, 85.0% rendelkezik szigorú SPF-fel, de csupán 21.7% érvényesíti a DMARC-ot (adatok: 2026-06-29). Az SPF a továbbítás során is megbukik, mert a Return-Path, nem a Feladó fejléc ellen értékelik — az igazított DKIM az a szár, amely megmarad, ezért fontos ez a javítás.

Mennyi ideig tart a javítás? A konzolon végzett munka percek szolgáltatónként. A DNS jelenti a várakozást: a Google szerint engedélyezzük legfeljebb 48 órát a hitelesítés indítása előtt; a Microsoft CNAME-jei általában órákon belül élőek. Számítson egy munkanapra a végétől a végéig, amelynek nagy részét várakozással tölti.

Küldje el a tulajdonosnak a jelentést

Ha egy ügyfélért vagy munkaadójáért végzi a javítást, zárja le a kört bizonyítékkal. Futtassa újra az ingyenes vizsgálatot miután az új aláírás él, és küldje el az értékelt jelentést a vállalkozás tulajdonosának: keltezve, közérthető nyelven, a DKIM a domainjükkel igazítva látható. Ez a dokumentum a kibervédelmi biztosítás megújításakor és a következő szállítói biztonsági kérdőívnél — annak bizonyítéka, hogy a domain önmagaként hitelesít, nem a gappssmtp.com albérlőjeként.

Ellenőrizze a DKIM-igazítást ingyen

Tekintse meg, hogy a levele a saját domainjéként ír-e alá — és pontosan mit kell javítani —, privát módon és csak a tulajdonosra vonatkozóan.

Ellenőrizze a domainjét → · DMARC megbukik, de az SPF és a DKIM átmegy → · DKIM javítása → · DKIM beállítása Google Workspace-en → · Csak összesített adatok. Az adatokat az EU-ban tároljuk és dolgozzuk fel.