Az SPF meghibásodott a levelezési szolgáltató váltása után — A migrációs javítás (2026)

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

Adatok: 2026-06-29 · módszertan v7. Összesített adatok 261 millió értékelt domain felmérése alapján. Lásd: hogyan értékeltük az internetet.

Az SPF általában azért hibásodik meg e-mail-szolgáltató váltása után, mert az új szolgáltató rekordját a régi mellé adták hozzá. Két v=spf1 rekord permanens hiba — az SPF teljesen érvénytelen lesz. 1,013,416 domain — nagyjából minden 138-ból egy, amelyek megpróbálnak SPF-et alkalmazni — van ebben az állapotban a Defaults.Exposed 261 millió doménből álló felmérése szerint. Egyesítse őket egybe.

A javítás nagyjából tíz percet vesz igénybe: vizsgálja meg a domént, hogy pontosan lássa, mit hagyott maga után a migráció; listázza az összes SPF-rekordot az autoritatív névszerverein; egyesítse azokat egyetlen, csak az új szolgáltatót tartalmazó rekordba; és ellenőrizze újra dig segítségével. Ez az útmutató végigvezeti az egyes lépéseken, beleértve a DKIM- és névszerver-ellenőrzéseket, amelyekről a legtöbb migráció megfeledkezik.

Miért hibásodott meg az SPF közvetlenül a migráció után?

Mert az új szolgáltató beállítási útmutatója azt mondta: „adja hozzá ezt a TXT-rekordot” — és Ön meg is tette, a régi mellé. Ez az egyetlen dolog, amit az SPF-szabvány nem engedélyez. Az RFC 7208 (§3.2, a hibaeredményt a §4.5 írja elő) dománenként pontosan egy v=spf1 rekordot engedélyez; egy fogadó, amely kettőt vagy többet talál, PermError-t kell visszaadjon ahelyett, hogy kitalálja, melyik az autoritatív. A PermError azt jelenti, hogy az SPF érvénytelen: nem a régi rekord, nem az új, egyáltalán nincs SPF.

És ez nem ér véget ott. A DMARC a PermError-t az SPF-lábon való megbukásként kezeli, tehát a levelei mostantól teljesen a DKIM-re támaszkodnak. Ha az új szolgáltató DKIM-je sincs még beállítva — ami a migráció közepén gyakori —, pontosan akkor küld hitelesítetlenül, amikor az infrastruktúrát megváltoztatta, ami az a pillanat, amikor a fogadók a legkritikusabban szemlélik.

Ez a másolat-beillesztés, amely érvényteleníti a védelmet a váltáskor, és egyáltalán nem ritka: 1,013,416 domain tesz közzé most is két vagy több SPF-rekordot — nagyjából minden 138-ból egy az SPF-et megkísérlő 139 milliós populációból, a Defaults.Exposed 261 millió doménes felmérése szerint (adatok: 2026-06-29). A két rekord csapdájának teljes számaihoz külön riport tartozik; ez az oldal az eljárási javítás.

Mit hagyott maga után a migráció?

Öt maradék okozza szinte az összes migrációt követő SPF-hibát. Ellenőrizze őket ebben a sorrendben:

Mi maradt vissza	Mit lát	A javítás
A régi SPF-rekord, még mindig DNS-ben az új mellett (két `v=spf1` rekord)	Az ellenőrzők „több SPF-rekordot” vagy PermError-t jeleznek; az SPF teljesen leáll	Egyesítse egy rekordba, törölje a többit — lásd az alábbi lépéseket
A régi szolgáltató `include:`-ja az egyetlen rekordban	Az SPF működik, de DNS-keresési helyeket pazarol, és a régi szolgáltató szerverei továbbra is küldhetnek az Ön nevében	Távolítsa el, ha a levelezés teljesen átállt az új rendszerre
Az új szolgáltató `include:`-ja soha nem lett hozzáadva	Az új szolgáltatótól érkező levelek megbuknak SPF-en a fogadóknál	Adja hozzá a meglévő egyetlen rekordhoz — soha ne új rekordként
Az új szolgáltatóhoz nem lettek DKIM-selectorok létrehozva	`dkim=fail` vagy aláírások a szolgáltató alapértelmezett doménjéről; a DMARC-nak nincs második lába	Tegye közzé az új selectorokat — lásd a 6. lépést alább
A rekord csak a régi névszervereken lett frissítve	Eltérő válaszok attól függően, kit kérdez; időszakos hibák	Javítsa a zónát az autoritatív névszervereken; ellenőrizze mindkét készletet az átváltás során

