Defaults.Exposed › Javítások › Guides

A továbbított e-mail meghibásodik az SPF-en — Miért nem javíthatja, és mi működik valójában (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.

Nem lehet az SPF-et átmenővé tenni a továbbított e-mailekhez — a továbbítás szándéka szerint tönkreteszi az SPF-et, és az őszinte javítás az igazított DKIM, amely megéli a továbbítást. A méret népszámlálásszintű: a Defaults.Exposed 261 millió domainre kiterjedő népszámlálása szerint 7,355,985 a 138,927,207 SPF-et közzétevő domain közül engedélyezi egyedül a Namecheap továbbítási include-ját, <0.1%-os szigorú-SPF-aránnyal.

Az alábbiakban: miért nem él túl egyetlen SPF-rekord sem a továbbítást, miért nem az Ön által irányított eszközök az SRS és az ARC, és a megoldás, amely tartós — DKIM-aláírás a saját domainjével, mint a DMARC-átmenet —, plusz az egyetlen eset, amely a DKIM-et is megtöri (üzenetet átíró levelezőlisták), és mit tegyen azzal a maradékkal.

Miért tönkreteszi a továbbítás az SPF-et?

A vevők az SPF-et a Return-Path (RFC5321.MailFrom) domain, nem a Feladó fejléc ellen értékelik. Közvetlen küldéskor a szervere IP-je az SPF-rekordjában van, és az ellenőrzés átmegy. Amikor a fogadó automatikusan továbbítja az üzenetet — személyes Gmailbe, egy egyetemi álnéven keresztül, egy regisztrátor továbbítási termékén keresztül —, a továbbító szervere továbbítja újra, általában megtartva a domainjét a Return-Pathon. A végső vevő most azt kérdezi: engedélyezett-e ez a továbbítószerver az Ön SPF-rekordjában?

Nem az, és soha nem lesz: Ön nem választotta a továbbítót, nem tudja, hogy létezik, és az ugyanazon üzenet egy eltérő szolgáltatáson holnap átmenve egy eltérő IP-ről bukna meg. Az SPF egyetlen kérdést válaszol meg — „az adott IP a Return-Path domain által engedélyezett szerverről jött?” —, és a továbbított levelek esetén az igaz válasz nem. A megbukás az SPF rendeltetésszerű működése, nem az Ön rekordja hibás.

A népszámlálás megmutatja, mennyire általános ez az útvonal: 7,355,985 domain engedélyezi a Namecheap e-mail-továbbítási include-ját (spf.efwd.registrar-servers.com) — egyetlen szolgáltató továbbítási termékét, a 139 millió SPF-közzétevőből kiindulva — <0.1%-os szigorú-SPF-aránnyal és csupán 0.2%-os DMARC-érvényesítéssel. Az a puha sablon nem gondatlanság: a továbbítás pontosan az a hely, ahol a szigorú -all rosszul sül el, és az a szolgáltató, amelynek terméke a továbbítás, ennek megfelelően szállít. A teljes minősítési történet a ~all vs -all jelentésünkben van, és a szolgáltatónkénti kép a legerősebb SPF alapértelmezéssel rendelkező e-mail-szolgáltatóban.

Nem adhatom hozzá a továbbító szerverét az SPF-rekordomhoz?

Nem — és a miért az egész cikk:

1. Nem tudja felsorolni a továbbítókat. Bármely fogadó, bárhol, bármilyen szolgáltatáson keresztül továbbíthatja a levelét. Az SPF-rekordjának olyan szervereket kellene felsorolnia, amelyeket előre nem tud.
2. A felsorolásuk legyőzné a célt. A nagy továbbítási szolgáltatások millió ügyfél levelét közvetítik. Helyezze a tartományaikat a rekordjába, és minden általuk az ügyfelek által közvetített üzenet — beleértve a hamisítóét is — átmegy az SPF-en Önként.

Ugyanez a logika kizárja a minősítő lazítását, hogy „a továbbítás működjön”: a minősítő nem az oka, hogy a továbbított levél megbukik, és ha a DMARC játékban van, kevesebbet változtat, mint a legtöbb útmutató állítja — lásd a minősítési adatokat. A rekord nem az itt lévő karok. Hagyja abba a húzogatást.

Mi van az SRS-sel és az ARC-cal — nem javítják ezek a továbbítást?

Foglalkoznak vele — de egyik sem az Ön által bevethető:

Adatok és mechanizmus-státusz: 2026-06-29.

Az SRS a továbbító SPF-problémáját tünteti el, nem az Önét: a Return-Path átírása megváltoztatja, kinek az SPF-je kerül ellenőrzésre, míg a Feladó fejléce — a DMARC által védett domain — érintetlen marad. Az ARC infrastruktúra-üzemeltetők közötti bizalmi döntés. Ha egy útmutató azt mondja, „vezessen be SRS-t” domain tulajdonosként, összetéveszti Önt a továbbítási szolgáltatóval.

Hogyan éljék túl a leveleim a továbbítást?

Tegye a domainjéhez igazított DKIM-et a DMARC-átmenettévé. Egy DKIM-aláírás az üzenet fejléceiben hordozott kriptográfia: ellenőriz, bárhova kerül az üzenet, bármennyi szerver közvetítette, ameddig az aláírt tartalom nem módosult. A DMARC-nak csak egy igazított átmenetre van szüksége — SPF vagy DKIM —, tehát amikor a továbbítás megöli az SPF-szárát, az igazított DKIM hitelesítetten tartja az üzenetet.

1. Futtassa az ingyenes vizsgálatot a defaults.exposed oldalon, mielőtt hozzányúl a DNS-hez. Megmutatja, van-e egyáltalán DKIM-je, a saját domainjével ír-e alá, és hol áll a DMARC-ja — tehát a valódi rést javítja, nem az SPF-rekordján harcol.
2. Erősítse meg, hogy a továbbítás ténylegesen a problémája. Az érintett üzenet Authentication-Results fejlécében a közvetlen levél átmegy az SPF-en, míg a továbbított példány megbukik a továbbítási szolgáltatás IP-jéről. Ha az SPF és a DKIM is átmegy, de a DMARC még mindig megbukik, igazítási problémája van — lásd: DMARC megbukik, de az SPF és a DKIM átmegy.
3. Kapcsolja be a DKIM-aláírást a saját domainjével minden küldési szolgáltatásnál — először a postafiók-szolgáltatónál, majd az ESP-knél és a tranzakciós küldőknél. A szolgáltatói alapértelmezések sokszor a szolgáltató domainjével írnak alá, amely nem igazodik; d=sajatdomain.hu értéket akar. Kezdje a DKIM javításával, kattintási útmutatókkal a Google Workspace-hez és a Microsoft 365-höz.
4. Ellenőrizze az igazítást, ne csak az átmenetet. Az aláírásban a d= domainnek egyeznie kell a Feladó domainjével; dkim=pass valaki más domainjén semmit sem jelent a DMARC-hoz.
5. Hagyja az SPF-rekordját úgy, ahogy van. Tartsa pontosan a közvetlen leveleihez — továbbra is hitelesíti a forgalma nagy részét, és a második DMARC-szárát is megmarad. Csak hagyja abba a próbálkozást, hogy lefedjen vele továbbítókat.
6. Futtassa újra a vizsgálatot, majd emelje tudatosan a DMARC-érvényesítést — következő rész, és a p=none-tól p=reject-ig terjedő bevezetési útmutató.

Ez a kombináció — SPF plusz igazított DKIM-re támaszkodó DMARC-érvényesítés — a továbbítás-biztos minta, és ritka: a ~all-t közzétevő 77.5 millió domain közül csupán 9.2% (7,116,774) támogatja érvényesítő DMARC-szabályzattal, és a 261 millió értékelt domain közül csupán 3.87% (10,092,481) teljesíti a teljes SPF + DKIM + érvényesített DMARC hármas feltételt a népszámlálás szerint (2026-06-29).

Mi van az üzeneteket átíró levelezőlistákkal?

Az az egy továbbítási útvonal, amelyet az igazított DKIM sem él túl: levelezőlisták, amelyek módosítják az üzenetet — [lista-neve] tárgycímke, leiratkozási lábléc, eltávolított melléklet. Változtassa meg az aláírt tartalmat, és a törzskivonat már nem egyezik, tehát a DKIM is megbukik (dkim=fail: body hash did not verify ennek saját útmutatója). Most mindkét DMARC-szár megbukott, és csak a lista enyhíthet (Feladó átírásával, ARC lepecsételéssel).

Ez a maradék pontosan az, amire a szakaszos DMARC-érvényesítés való. A p=quarantine-on való áthaladás pct emelkedéssel, miközben az összesítő jelentéseket figyeli, megmutatja, hogy a valódi forgalmának mekkora része folyik átíró listákon keresztül, mielőtt egy p=reject szabályzat megkezdi a visszapattintást. Ne ugorjon azonnal elutasításra egy olyan domainnél, amelynek felhasználói levelezőlistákon élnek; de ne stagnáljon örökre a p=none-nál sem. A szakaszos bevezetési útmutató végigvezeti az emelkedésen.

Gyakran ismételt kérdések

A továbbítás a DKIM-et is megtöri? Egyszerű továbbítás esetén nem: az aláírás az üzenettel utazik, és a végső vevőnél is ellenőriz. A DKIM csak akkor törik meg, ha a szállítás közben módosítják az aláírt tartalmat — levelezőlista tárgycímkék és láblécek az ős eset —, ezért a lista maradékát a DMARC-szabályzat szakaszolásával kezelik, nem a DNS-ben lévő semmivel.

Váltsak -all-ról ~all-ra, hogy a továbbítás ne bukjon meg? A minősítő megváltoztatása nem teszi az átirányítókat átmenetvé — nem ezért buknak meg. Árulkodó, hogy a Namecheap továbbítási include-ja, 7,355,985 domain és a népszámlálás legnagyobb dedikált-továbbítási populációja (2026-06-29), <0.1%-os szigorú-SPF-aránnyal szállít: a puha SPF vitathatatóan a helyes sablon egy továbbítási termékhez. Lásd a ~all vs -all jelentést arra vonatkozóan, mit változtat ténylegesen a minősítő.

Miért megy át a levelem az SPF-en közvetlenül küldve, de buksz meg, ha valaki továbbítja? A vevő ellenőrzi, hogy az utolsó továbbító szerver IP-je engedélyezett-e a Return-Path domain SPF-rekordjában. Közvetlen: az Ön szervere, az Ön rekordjában, átmegy. Továbbított: a továbbító szervere, nem az Ön rekordjában, megbukik. A rekordja nem változott — az továbbító IP változott.

Be tudom-e állítani az SRS-t a javításhoz? Csak ha Ön a továbbító. Az SRS a továbbítást végző szerveren fut, és még ahol fut is, az eredő SPF-átmenet a továbbító domainjéhez tartozik, és nem igazodik a Feladóhoz — a DMARC-nak még mindig szüksége van a DKIM-szárra.

Az SPF értelmetlen, ha a továbbítás mégis megtöri? Nem. A legtöbb levél közvetlenül kézbesül, ahol az SPF pontosan az előírásoknak megfelelően működik, és az SPF az egyik DMARC-szárán marad. A 261,086,232 domain 2026-06-29 dátumú népszámlálásában 138,927,207 tesz közzé SPF-et — tartsa pontosan a SPF javítási oldalon keresztül, és hagyja a DKIM-et vinni a továbbított maradékot.

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. Amint az egyéni domainre szóló DKIM él és a DMARC szakaszolva van, futtassa újra az ingyenes vizsgálatot, és küldje el az értékelt jelentést a vállalkozás tulajdonosának: keltezve, közérthető nyelven, megmutatja, hogy a domain hitelesítve marad még a forwarding esetén is. Ez a dokumentum a kibervédelmi biztosítás megújításakor és a következő szállítói kérdőívnél — dokumentált előtte-utána, nem „bekapcsoltam valamit”.

Ellenőrizze a domainjét → · DMARC megbukik, de az SPF és a DKIM átmegy → · DKIM javítása → · Hogyan értékelünk → · Csak összesített adatok. Az adatokat az EU-ban tároljuk és dolgozzuk fel.