Sprendimas: išlaikyti pašto dėžutę, pakeisti MX
El. pašto sistemos keitimas ir apsaugos keitimas yra du skirtingi projektai. Pirmasis perkelia pašto dėžutes, istoriją, kalendorius ir paskyras telefonuose. Antrasis keičia tik gaunamų laiškų kelią.
Šį kelią apibrėžia vienas DNS įrašas: MX, kuris nurodo siunčiantiems serveriams, kur pristatyti jūsų domeno laiškus. Kai jis nurodo šliuzą, šis gauna, išanalizuoja ir perduoda laišką pašto dėžučių serveriui. Tai taikoma:
- Microsoft 365 (Exchange Online);
- Google Workspace;
- Exchange, įdiegtam jūsų patalpose ar talpinamam;
- bet kuriam kitam el. pašto serveriui, gaunančiam SMTP;
- Klytic Mail, kuris yra tik vienas iš atvejų, o ne būtina sąlyga.
Šis vadovas nagrinėja atvejį, kai pašto dėžutė išlaikoma. Jei keičiate ir serverį, šį projektą aprašo vadovai perkėlimas iš Microsoft 365 ir perkėlimas iš Google Workspace.
Kas ką keičia
| Nustatymas | Kur | Kas |
|---|
| Domeno MX įrašas | DNS zona, pas domenų registratorių ar DNS talpinimo paslaugų teikėją | DNS tvarkantis asmuo arba paslaugų teikėjas, kuriam tai deleguota |
| Šliuzo deklaravimas el. pašto sistemoje | Microsoft 365, Google Workspace ar serverio administravimo konsolė | El. pašto administratorius |
| SPF, DKIM ir DMARC | DNS zona | DNS tvarkytojas, inventorizavęs serverius, siunčiančius domeno vardu |
| Domenai ir pristatymo serveris | Šliuzas | Šliuzo tiekėjas, kuris parengia konfigūraciją |
Principas Microsoft 365 pusėje
Microsoft dokumentacija apie filtravimą trečiosios šalies paslauga yra aiški: domeno MX turi nurodyti šią paslaugą, kuri tada pristato laiškus į Exchange Online. Microsoft rekomenduoja „partnerio“ tipo gaunamųjų laiškų jungtį, kuri gali atmesti laiškus, atkeliavusius ne per paslaugą. Ji taip pat rekomenduoja įjungti patobulintą jungčių filtravimą, kad jos pačios analizė vertintų tikrąjį siuntėją, o ne šliuzo adresą. Ji nerekomenduoja tiesiog apeiti savo filtravimo trečiosios šalies paslaugos adresams.
Principas Google Workspace pusėje
Google aprašo „gaunamųjų laiškų šliuzą“: MX nurodo šliuzą, o administratorius deklaruoja jo IP adresus konsolėje. Gmail tai naudoja, kad antraštėse rastų tikrąjį siuntėjo adresą, nuo kurio priklauso SPF ir šlamšto vertinimas. Taip pat galima atmesti laiškus, atkeliavusius ne per šliuzą. Google patikslina, kad netaiko siuntėjo DMARC politikos laiškams, gautiems per deklaruotą šliuzą: tada šią patikrą atlieka šliuzas.
Šis vadovas nekopijuoja šių konsolių ekranų, nes jie keičiasi. Atlikdami nustatymą, vadovaukitės puslapio apačioje nurodytu oficialiu puslapiu.
Keli serveriai už vieno šliuzo
Dažnas atvejis grupėje: patronuojančioji įmonė naudoja Microsoft 365, dukterinė įmonė – Google Workspace, trečioji – seną serverį. Vienas šliuzas gali būti prieš visus tris.
Principas – maršrutizavimas pagal domeną. Kiekvieno domeno MX nurodo šliuzą. Kiekvienam domenui šliuzas žino serverį, kuriam po analizės reikia perduoti laiškus. Analizė bendra, keičiasi paskirties vieta.
Nauda: ta pati filtravimo politika arba skirtingi nustatymai kiekvienam domenui, o visi sprendimai matomi vienoje vietoje. Ką reikia parengti: jei domeno pašto dėžutės paskirstytos tarp dviejų serverių, reikia žinoti, kur pristatyti kiekvienu adresu. Šis atvejis išnagrinėjamas prieš perjungimą.
Kas keičiasi ir kas nesikeičia
Nesikeičia: adresai, pašto dėžutės, istorija, el. pašto programa, žiniatinklio paštas, telefonai. Integruotas el. pašto sistemos filtras toliau veikia. Teisės ir vidiniai bendrinimai lieka platformos.
Keičiasi:
- Pirmasis laiškus gaunantis serveris. Jis mato pradinį prisijungimą ir tikrina siuntėjo autentifikavimą.
- Pašto dėžučių serveris nebemato siuntėjo tiesiogiai, o mato šliuzą. Todėl reikalingas aukščiau aprašytas deklaravimas.
- Laiškuose yra šliuzo sprendimo antraštės: administratorius jose gali perskaityti, kodėl laiškas buvo pristatytas ar atidėtas.
- Jei šliuzas perduoda ir siunčiamus laiškus, domeno SPF įrašas turi jį leisti, o jam turi būti paskelbtas DKIM parašas. Šių mechanizmų prasmė paaiškinta puslapyje SPF, DKIM ir DMARC: ką jie apsaugo ir ko neapsaugo.
Kai pakeisite ir pašto dėžučių serverį, šliuzas gali likti: keičiasi tik jo pristatymo serveris. Tai dienai pagrindinis vadovas lieka el. pašto migracija be pertrūkių, įskaitant SPF, DKIM ir DMARC.
Įdiegimas eilės tvarka
- Inventorizacija: domenai, kiekvieno pašto dėžučių serveris, programos, siunčiančios laiškus domeno vardu.
- Šliuzo parengimas, kurį atlieka jo tiekėjas: priimami domenai, pristatymo serveris, pradinės taisyklės.
- Šliuzo deklaravimas el. pašto sistemoje (gaunamųjų laiškų jungtis ar gaunamųjų laiškų šliuzas), jei platforma tai numato.
- Iš anksto sumažinamas MX TTL, tada pakeičiamas MX. DNS podėlio galiojimo metu dalis siuntėjų vis dar pristato tiesiai pašto dėžučių serveriui: tai normalu.
- Patikra: iš išorinio adreso išsiųstas laiškas turi atkeliauti su šliuzo sprendimo antraštėmis.
- Karantino stebėjimas pirmosiomis dienomis, kad būtų išleisti klaidingi teigiami rezultatai ir pakoreguotos taisyklės.
Grįžti atgal paprasta: atkurti senąjį MX. Tai parengiama kaip ir perkėlimo atveju, paskiriant asmenį, turintį teisę tai nuspręsti.
Ko šliuzas nedaro
Jis mato pro jį einančius laiškus, ir tik juos. Jis nemato laiškų, kuriais keičiasi dvi tos pačios platformos pašto dėžutės ir kurie neišeina už jos ribų, nei internetinėje saugykloje bendrinamų failų, nei naudotojų prisijungimų.
Todėl jis nepakeičia Microsoft 365 ar Google Workspace vidinių nustatymų: teisių, dviejų veiksnių autentifikavimo, prisijungimo įspėjimų, automatinio persiuntimo taisyklių. Pavogta paskyra pirmiausia lieka el. pašto sistemos klausimas. Vadovas Šlamštas, sukčiavimas, kenkėjiškos programos ir įsilaužimo pažeista paskyra tai atskiria.
Galiausiai siuntėjas, žinantis techninį pašto dėžučių serverio adresą, gali bandyti pristatyti tiesiai jam, apeidamas MX. Būtent todėl Microsoft siūlo užrakinimą (partnerio jungtis), o Google – atmesti laiškus ne per šliuzą.
Dažniausi klausimai
Ar reikia įspėti naudotojus?
Jų adresai nesikeičia. Tačiau įspėkite juos, kad jie gali gauti pranešimus apie karantiną: žr. Karantinas, klaidingi teigiami rezultatai ir pranešimai.
Ar reikia išjungti Microsoft 365 ar Google filtrą?
Ne. Microsoft rekomenduoja palikti savo analizę įjungtą ir ją nustatyti taip, kad ji matytų tikrąjį siuntėją, o ne ją apeiti.
Kiek laiko trunka perjungimas?
Pats MX pakeitimas įsigalioja DNS podėlio tempu. Parengimas priklauso nuo domenų ir serverių skaičiaus. Klytic MTA atveju žr. kitą skyrių.
Ar priekyje esantis šliuzas keičia mūsų siunčiamų laiškų pristatomumą?
Tik jei jis perduoda ir siunčiamus laiškus. Tokiu atveju SPF ir DKIM turi į tai atsižvelgti: žr. SPF, DKIM ir DMARC: ką jie apsaugo ir ko neapsaugo.
Kodėl tiesiog nepakeisti el. pašto sistemos?
Tai kitas sprendimas, su kitais kriterijais. Jis nagrinėjamas puslapyje kaip pasirinkti europietišką verslo el. paštą.
Kur yra Klytic
Klytic MTA įdiegiamas prieš jūsų turimą el. pašto sistemą: Microsoft 365, Google Workspace, Exchange, Klytic Mail ar bet kurį kitą serverį. Klytic pašto dėžutės nereikia.
- Paleidimas: paprastai per 24–48 valandas. Klytic parengia konfigūraciją; jūs pakeičiate savo domeno MX įrašą arba Klytic tai padaro už jus. Šliuzą Microsoft 365 ar Google Workspace konsolėje deklaruoja tos el. pašto sistemos administratorius, o tai parengiama kartu su Klytic paleidimo metu.
- Diegimas: Klytic debesija, skirtas egzempliorius ar kliento serveriai. Ypatingiems poreikiams kartu su Klytic galima suprojektuoti kitas architektūras, pavyzdžiui, filtravimą debesijoje ir jūsų patalpose įdiegtą tarpinį serverį arba kelis regionus.
- Planai: Essential ir Advanced. Essential apima autentifikavimą, šlamšto ir virusų filtravimą, sukčiavimo laiškus, panašius domenus, karantiną, siunčiamų laiškų DKIM parašą ir atšaukimą prieš išsiuntimą. Advanced prideda finansinį sukčiavimą, apsaugą paspaudus nuorodą, DMARC konsolę ir žurnalų eksportą į SIEM.
- Bandymas: 30 dienų nemokamai, nekeičiant el. pašto sistemos.
Klytic MTA netvarko jūsų esamos el. pašto sistemos teisių ir paskyrų ir nežada lygiavertiškumo su Microsoft 365 ar Google Workspace integruotais saugumo įrankiais: jis pridedamas prieš juos.
Šiame puslapyje aprašomas principas. Microsoft ir Google konsolės keičiasi: atliekant veiksmus vadovautis reikia jų oficialia dokumentacija.
Šaltiniai
Peržiūrėta 2026 m. spalį.
- Microsoft Learn, „Manage mail flow using a third-party cloud service with Exchange Online“: MX turi nurodyti trečiosios šalies paslaugą; partnerio tipo gaunamųjų laiškų jungtis; patobulintas jungčių filtravimas, užuot apėjus filtravimą. learn.microsoft.com
- Google Workspace pagalba, „Set up an inbound mail gateway“: MX į šliuzą, jo IP adresų deklaravimas, galimas laiškų ne per šliuzą atmetimas; Gmail netaiko siuntėjo DMARC politikos laiškams, gautiems per šliuzą. knowledge.workspace.google.com
- RFC 5321, SMTP: tarpiniai mazgai paprastai nurodomi DNS MX įrašu. rfc-editor.org
- Klytic, Klytic MTA puslapis: Essential ir Advanced planų moduliai, papildomos paslaugos, diegimo būdai, paleidimas per MX. klytic.com
