Decizia: păstrați căsuța, schimbați MX-ul
Schimbarea serviciului de e-mail și schimbarea protecției sunt două proiecte diferite. Primul mută căsuțele, istoricul, calendarele și conturile de pe telefoane. Al doilea atinge doar traseul e-mailurilor primite.
Acest traseu este definit de o înregistrare DNS: MX-ul, care indică serverelor expeditoare unde să livreze e-mailurile domeniului dumneavoastră. Când acesta desemnează poarta, ea primește, analizează și apoi predă mesajul serverului de căsuțe. Acest lucru este valabil pentru:
- Microsoft 365 (Exchange Online);
- Google Workspace;
- Exchange instalat la sediul dumneavoastră sau găzduit;
- orice alt server de e-mail care primește prin SMTP;
- Klytic Mail, care este doar un caz printre celelalte, nu o condiție prealabilă.
Acest ghid tratează cazul în care căsuța este păstrată. Dacă schimbați și serverul, ghidurile migrarea de la Microsoft 365 și migrarea de la Google Workspace descriu acel proiect.
Cine ce modifică
| Setare | Unde | Cine |
|---|
| Înregistrarea MX a domeniului | Zona DNS, la registrar sau la furnizorul de găzduire DNS | Persoana care gestionează DNS-ul sau prestatorul care a primit delegarea |
| Declararea porții în serviciul de e-mail | Consola de administrare Microsoft 365, Google Workspace sau a serverului | Administratorul serviciului de e-mail |
| SPF, DKIM și DMARC | Zona DNS | Administratorul DNS, după inventarierea serverelor care trimit pentru domeniu |
| Domenii și server de livrare | Poarta | Furnizorul porții, care pregătește configurația |
Principiul la Microsoft 365
Documentația Microsoft privind filtrarea printr-un serviciu terț este clară: MX-ul domeniului trebuie să desemneze acest serviciu, care livrează apoi către Exchange Online. Microsoft recomandă un conector de intrare de tip „partener”, care poate refuza e-mailurile sosite fără a trece prin serviciu. Recomandă și activarea filtrării îmbunătățite pentru conectori, astfel încât propria analiză să evalueze expeditorul real, nu adresa porții. Nu recomandă simpla ocolire a filtrării sale pentru adresele serviciului terț.
Principiul la Google Workspace
Google descrie o „poartă de e-mail de intrare”: MX-ul desemnează poarta, apoi administratorul îi declară adresele IP în consolă. Gmail le folosește pentru a regăsi în antete adresa reală a expeditorului, de care depind SPF și evaluarea spamului. Se pot refuza și e-mailurile care nu provin de la poartă. Google precizează că nu aplică politica DMARC a expeditorului e-mailurilor primite printr-o poartă declarată: acest control revine atunci porții.
Acest ghid nu reproduce ecranele acestor console, care se schimbă. Urmați pagina oficială citată la finalul paginii în momentul configurării.
Mai multe servere în spatele unei singure porți
Caz frecvent într-un grup: societatea-mamă pe Microsoft 365, o filială pe Google Workspace, o a treia pe un server mai vechi. O singură poartă le poate preceda pe toate trei.
Principiul este o rutare pe domeniu. MX-ul fiecărui domeniu indică poarta. Pentru fiecare domeniu, poarta cunoaște serverul căruia trebuie să îi predea e-mailurile după analiză. Analiza este comună, destinația se schimbă.
Avantaj: aceeași politică de filtrare sau setări diferite în funcție de domeniu și citirea tuturor deciziilor în același loc. Aspect de pregătit: un domeniu ale cărui căsuțe ar fi împărțite între două servere necesită să se știe, adresă cu adresă, unde trebuie livrat. Acest caz se analizează înainte de comutare.
Ce se schimbă și ce nu se schimbă
Nu se schimbă: adresele, căsuțele, istoricul, programul de e-mail, webmailul, telefoanele. Filtrul integrat al serviciului de e-mail continuă să funcționeze. Drepturile și partajările interne rămân cele ale platformei.
Se schimbă:
- Primul server care primește e-mailurile. El vede conexiunea de origine și verifică autentificarea expeditorului.
- Serverul de căsuțe nu mai vede expeditorul direct, ci poarta. De aici declararea descrisă mai sus.
- Mesajele poartă antetele de decizie ale porții: un administrator poate citi acolo de ce un mesaj a fost livrat sau pus deoparte.
- Dacă poarta transmite și e-mailurile trimise, înregistrarea SPF a domeniului trebuie să o autorizeze, iar semnătura DKIM trebuie publicată pentru ea. Sensul acestor mecanisme este explicat în SPF, DKIM și DMARC.
În ziua în care veți schimba și serverul de căsuțe, poarta poate rămâne pe loc: se schimbă doar serverul său de livrare. Ghidul migrarea unui serviciu de e-mail fără întreruperi rămâne referința pentru acea zi, inclusiv pentru SPF, DKIM și DMARC.
Punerea în funcțiune, în ordine
- Inventar: domeniile, serverul de căsuțe al fiecăruia, aplicațiile care trimit e-mailuri în numele domeniului.
- Pregătirea porții de către furnizorul ei: domenii acceptate, server de livrare, reguli inițiale.
- Declararea porții în serviciul de e-mail (conector de intrare sau poartă de intrare), dacă platforma prevede acest lucru.
- Reducerea prealabilă a TTL-ului MX, apoi modificarea MX-ului. Pe durata cache-ului DNS, o parte dintre expeditori livrează încă direct către serverul de căsuțe: este normal.
- Verificare: un mesaj trimis de la o adresă externă trebuie să sosească cu antetele de decizie ale porții.
- Monitorizarea carantinei în primele zile, pentru a elibera rezultatele fals pozitive și a ajusta regulile.
Revenirea este simplă: se repune vechiul MX. Ea se pregătește ca pentru o migrare, cu o persoană care are dreptul să o decidă.
Ce nu face poarta
Ea vede e-mailurile care o traversează și numai pe acestea. Nu vede mesajele schimbate între două căsuțe ale aceleiași platforme care nu ies din aceasta, nici fișierele partajate într-un spațiu de stocare online, nici conectările utilizatorilor.
Prin urmare, nu înlocuiește setările interne ale Microsoft 365 sau Google Workspace: drepturi, autentificare cu doi factori, alerte de conectare, reguli de redirecționare automată. Un cont furat rămâne în primul rând o problemă a serviciului de e-mail. Ghidul spam, phishing, malware și cont compromis face distincția.
În sfârșit, un expeditor care cunoaște adresa tehnică a serverului de căsuțe poate încerca să livreze direct către acesta, fără a trece prin MX. Acesta este motivul blocajului propus de Microsoft (conector partener) și de Google (refuzul e-mailurilor care nu trec prin poartă).
Întrebări frecvente
Trebuie anunțați utilizatorii?
Adresele lor nu se schimbă. Anunțați-i însă că ar putea primi notificări de carantină: vedeți Carantină, rezultate fals pozitive și semnalări.
Trebuie dezactivat filtrul Microsoft 365 sau Google?
Nu. Microsoft recomandă să lăsați analiza sa activă și să o configurați astfel încât să vadă expeditorul real, în loc să o ocoliți.
Cât durează comutarea?
Schimbarea MX-ului însăși intră în vigoare în ritmul cache-ului DNS. Pregătirea depinde de numărul de domenii și de servere. Pentru Klytic MTA, vedeți secțiunea următoare.
O poartă plasată în față schimbă livrabilitatea trimiterilor noastre?
Doar dacă transmite și e-mailurile trimise. În acest caz, SPF și DKIM trebuie să țină cont de ea: vedeți SPF, DKIM și DMARC.
De ce să nu schimbați pur și simplu serviciul de e-mail?
Este o altă decizie, cu alte criterii. Ea este tratată în alegerea unui e-mail profesional european.
Unde se situează Klytic
Klytic MTA se plasează în fața serviciului de e-mail pe care îl aveți: Microsoft 365, Google Workspace, Exchange, Klytic Mail sau orice alt server. Nu presupune o căsuță Klytic.
- Punere în funcțiune: de obicei între 24 și 48 de ore. Klytic pregătește configurația; dumneavoastră modificați înregistrarea MX a domeniului sau o face Klytic pentru dumneavoastră. Declararea porții în consola Microsoft 365 sau Google Workspace este făcută de administratorul acelui serviciu de e-mail și se pregătește împreună cu Klytic la punerea în funcțiune.
- Implementare: cloudul Klytic, instanță dedicată sau serverele clientului. Pentru nevoi speciale, alte arhitecturi se concep împreună cu Klytic, de exemplu o filtrare în cloud și un releu instalat la sediul dumneavoastră sau mai multe regiuni.
- Oferte: Essential și Advanced. Essential acoperă autentificarea, antispamul, antivirusul, phishingul, domeniile-clonă, carantina, semnarea DKIM a trimiterilor și rechemarea înainte de trimitere. Advanced adaugă frauda financiară, protecția la clic, consola DMARC și exportul jurnalelor către un SIEM.
- Perioadă de probă: 30 de zile gratuite, fără a schimba serviciul de e-mail.
Klytic MTA nu gestionează drepturile și conturile serviciului dumneavoastră actual de e-mail și nu promite echivalența cu instrumentele de securitate integrate în Microsoft 365 sau Google Workspace: se adaugă în fața lor.
Această pagină descrie un principiu. Consolele Microsoft și Google evoluează: documentația lor oficială este cea care face dovada pentru pașii concreți.
Surse
Consultate în octombrie 2026.
- Microsoft Learn, „Manage mail flow using a third-party cloud service with Exchange Online”: MX-ul trebuie să desemneze serviciul terț; conector de intrare de tip partener; filtrare îmbunătățită pentru conectori în locul ocolirii filtrării. learn.microsoft.com
- Ajutor Google Workspace, „Set up an inbound mail gateway”: MX către poartă, declararea adreselor sale IP, posibilitatea de a refuza e-mailurile care nu trec prin poartă; politica DMARC a expeditorului nu este aplicată de Gmail e-mailurilor primite prin poartă. knowledge.workspace.google.com
- RFC 5321, SMTP: gazdele intermediare sunt în general desemnate de înregistrarea MX din DNS. rfc-editor.org
- Klytic, pagina Klytic MTA: modulele ofertelor Essential și Advanced, opțiuni, moduri de implementare, punere în funcțiune prin MX. klytic.com
