Răspuns rapid
Cum mut e-mailul la un furnizor nou fără să pierd mesaje?
Reduceți TTL-ul înregistrărilor MX la 300 până la 600 de secunde cu 24 până la 48 de ore înainte, importați vechea arhivă în noua căsuță, modificați ultimele înregistrările MX și păstrați vechiul cont până când a sosit e-mailul nou. Postelva găzduiește DNS-ul, deci comutarea este o singură modificare a două sau mai multor înregistrări.
Câte înregistrări se schimbă când vă mutați
| Furnizor nou | MX | TXT de verificare | SPF | DKIM | DMARC | Înregistrări în total |
|---|---|---|---|---|---|---|
| Proton Mail | 2 | 1 | 1 include | 3 CNAME | 1 | 8 |
| Mailbox.org | 4 | 1 | 1 include | 4 CNAME | 1 | 11 |
| Fastmail | 2 | Nu este necesar pentru o configurare doar cu MX | 1 include | 3 CNAME | Nu s-a citit (neverificat) | 6, fără DMARC |
Cinci pași, în ordinea corectă
Reduceți TTL-ul
Cu cel puțin 24 până la 48 de ore înainte de mutare, setați TTL-ul înregistrărilor MX la 300 până la 600 de secunde. O modificare se propagă în aproximativ vechiul TTL, deci o valoare scurtă înainte de modificare face schimbarea rapidă.
Pregătiți noua căsuță
Adăugați domeniul la noul furnizor, creați adresele și aliasurile și copiați înregistrarea de verificare pe care o afișează. Nu atingeți încă înregistrările MX.
Copiați vechiul e-mail
Importați arhiva cu instrumentul de import IMAP al noului furnizor, cât timp vechiul cont încă primește mesaje. Redirecționarea singură mută doar mesajele noi.
Schimbă înregistrările MX
Înlocuiți vechile înregistrări MX cu cele noi, adăugați noul include SPF în înregistrarea SPF existentă și adăugați înregistrările DKIM. Mențineți serverul vechi care acceptă mesaje până când a trecut vechiul TTL.
Confirmați, apoi curățați
Trimiteți-vă un mesaj de test din două conturi externe, verificați anteturile, păstrați vechiul cont o vreme, apoi măriți din nou TTL-ul și ștergeți vechile înregistrări.
De ce decide TTL-ul dacă se pierde e-mailul?
TTL este numărul de secunde pe care un resolver le poate păstra un răspuns, deci stabilește cât timp expeditorii continuă să folosească vechile înregistrări MX. Dacă TTL-ul vechi este de 86400 de secunde, un expeditor care v-a căutat cu un minut înainte de modificare livrează la serverul vechi până la o zi. Cu un TTL de 300 până la 600 de secunde, fereastra este de cinci până la zece minute.
Regula din ghidurile de livrabilitate este să reduceți TTL-ul cu 24 până la 48 de ore înainte de mutare, ca fiecare cache să țină deja valoarea scurtă în ziua respectivă, și să îl măriți din nou după aceea. O modificare MX tipică se stabilizează în 1 până la 4 ore și poate dura 24 până la 48 de ore în cel mai rău caz. Este o recomandare a furnizorilor, nu un standard. Răspunsurile goale sunt și ele memorate în cache, cu TTL-ul înregistrării SOA a zonei (RFC 2308), deci o înregistrare creată târziu poate rămâne invizibilă o vreme la unii resolveri.
Cum copiez vechiul e-mail înainte de comutare?
Importați vechea arhivă prin IMAP înainte să modificați o singură înregistrare MX. Proton Mail, de exemplu, documentează o trecere de la Gmail cu un instrument de import, iar ghidurile de migrare ale furnizorilor converg către aceeași ordine: importul întâi, modificarea MX doar când destinația este pregătită, păstrarea vechiului cont până când confirmați că totul a ajuns.
Două obiceiuri previn cele mai multe pierderi. În primul rând, mențineți vechea căsuță primind mesaje cât timp rulează importul, pentru că mesajele care sosesc în timpul copierii vor fi doar în vechiul cont. În al doilea rând, rulați un al doilea import scurt după comutarea MX, ca să preluați mesajele care au ajuns la serverul vechi în timpul propagării. Pentru ordinea lucrului când adresa dvs. își schimbă furnizorul, dar nu și numele, citiți cum păstrați adresa de e-mail când schimbați furnizorul.
Cum comut în siguranță înregistrările MX?
Eliminați vechile înregistrări MX sau dați celor noi cel mai mic număr de prioritate și nu lăsați niciodată doi furnizori amestecați. Fastmail și Proton Mail spun asta în paginile lor de ajutor: cu vechile și noile înregistrări una lângă alta, mesajele ajung nepredictibil la unul sau la celălalt server. O înregistrare MX numește un server de mail și o prioritate; expeditorii încearcă mai întâi numărul cel mai mic. Conceptul este explicat în ce este o înregistrare MX.
La Postelva, zona se editează în zona clientului, iar șabloane DNS dintr-un clic pentru Proton Mail, Fastmail, Zoho Mail, Google Workspace și Microsoft 365, plus un șablon SPF + DMARC și un șablon „fără e-mail” pentru un domeniu care nu trimite nimic. Un șablon înlocuiește dintr-o acțiune înregistrările MX, SPF și DKIM ale furnizorului. Pentru Tuta, Mailbox.org, iCloud+ și Migadu tastați înregistrările MX, TXT și CNAME în editorul DNS, folosind valorile afișate pe ecranul furnizorului.
Ce se întâmplă cu SPF și DKIM în timpul unei mutări?
Un domeniu poate publica o singură înregistrare SPF, deci adăugați include-ul noului furnizor în înregistrarea existentă, în loc să creați una a doua. Proton Mail, Mailbox.org și Mailfence dau aceeași instrucțiune. Păstrați include-ul vechi în înregistrare până ce ați oprit trimiterea de pe vechiul furnizor, apoi eliminați-l: verificarea SPF permite cel mult 10 căutări DNS (RFC 7208), iar fiecare include contează.
Înregistrările DKIM sunt altfel. Fiecare furnizor își folosește propriile nume de selector, precum fm1, fm2 și fm3 la Fastmail sau protonmail, protonmail2 și protonmail3 la Proton Mail, deci noile înregistrări pot sta alături de cele vechi până eliminați vechiul furnizor. Verificați înregistrările publicate cu comenzile din cum verificați înregistrările MX, SPF, DKIM și DMARC.
Cum știu că mutarea a reușit?
Trimiteți un mesaj de test la domeniu din două conturi externe și citiți anteturile de livrare. Potrivit indexului Postelva din 12 noiembrie 2026, mutarea la Proton Mail înseamnă modificarea a 8 înregistrări, la Mailbox.org 11 și la Fastmail 6 (înregistrarea DMARC a Fastmail nu a fost citită pe paginile verificate), deci verificarea fiecărui tip de înregistrare este cel mai rapid mod de a găsi una ratată.
Dacă un mesaj nu ajunge, defecțiunea este aproape întotdeauna una dintre cauzele din de ce e-mailul nu ajunge pe un domeniu personalizat. Păstrați vechiul cont câteva săptămâni, pentru că un expeditor cu cache învechit poate livra încă acolo. Când vechiul cont rămâne gol, readuceți TTL-ul la valoarea normală și eliminați vechile înregistrări.
Mutarea furnizorilor: întrebări
Cât durează comutarea?
Un schimb MX tipic se stabilizează în 1 până la 4 ore și poate dura 24 până la 48 de ore. Proton Mail cere să acordați până la o zi. Un TTL scurt setat din timp păstrează fereastra mică.
Îmi pierd adresa când mă mut?
Nu, dacă adresa se află pe propriul dvs. domeniu: domeniul rămâne la același registrar și se schimbă doar înregistrările. O adresă din domeniul vechiului furnizor, precum @proton.me sau @tuta.com, nu se poate muta.
Pot să mă mut fără să import vechiul e-mail?
Puteți, dar pierdeți arhiva din noua căsuță. Păstrați vechiul cont deschis sau exportați e-mailurile până aveți ce vă trebuie.
Mutarea schimbă înregistrarea domeniului?
Nu. Înregistrarea, data reînnoirii și proprietarul rămân aceleași. Se schimbă doar înregistrările DNS care indică serverul de mail.
Ar trebui să mă mut într-o oră liniștită?
Ajută, dar nu este obligatoriu. Important este ca schimbarea MX să aibă loc după import și după ce TTL-ul a fost redus.
Pe scurt
- Reduceți TTL-ul MX la 300 până la 600 de secunde cu 24 până la 48 de ore înainte de mutare.
- Importați întâi arhiva prin IMAP; redirecționarea mută doar mesajele noi.
- Comutați ultimele înregistrările MX; nu lăsați doi furnizori amestecați.
- Un singur SPF; adăugați noul include la el; cel mult 10 căutări DNS.
- Înregistrări modificate: Proton Mail 8, Mailbox.org 11, Fastmail 6 fără DMARC.
- Propagarea tipică este de 1 până la 4 ore, până la 24 până la 48 de ore.
- Păstrați vechiul cont până sosesc mesajele de test.
Surse (8)
- Treceți de la Gmail la Proton — Proton (citite 2026-11-12)
- Domeniu personalizat de la Namecheap (valori MX) — Proton (citite 2026-11-12)
- Protecție anti-spoofing pentru domenii personalizate — Proton (citite 2026-11-12)
- Înregistrări DNS implicite — Fastmail (citite 2026-11-12)
- Bază de cunoștințe mailbox.org: domeniu personalizat — mailbox.org (citite 2026-11-12)
- RFC 7208, secțiunea 4.6.4 — RFC Editor (citite 2026-11-12)
- RFC 2308: memorarea negativă a interogărilor DNS — RFC Editor (citite 2026-11-12)
- Cât durează propagarea modificărilor DNS — Suped (citite 2026-11-12)