Hogyan javítsam? A migrációs ellenőrzőlista

Először futtassa az ingyenes vizsgálatot a defaults.exposed oldalon. Olvassa a live DNS-t, és megmondja, van-e több SPF-rekordja, hiányzó include, vagy DKIM-rés — diagnosztizáljon, mielőtt bármihez hozzányúl.
Listázza az összes SPF-rekordot az autoritatív névszervereken. dig +short NS sajatdomain.hu, majd dig +short TXT sajatdomain.hu @<névszerver> az egyikükkel szemben. Számolja meg a v=spf1 értékkel kezdődő sorokat. Az egyetlen biztonságos szám 1.
Egyesítse egyetlen rekordba. Egy rekord, v=spf1-gyel kezdve, amely tartalmazza az új szolgáltató include-ját és minden más küldőt, amelyet még használ (számlázóeszköz, CRM, hírlevélplatform), egyetlen záró -all vagy ~all értékkel. Példa — régi Google Workspace, új Microsoft 365, kiürítés közben:
```
Előtte:  "v=spf1 include:_spf.google.com ~all"
         "v=spf1 include:spf.protection.outlook.com -all"

Utána:   "v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all"
Később:  "v=spf1 include:spf.protection.outlook.com -all"
```
A szolgáltatói értékek és a DNS-kezelő felület sajátosságai a Google Workspace és a Microsoft 365 beállítási útmutatóiban találhatók.
Törölje a felesleges rekordokat. Az egyesítés törlés nélkül semmit sem old meg — a PermError a számból adódik.
A régi szolgáltató include-ját csak addig tartsa meg, amíg a régi rendszer még küld — ütemezett riportok, régi CRM-összekötő, elfelejtett postafiók. Ha a kiürítés megtörtént, távolítsa el: az elavult include megengedi, hogy a régi infrastruktúra továbbra is küldjön az Ön nevében, és minden include DNS-kereséseket emészt az SPF 10-es keménykorlátjából — legalább 797,263 domain érvénytelenítette így az SPF-jét (felmérés, 2026-06-29).
Állítsa be az új szolgáltató DKIM-jét — de a régi selectorokat egyelőre ne törölje. Az új selectorok az új leveleket írják alá; a régieket addig kell megtartani, amíg az általuk aláírt összes üzenet kézbesítésre nem kerül és a továbbítások le nem csengnek. Teljes útmutató: A DKIM meghibásodik az e-mail-eszközök váltása után.
Ha névszervert is váltott, ellenőrizze mindkettőt. A DNS-migrációk gyakran az e-mail-migrációkkal együtt járnak. Kérdezze le közvetlenül a régi és az új NS-készletet (dig TXT sajatdomain.hu @regi-ns és @uj-ns) — amíg a regisztrátor-delegáció teljesen el nem terjed, egyes fogadók még a régi szervereket kérdezik, tehát a javított rekordnak léteznie kell abban a készletben is, amely válaszol.
Futtassa újra a vizsgálatot, és erősítse meg, hogy az SPF egyetlen érvényes rekordot mutat átmenéssel.

Valójában melyik domént ellenőrzi az SPF?

