Ce rol au înregistrările MX
Înregistrările MX, prescurtare de la Mail Exchange, indică serverele care primesc mesajele trimise către un domeniu. Când cineva trimite un e-mail către o adresă de forma contact@exemplu.ro, serverul expeditorului caută în DNS înregistrările MX pentru domeniul respectiv. Acestea îi arată unde trebuie livrat mesajul. Dacă MX-ul lipsește, este greșit sau indică un server care nu mai găzduiește căsuțele, mesajele pot fi respinse sau pot ajunge în altă parte.
MX nu este același lucru cu SPF, DKIM sau DMARC. MX descrie ruta de primire, în timp ce SPF, DKIM și DMARC contribuie la autentificarea mesajelor și la reducerea falsificării domeniului. O configurare completă a e-mailului are nevoie de ambele categorii de înregistrări. Dacă ai configurat deja autentificarea, articolul despre SPF, DKIM și DMARC în cPanel explică partea de protecție a identității expeditorului.
Cum citești o înregistrare MX
O înregistrare MX are de regulă un nume sau host, o prioritate și o destinație. Numele este domeniul pentru care se aplică regula, prioritatea stabilește ordinea preferată, iar destinația este numele serverului de e-mail. Într-un set cu mai multe servere, valoarea numerică mai mică indică prioritatea mai mare. De exemplu, un MX cu prioritatea 10 este încercat înaintea unuia cu prioritatea 20. Serverul secundar este folosit dacă serverul preferat nu poate primi mesajul, în funcție de comportamentul sistemelor implicate.
Destinația trebuie să fie un nume de gazdă complet, de tipul mail.exemplu.ro, nu o adresă de e-mail. Verifică dacă acel nume are și o înregistrare A sau AAAA validă și dacă serverul chiar acceptă mesaje pentru domeniul tău. Nu copia automat un MX dintr-un tutorial: valorile corecte depind de furnizorul care găzduiește căsuțele. Folosește exact valorile furnizate de serviciul de e-mail.
Email Routing în cPanel: Local, Remote și Backup
În cPanel, secțiunea Email Routing stabilește cum tratează serverul local mesajele pentru domeniu. Local Mail Exchanger indică faptul că serverul local primește e-mailul. Remote Mail Exchanger arată că mesajele sunt gestionate de un server extern, iar Backup Mail Exchanger permite serverului local să funcționeze ca destinație secundară atunci când serverul principal este extern. Opțiunea trebuie să corespundă arhitecturii reale a domeniului.
Nu alege Local doar pentru că ai creat căsuțe în cPanel dacă MX-ul domeniului indică spre Google Workspace sau alt furnizor extern. În această situație, setarea de rutare trebuie să reflecte serviciul extern. Invers, dacă e-mailul este găzduit chiar pe același cont cPanel, o setare Remote poate împiedica livrarea locală. O nepotrivire între MX și Email Routing este una dintre cauzele frecvente pentru care mesajele nu ajung unde te aștepți.
Opțiunea Auto Detect poate folosi informațiile din zona DNS locală pentru a deduce configurația, însă nu trebuie tratată ca un instrument care verifică întregul DNS public în timp real. Dacă ai schimbat recent furnizorul sau zona DNS este găzduită în altă parte, verifică manual setarea. Documentația oficială despre Email Routing în cPanel descrie diferențele dintre tipurile de rutare și situațiile în care se folosesc.
| Opțiune | Comportament | Când o folosești |
|---|---|---|
| Local Mail Exchanger | Serverul local primește mesajele | Căsuțe găzduite local |
| Remote Mail Exchanger | Mesajele sunt gestionate extern | MX indică un furnizor extern |
| Backup Mail Exchanger | Server secundar | Server local folosit ca rezervă |
Verificarea MX în Zone Editor
Deschide cPanel și intră în Zone Editor pentru domeniul dorit. Alege administrarea înregistrărilor și identifică liniile de tip MX. Verifică numele domeniului, prioritatea și destinația. Dacă folosești un furnizor extern, compară valorile din cPanel cu cele afișate în panoul acelui furnizor. Dacă DNS-ul este administrat în Cloudflare sau la registrar, modificarea trebuie făcută în zona DNS autoritativă, nu doar în zona locală a serverului.
Înainte de a șterge un MX vechi, confirmă că noul serviciu este activ și că toate căsuțele importante există la destinație. Dacă faci migrarea, păstrează accesul la vechiul server pentru perioada de tranziție și planifică schimbarea într-un interval cu trafic redus. Nu modifica simultan MX, A, SPF și alte înregistrări fără să notezi valorile inițiale. Un export sau o captură a zonei DNS poate ajuta la revenirea rapidă dacă apare o problemă.
În documentația Zone Editor găsești explicații despre adăugarea și modificarea înregistrărilor. Respectă valorile și formatele indicate de furnizorul de e-mail, inclusiv punctul final din unele interfețe DNS, care poate fi adăugat automat sau poate fi necesar în funcție de panou.
Propagarea DNS și verificarea din terminal
După modificarea MX, actualizarea nu este instantanee peste tot. Rezultatul depinde de TTL, cache-ul resolverelor și momentul la care serverele DNS au preluat noua informație. Un TTL de 3600 de secunde indică o perioadă de cache de până la o oră pentru resolverele care respectă acea valoare, dar nu reprezintă o promisiune că toate sistemele vor vedea schimbarea exact după o oră. Verifică din mai multe rețele dacă domeniul este important pentru activitatea zilnică.
Pe un calculator cu Windows poți folosi nslookup pentru a interoga MX-ul domeniului. În Command Prompt, comanda este:
Comenzi utile pentru verificare
Comanda de mai jos cere înregistrările MX pentru domeniul exemplu.ro. Înlocuiește domeniul demonstrativ cu numele real și compară răspunsul cu valorile furnizate de serviciul de e-mail. Dacă ai dig instalat pe un server Linux, poți folosi și a doua comandă.
nslookup -type=mx exemplu.ro
# Alternativ, dacă ai dig instalat:
dig MX exemplu.ro +shortTestarea livrării și diagnosticarea problemelor
După ce DNS-ul arată valorile corecte, trimite un mesaj de test dintr-un serviciu extern către o căsuță de pe domeniu. Verifică Inbox, Spam și eventualele filtre. Trimite apoi un răspuns în sens invers, pentru a testa și ruta de ieșire. Dacă mesajele intră pe server, dar nu ajung în căsuță, problema poate fi la stocare, filtre, cote sau configurarea contului, nu la MX.
Dacă mesajul este respins, citește codul de eroare și jurnalul de livrare, acolo unde furnizorul îl oferă. Un mesaj de tip host not found poate indica o destinație MX invalidă sau lipsa înregistrării A/AAAA. Un mesaj de tip connection timed out poate indica o problemă de acces la server sau la porturile de mail. Dacă serverul acceptă mesajul, dar îl livrează într-o căsuță greșită, verifică rutarea locală și aliasurile.
Nu confunda Email Deliverability din cPanel cu MX. Instrumentul de livrabilitate verifică în principal configurări de autentificare și recomandări DNS, în timp ce MX determină ruta de primire. Pentru protecția căsuțelor, poți consulta și articolul despre filtrarea mesajelor nedorite cu BoxTrapper, dar nu activa filtre agresive înainte să confirmi că mesajele legitime sunt livrate.
Migrarea către un furnizor extern
Dacă muți e-mailul de pe serverul cPanel către un serviciu extern, creează mai întâi toate căsuțele și aliasurile la destinație. Migrează mesajele vechi, verifică autentificarea conturilor și pregătește valorile MX furnizate de noul serviciu. Abia apoi schimbă înregistrările DNS. Dacă schimbi MX înainte ca noile căsuțe să fie pregătite, mesajele noi pot ajunge într-un cont care nu există.
Verifică și setările de trimitere, inclusiv SPF, DKIM și DMARC. Un MX corect nu garantează că mesajele trimise vor ajunge în Inbox. Dacă folosești simultan un server web și un serviciu extern de mail, păstrează clară separarea dintre găzduirea site-ului și găzduirea e-mailului. Poți avea website-ul pe un server și căsuțele pe altul, fără ca acest lucru să afecteze funcționarea domeniului, dacă DNS-ul este configurat corect.
Listă de verificare înainte de final
Înainte de a considera configurarea încheiată, confirmă că MX-urile publice corespund furnizorului activ, prioritățile sunt corecte, destinațiile pot fi rezolvate și Email Routing este setat în acord cu arhitectura. Testează primirea dintr-un serviciu extern, răspunsul din căsuța domeniului și comportamentul aliasurilor. Notează valorile anterioare și păstrează o evidență a schimbărilor.
Înregistrările MX sunt simple ca structură, dar au efect direct asupra comunicării unei afaceri. O verificare metodică înainte și după modificare previne pierderea mesajelor și reduce timpul de diagnosticare. Dacă nu ești sigur unde este găzduit DNS-ul autoritativ sau ce server trebuie să primească mesajele, cere valorile exacte de la furnizor înainte să schimbi zona.
TTL, migrare și domenii cu servicii separate
TTL-ul merită planificat înainte de o migrare. Dacă știi că vei schimba furnizorul, poți reduce temporar TTL-ul în avans, acolo unde furnizorul DNS permite acest lucru. Apoi aștepți să expire cache-urile vechi înainte de modificarea finală. După ce noul serviciu funcționează stabil, poți reveni la o valoare mai mare pentru a reduce numărul de interogări DNS. Nu modifica TTL-ul în ultimul moment și nu presupune că scăderea lui golește instantaneu cache-urile deja existente.
Un domeniu poate avea website-ul pe un server, iar e-mailul pe alt furnizor. De exemplu, înregistrarea A pentru domeniul principal poate indica spre hostingul web, în timp ce MX indică spre un serviciu extern de e-mail. Acest lucru este normal. Important este să nu confunzi serverul web cu serverul de mail și să verifici unde este găzduită zona DNS autoritativă. Dacă folosești un subdomeniu separat pentru e-mail, confirmă că înregistrările sale A, MX și politicile de autentificare sunt configurate în acord cu furnizorul.
În timpul migrării, păstrează o perioadă de supraveghere în care verifici mesajele noi, mesajele trimise de pe site și notificările automate. Formularele WordPress, mesajele WooCommerce și sistemele de facturare pot folosi un server SMTP diferit de cel care primește e-mailul. Un test simplu de trimitere nu confirmă automat că toate aceste fluxuri funcționează; verifică fiecare aplicație importantă și păstrează logurile până când noua rută este stabilă.
