A döntés: a postafiók marad, az MX változik
A levelezőrendszer-váltás és a védelem cseréje két különböző projekt. Az első áthelyezi a postafiókokat, az előzményeket, a naptárakat és a telefonokon beállított fiókokat. A második csak a beérkező levelek útvonalát érinti.
Ez az útvonal egyetlen DNS-rekordon múlik: az MX-en, amely megmondja a küldő szervereknek, hová kézbesítsék az Ön domainjének leveleit. Ha az átjáróra mutat, az fogadja, elemzi, majd továbbadja az üzenetet a postafiókszervernek. Ez érvényes:
- a Microsoft 365-re (Exchange Online);
- a Google Workspace-re;
- a saját telephelyen telepített vagy hosztolt Exchange-re;
- minden más, SMTP-n fogadó levelezőszerverre;
- a Klytic Mailre, amely csak egy eset a többi között, nem előfeltétel.
Ez az útmutató azzal az esettel foglalkozik, amikor a postafiók marad. Ha szervert is vált, a migrálás a Microsoft 365-ről és a migrálás a Google Workspace-ről útmutató írja le azt a projektet.
Ki mit módosít
| Beállítás | Hol | Ki |
|---|
| A domain MX-rekordja | DNS-zóna, a domainregisztrátornál vagy a DNS-szolgáltatónál | A DNS-t kezelő személy, vagy az a szolgáltató, akire ezt delegálták |
| Az átjáró bejelentése a levelezőrendszerben | A Microsoft 365, a Google Workspace vagy a szerver felügyeleti konzolja | A levelezőrendszer adminisztrátora |
| SPF, DKIM és DMARC | DNS-zóna | A DNS kezelője, miután felmérte, mely szerverek küldenek a domain nevében |
| Domainek és kézbesítési szerver | Átjáró | Az átjáró szolgáltatója, amely előkészíti a konfigurációt |
Az elv a Microsoft 365 oldalán
A Microsoft harmadik féltől származó szűrésről szóló dokumentációja egyértelmű: a domain MX-rekordjának erre a szolgáltatásra kell mutatnia, amely ezután az Exchange Online-ba kézbesít. A Microsoft „partner” típusú bejövő összekötőt ajánl, amely elutasíthatja a szolgáltatás megkerülésével érkező leveleket. Azt is ajánlja, hogy kapcsolják be az összekötők bővített szűrését, hogy saját elemzése a valódi feladót értékelje, ne az átjáró címét. Nem javasolja, hogy saját szűrését egyszerűen megkerüljék a harmadik fél szolgáltatásának címeire.
Az elv a Google Workspace oldalán
A Google „bejövő levelezési átjárót” ír le: az MX az átjáróra mutat, majd az adminisztrátor megadja annak IP-címeit a konzolban. A Gmail ezek alapján találja meg a fejlécekben a feladó valódi címét, amelytől az SPF és a levélszemét-értékelése függ. Az átjárón kívül érkező levelek elutasítása is beállítható. A Google kiemeli, hogy a bejelentett átjárón keresztül kapott levelekre nem alkalmazza a feladó DMARC-szabályzatát: ez az ellenőrzés ilyenkor az átjáró feladata.
Ez az útmutató nem másolja le ezeknek a konzoloknak a képernyőit, mert azok változnak. A beállításkor kövesse az oldal alján hivatkozott hivatalos oldalt.
Több szerver egyetlen átjáró mögött
Gyakori eset egy cégcsoportban: az anyavállalat Microsoft 365-ön, egy leányvállalat Google Workspace-en, egy harmadik egy régi szerveren. Egyetlen átjáró mindhárom elé kerülhet.
Az elv a domainenkénti útválasztás. Minden domain MX-rekordja az átjáróra mutat. Az átjáró minden domainhez ismeri azt a szervert, amelynek az elemzés után átadja a leveleket. Az elemzés közös, a cél változik.
Előny: azonos szűrési szabályzat, vagy domainenként eltérő beállítások, és az összes döntés egy helyen olvasható. Előkészítendő pont: ha egy domain postafiókjai két szerver között oszlanak meg, címenként tudni kell, hová kell kézbesíteni. Ezt az esetet az átállás előtt kell megvizsgálni.
Mi változik, és mi nem
Nem változik: a címek, a postafiókok, az előzmények, a levelezőprogram, a webes levelezőfelület, a telefonok. A levelezőrendszer beépített szűrője továbbra is működik. A jogosultságok és a belső megosztások a platforméi maradnak.
Változik:
- A leveleket elsőként fogadó szerver. Ez látja az eredeti kapcsolatot, és ez ellenőrzi a feladó hitelesítését.
- A postafiókszerver már nem közvetlenül a feladót látja, hanem az átjárót. Ezért van szükség a fent leírt bejelentésre.
- Az üzenetek hordozzák az átjáró döntési fejléceit: egy adminisztrátor kiolvashatja belőlük, miért kézbesítettek vagy tettek félre egy üzenetet.
- Ha az átjáró a kimenő leveleket is továbbítja, a domain SPF-rekordjának engedélyeznie kell, és a DKIM-aláírást közzé kell tenni hozzá. Ezeknek a mechanizmusoknak az értelmét az SPF, DKIM és DMARC útmutató magyarázza el.
Amikor majd a postafiókszervert is lecseréli, az átjáró a helyén maradhat: csak a kézbesítési szervere változik. Arra a napra továbbra is a levelezés migrálása megszakítás nélkül útmutató az irányadó, az SPF-re, a DKIM-re és a DMARC-ra is.
A bevezetés, sorrendben
- Leltár: domainek, mindegyik postafiókszervere, a domain nevében leveleket küldő alkalmazások.
- Az átjáró előkészítése a szolgáltatója által: elfogadott domainek, kézbesítési szerver, kiinduló szabályok.
- Az átjáró bejelentése a levelezőrendszerben (bejövő összekötő vagy bejövő átjáró), ha a platform ezt előirányozza.
- Az MX TTL-értékének előzetes csökkentése, majd az MX módosítása. A DNS-gyorsítótár érvényességi ideje alatt a feladók egy része még közvetlenül a postafiókszervernek kézbesít: ez normális.
- Ellenőrzés: egy külső címről küldött üzenetnek az átjáró döntési fejléceivel kell megérkeznie.
- A karantén figyelése az első napokban, a téves riasztások felengedéséhez és a szabályok finomhangolásához.
A visszalépés egyszerű: vissza kell állítani a régi MX-et. Ezt úgy kell előkészíteni, mint egy migrációnál, egy olyan személlyel, aki jogosult erről dönteni.
Amit az átjáró nem tesz
Csak az áthaladó leveleket látja. Nem látja az ugyanazon platform két postafiókja között váltott, azt el nem hagyó üzeneteket, sem az online tárhelyen megosztott fájlokat, sem a felhasználók bejelentkezéseit.
Ezért nem helyettesíti a Microsoft 365 vagy a Google Workspace belső beállításait: jogosultságok, kétfaktoros hitelesítés, bejelentkezési riasztások, automatikus továbbítási szabályok. Egy ellopott fiók elsősorban a levelezőrendszer ügye marad. A Kéretlen levelek, adathalászat, kártevők és kompromittált fiók útmutató szétválasztja ezeket.
Végül egy feladó, aki ismeri a postafiókszerver műszaki címét, megpróbálhat közvetlenül annak kézbesíteni, az MX megkerülésével. Ez az oka a Microsoft (partnerösszekötő) és a Google (az átjárón kívüli levelek elutasítása) által javasolt lezárásnak.
Gyakori kérdések
Értesíteni kell a felhasználókat?
Címük nem változik. Azt viszont jelezze nekik, hogy karanténértesítéseket kaphatnak: lásd Karantén, téves riasztások és bejelentések.
Ki kell kapcsolni a Microsoft 365 vagy a Google szűrőjét?
Nem. A Microsoft azt ajánlja, hogy saját elemzését hagyják bekapcsolva, és úgy állítsák be, hogy a valódi feladót lássa, ahelyett hogy megkerülnék.
Mennyi ideig tart az átállás?
Maga az MX módosítása a DNS-gyorsítótár ütemében lép érvénybe. Az előkészítés a domainek és a szerverek számától függ. A Klytic MTA-ról lásd a következő szakaszt.
Megváltoztatja-e egy elé helyezett átjáró kimenő leveleink kézbesíthetőségét?
Csak akkor, ha a kimenő leveleket is továbbítja. Ebben az esetben az SPF-nek és a DKIM-nek ezt figyelembe kell vennie: lásd SPF, DKIM és DMARC.
Miért nem váltunk egyszerűen levelezőrendszert?
Ez egy másik döntés, más szempontokkal. Az európai üzleti levelezőrendszer kiválasztása útmutató foglalkozik vele.
Hol helyezkedik el a Klytic
A Klytic MTA az Ön meglévő levelezőrendszere elé kerül: Microsoft 365, Google Workspace, Exchange, Klytic Mail vagy bármely más szerver. Nem feltételez Klytic-postafiókot.
- Üzembe helyezés: általában 24–48 óra. A Klytic előkészíti a konfigurációt; Ön módosítja domainje MX-rekordját, vagy a Klytic teszi meg Ön helyett. Az átjáró bejelentését a Microsoft 365 vagy a Google Workspace konzoljában az adott levelezőrendszer adminisztrátora végzi, és ezt az üzembe helyezéskor a Klytickel együtt készítik elő.
- Telepítés: Klytic-felhő, dedikált példány vagy az ügyfél szerverei. Különleges igényekhez más architektúrák is kialakíthatók a Klytickel, például felhőbeli szűrés egy Önnél telepített továbbítóval, vagy több régió.
- Csomagok: Essential és Advanced. Az Essential csomag lefedi a hitelesítést, a levélszemétszűrést, a víruskeresést, az adathalászatot, a hasonmás domaineket, a karantént, a kimenő levelek DKIM-aláírását és a küldés előtti visszahívást. Az Advanced csomag ehhez hozzáadja a pénzügyi csalások felismerését, a kattintáskori védelmet, a DMARC-konzolt és a naplók exportálását egy SIEM-be.
- Próba: 30 nap ingyen, levelezőrendszer-váltás nélkül.
A Klytic MTA nem kezeli jelenlegi levelezőrendszere jogosultságait és fiókjait, és nem ígér egyenértékűséget a Microsoft 365-be vagy a Google Workspace-be épített biztonsági eszközökkel: eléjük kerül, kiegészítve őket.
Ez az oldal egy elvet ír le. A Microsoft és a Google konzoljai változnak: a konkrét lépésekhez hivatalos dokumentációjuk az irányadó.
Források
Megtekintve 2026 októberében.
- Microsoft Learn, „Manage mail flow using a third-party cloud service with Exchange Online”: az MX-nek a harmadik fél szolgáltatására kell mutatnia; partner típusú bejövő összekötő; az összekötők bővített szűrése a szűrés megkerülése helyett. learn.microsoft.com
- Google Workspace súgó, „Set up an inbound mail gateway”: MX az átjáróra, IP-címeinek megadása, az átjárón kívüli levelek elutasításának lehetősége; a Gmail nem alkalmazza a feladó DMARC-szabályzatát az átjárón keresztül kapott levelekre. knowledge.workspace.google.com
- RFC 5321, SMTP: a köztes gépeket általában a DNS MX-rekordja jelöli ki. rfc-editor.org
- Klytic, Klytic MTA oldal: az Essential és az Advanced csomag moduljai, opciók, telepítési módok, üzembe helyezés az MX-en keresztül. klytic.com
