A megszakítás nélküli migráció azt jelenti, hogy minden, az Ön domainjére küldött üzenet megérkezik egy postafiókba, és az átállás napján minden munkatárs tud írni a partnereinek. Nem azt jelenti, hogy az előzmények, a mobileszközök és a megszokások egyetlen mozdulat nélkül átállnak.
Két platform működik párhuzamosan.
A tipikus rés abból adódik, hogy az MX-et akkor állítják át, amikor egy másolás még nem teljes, vagy hogy egy multifunkciós nyomtató, egy weboldal vagy egy CRM még a régi azonosítóval küld leveleket.
Az MX egy DNS-rekord: megmondja a küldő szervereknek, hová kézbesítsék az Ön domainjének leveleit. Az e-mail-szolgáltatás váltása mindenekelőtt ennek a kézbesítési címnek a megváltoztatását jelenti. Minden más (fiókok, előzmények, eszközök) e köré szerveződik.
Az SMTP protokoll jól tűri a rövid fennakadásokat. Az a küldő szerver, amely ideiglenes hibát kap, várólistán tartja az üzenetet, és később újra próbálkozik. Egy átmenetileg elérhetetlen szerver tehát nem okoz levélvesztést. Egy végleges hiba (ismeretlen postafiók, elutasított üzenet) viszont visszaküldi az üzenetet a feladónak, és ez az üzenet magától soha nem fog megérkezni. Az átállás fő kockázata nem a kiesés, hanem az, hogy az új platform elutasít egy címzettet, mert egy aliast vagy egy listát nem hoztak létre újra.
A TTL (élettartam) határozza meg, mennyi ideig tarthat egy DNS-feloldó egy választ a gyorsítótárában. Ez idő alatt a küldők egy része még a régi platformra kézbesít. Ez normális, és éppen ezért kell a régi platformnak az átmenet alatt fogadóképesnek maradnia.
Két héttel előtte. A postafiókok, aliasok, listák, megosztott postafiókok és minden levelet küldő alkalmazás leltára. Az MX DNS TTL-értékének csökkentése rövid értékre (gyakran 300 másodpercre), hogy az átállás napján a változás gyorsan terjedjen. A célfiókok létrehozása. Az előzmények első másolása.
A TTL-t korán kell csökkenteni, mert az a feloldó, amely a régi értéket olvasta, annak lejártáig megtartja: a rövid TTL csak a régi gyorsítótár lejárta után lép életbe. Az első másolás a leghosszabb; ha korán indítják, marad idő felfedezni a problémás postafiókokat.
Néhány nappal előtte. Egy minta ellenőrzése: üzenetek száma, mappák vagy címkék, naptári események, névjegyek. A módszer javítása, ha a minta nem felel meg. A mobil- és Outlook-útmutatók előkészítése. Küldési teszt a célplatformról Gmail- és Outlook.com-címekre, úgy, hogy az SPF, a DKIM és a DMARC már érvényes az új platformon. Ezek a rekordok az MX előtt is közzétehetők.
A gyakorlatban: egyetlen SPF-rekord, amely az átmenet idejére mindkét platformot engedélyezi (két külön SPF-rekord esetén az ellenőrzés sikertelen), az új platform DKIM-kulcsa a saját szelektora alatt közzétéve, a régi mellett, valamint egy átnézett DMARC-szabályzat. A DMARC megköveteli, hogy az üzenetet a feladó domainjének nevében SPF vagy DKIM hitelesítse; ha az Ön szabályzata szigorú, és a célplatform még nincs engedélyezve, a partnerei elutasítják az Ön üzeneteit.
Az előző napon. Második átmásolás: csak az első másolás óta érkezett tartalom másolása. Az aliasok és listák módosításának befagyasztása.
Az átállás napján. Az MX átállítása. Azonnali külső ellenőrzés: egy külső, magán-postafiókból küldött levélnek a TTL időtartamán belül meg kell érkeznie az új platformra. A várólista figyelése. A levelet küldő alkalmazások átkonfigurálása. Kijelölt belső ügyfélszolgálat, amely jogosult visszaállítani az MX-et, ha egy kritikus levélforgalom meghiúsul.
Ezzel egy időben módosítsa az autodiscover rekordot is, ha létezik: az Outlook ezt kérdezi le, hogy megtalálja a szerverét. Távolítsa el azokat a másodlagos MX-rekordokat is, amelyek még a régi platformra mutatnának: az a küldő, amely nem éri el az elsődleges MX-et, a következőkkel próbálkozik.
A következő napokban. A régi platform csak olvasható. Az eltérések jelzése (egy hiányzó mappa, egy megosztott postafiók). Szükség esetén harmadik, célzott átmásolás. Ezután a küldés lezárása a régi platformon, hogy egy munkatárs se válaszoljon két helyről.
Ennek az utolsó lépésnek technikai oka van. A régi platform továbbra is felelősnek tekinti magát az Ön domainjéért: az onnan egy kollégának küldött üzenetet helyben kézbesíti, az MX lekérdezése nélkül. A kolléga soha nem fogja látni az új postafiókjában.
| Kockázat | Mi történik | Ellenszer |
|---|---|---|
| Túl korán átállított MX | Az új levelek megérkeznek, az előzmények hiányoznak | Átállás a minta ellenőrzése és a második átmásolás után |
| Elfelejtett alias vagy lista | A célplatform véglegesen elutasítja ezeket az üzeneteket | Leltár, az aliasok befagyasztása az előző napon, a közös címek tesztelése |
| Hiányos SPF, DKIM vagy DMARC | A partnereknél az Ön üzeneteit elutasítják vagy levélszemétnek minősítik | Közzététel az átállás napja előtt, ellenőrzés valós üzeneten |
| A régi fiókkal küldő alkalmazás | Számlák, riasztások vagy szkennelt dokumentumok nem mennek ki | Az alkalmazások listája, az új SMTP-szerver beállítása az átállás napján |
| A régi platformon nyitva maradt küldés | Belső üzenetek a régi rendszerben maradnak | A küldés lezárása, amint a minta jóváhagyást kapott |
| Előkészítetlen visszaállás | Az MX visszaáll, de a közben érkezett üzenetek a célplatformon maradnak | Írásos terv, e üzenetek visszavételével együtt |
Vegyünk szemléltetésként egy 40 fős irodát. Az átállást csütörtök késő délutánra időzíti péntek helyett: másnap a csapat jelen van az eltérések kezelésére, és a belső ügyfélszolgálat előtt egy teljes munkanap áll. A recepció multifunkciós nyomtatóját, amely e-mailbe szkennel, még aznap este átkonfigurálják. Ha két megosztott postafiókban hiányzó mappát jeleznek, egy célzott átmásolás pótolja. Ebben a forgatókönyvben egyetlen üzenet sem vész el, de több munkatársnak újra be kell állítania a fiókját a telefonján: ez az a látható rész, amelyet előre be kell jelenteni.
Szervert váltanak az Outlookban vagy a mobilon. Egy nagy postafiók első betöltése időbe telik. A telefonon már gyorsítótárazott üzenetek megduplázódhatnak, ha a profilt nem állítják be újra rendesen. Készítsen eljárást „fiók törlése és újbóli létrehozása” formában a szerverbeállítások rögtönzött átírása helyett.
Az Outlook esetében is ugyanez az ok: a profil a régi szerverhez kötött helyi gyorsítótárat őriz. Egy új profil tiszta állapotból indul; egy módosított régi profil összekeveri a két világot. Mobilon a használt protokoll (a célplatformtól függően Exchange ActiveSync vagy IMAP) olykor a platformmal együtt változik, ami még egy ok a fiók újbóli létrehozására.
A szerveroldali szabályokat, a központi aláírásokat és a delegálási jogosultságokat újra be kell állítani. Jelentse be előre. Ez nem a levelezés megszakadása. Ez adminisztrációs munka.
Ez a továbbítás kifejezett beállítást igényel: a régi platformot, amely még azt hiszi, hogy ő tárolja a postafiókokat, úgy kell konfigurálni, hogy az új felé továbbítson ahelyett, hogy helyben kézbesítene. Ennek hiányában egy célzott pótló átmásolás ugyanezt a munkát végzi el.
Az egyes kiindulási platformok sajátosságait a migráció Microsoft 365-ről és a migráció Google Workspace-ről című útmutatók írják le.
Addig, amíg meg nem győződnek arról, hogy egyetlen levélforgalom sem használja már a régit, és a jelzett eltéréseket kezelték. Ez a postafiókok számától, a levelet küldő alkalmazásoktól és a munkaállomások átkonfigurálásának ütemétől függ. A túl korai lezárás megakadályozza a javítást; a túl késői lezárás miatt a munkatársak két rendszerben dolgoznak.
Nem, ha előkészítették. A TTL időtartama alatt a küldők egy része még a régi platformra kézbesít, a többi az újra. Mindkettő fogad leveleket, és a következő átmásolás egyesíti a kettőt. Levél csak akkor vész el, ha elutasítják, ezért olyan fontosak az aliasok és a listák.
Általában nem: a címek nem változnak. Értesítse viszont azokat a partnereket, akik szigorúan szűrik az Ön üzeneteit, vagy akik külön szabályt rendeltek Önhöz, valamint azokat, akikkel titkosított levelezést folytat, ha a kulcsok megváltoznak.
Igen, a régi MX visszaállításával, feltéve, hogy a régi platform még aktív. Az új platform által közben fogadott üzeneteket ilyenkor vissza kell másolni, vagy elérhetőnek kell maradniuk. A visszaállási terv rögzíti, ki dönt, mennyi idő alatt, és hogyan veszik vissza ezeket az üzeneteket.
Kérdezze meg a szolgáltatótól, mit garantál: az üzenetek megérkezését, az előzmények átvételét, vagy mindkettőt. Ezek különböző vállalások. Kérje el a visszaállási tervet is, írásban, annak a személynek a megnevezésével, aki jogosult azt aktiválni.
Az üzenetek megérkezésére vonatkozó garancia az átállás napjára és az azt követő napokra vonatkozik. Az előzményekre vonatkozó garancia a másolásra és annak ellenőrzésére vonatkozik. Egy szolgáltató teljesítheti az egyiket a másik nélkül; az árajánlatnak meg kell mondania, melyiket vállalja, és hogyan ellenőrizhető.
A Klyticnél az e-mail-migráció előkészítéséhez nyújtott tanácsok és javaslatok ingyenesek, és egyetlen levél sem vész el. A Klytic által elvégzett migráció árajánlat alapján történik. Az előfizetések az Árak oldalon találhatók, és külön kerülnek számlázásra. A költségtételek részletezése a mennyibe kerül egy Microsoft 365-migráció című útmutatóban, az ellenőrző lista pedig az ellenőrzőlistában található. A célplatformok összehasonlításához lásd: európai e-mail-szolgáltatás választása.
Ez az oldal egy módszert ír le. A tényleges lefolyás az Ön levélforgalmától, adatmennyiségeitől és attól a platformtól függ, amelyet elhagy.
Megtekintve: 2026. október.
Ingyenes tanácsadás, egyetlen e-mail sem vész el. A Klytic által végzett migrációról felmérés után adunk árajánlatot.
Üdvözlő ajánlat
Kötelezettségmentes próbaajánlat. Tanácsadónk visszahívja Önt, hogy megismerje igényeit, és előkészítse Klytic-környezetét.