A fogadók az SPF-et a Return-Path (RFC5321.MailFrom) doménnel szemben értékelik — a visszapattanási cím doménjével —, nem a From fejlécével, amelyet a címzettjei látnak. A migráció után ez kétszeresen fontos: az új szolgáltatója saját visszapattanási domént használhat, amíg Ön nem konfigurál egyedit, és az SPF „átmenése” egy nem-saját domén esetén nem igazodik a DMARC számára. Az erre való megoldás az új szolgáltató DKIM-je, a saját doménjével aláírva.

Egyidejű migráció és rebrandelés?

Megváltoztatta a domént is a szolgáltató mellett? Kezelje őket két külön feladatként. Az új domén az első naptól teljes stacket igényel — SPF, DKIM, DMARC; használja az új domain e-mail-ellenőrzőlistáját. A régi domain addig marad hitelesített, amíg átirányítás vagy válaszkommunikáció fut rajta, és miután parkolóba helyeződik, kifejezetten zárolni kell (nem csak elhagyni). Egy maradék, félig törött SPF-fű régi domain hamisítási célponttá válik a volt neve alatt.

Gyakran ismételt kérdések

Megtarthatom a két SPF-rekordot a migráció alatt? Nem. A szabványban nincs türelmi idő — két v=spf1 rekord a másodiknak létezése pillanatától PermError, és 1,013,416 domain ül ebben az állapotban a felmérés szerint (2026-06-29). A migrációhoz biztonságos minta az, ha az átfedési időszak alatt egy rekordban mindkét szolgáltató include-ja szerepel.

Meddig tartsam meg a régi szolgáltató include-ját? Addig, amíg semmi sem küld a régi szolgáltatón keresztül — általában az átfedési ablak hosszáig, napokig vagy néhány hétig. Figyelje a régi rendszeren keresztül még érkező levelek Return-Path-jét; ha ez a forgalom leáll, távolítsa el az include-ot, és ellenőrizze újra a keresési számot.

Miért mutatja még az ellenőrző a régi rekordot a javítás után? A DNS-gyorsítótárazás tiszteletben tartja a rekord TTL-jét, és ha változtak a névszerverei, egyes feloldók még a régi készletet kérdezik. Ellenőrizze közvetlenül az autoritatív névszervereknél a dig TXT sajatdomain.hu @<ns> paranccsal — ha az ott lévő válasz helyes, a javítás kész, és a gyorsítótárak frissülni fognak. Ha az egyik NS-készletnél rossz, lásd: „SPF-rekord nem található” — a valódi okok.

Kell-e módosítani a DMARC-ot a váltáskor? Általában magát a rekordot nem — ez tartalmazza a riport-postafiókját és a házirendet, nem a szolgáltatóját. A DMARC eredményei azonban az imént migrált SPF-től és DKIM-től függnek: számítson a riportok csökkenésére az átváltás alatt, és győződjön meg arról, hogy mindkét ág átmegy, mielőtt szigorítaná a házirendet. Kezdje az SPF javításával, ha a vizsgálat azt mutatja, hogy az SPF-ág még mindig megbukik.

Küldje el a riportot a tulajdonosnak

Ha Ön végzi ezt a migrációt egy ügyfél számára, fejezze be bizonyítékkal. Futtassa újra az ingyenes vizsgálatot, miután az egyesítés él, és továbbítsa az értékelt riportot az üzlettulajdonosnak: SPF, DKIM és DMARC átmegy az új szolgáltatónál, közérthető nyelven, dátumozva. Ez az a dokumentum, amelyet a kiberbiztosítás-megújításhoz és a következő szállítói biztonsági kérdőívhez tárolnak — bizonyíték arra, hogy a migráció a doménnek a korábbinál jobb hitelesítést hagyott maga után.

Ellenőrizze a doménjét → · A DKIM meghibásodik az e-mail-eszközök váltása után → · „SPF-rekord nem található” — a valódi okok → · Hogyan értékeltük → · Csak összesített adatok. Az adatok tárolása és feldolgozása az EU-ban történik.