Как се мести сайт на нов хостинг, без да спре имейлът

Сайтът и имейлът на един домейн са различни записи в DNS и се местят поотделно. Когато премествате сайта, променяте само записа, който сочи към уеб сървъра, а записите за пощата остават както са. Проблемите почти никога не идват от самото преместване – идват от два детайла, които стоят незабелязани с години: MX записът сочи към самия домейн вместо към пощенския сървър, а SPF записът разчита на +a. И двете работят безупречно, докато домейнът сочи към стария хостинг, и се чупят в момента, в който го пренасочите.

Защо изобщо спира имейлът

DNS е указателят на домейна. В него има отделни редове за различни услуги:

• A или CNAME запис за самия сайт – „когато някой отвори tcp.bg, изпрати го на този сървър“;
• MX запис за пощата – „писмата за @tcp.bg се доставят на този сървър“;
• TXT записи (SPF, DKIM, DMARC) – доказват, че писмата от домейна са истински;
• записи за webmail, cPanel, FTP и други помощни услуги.

Когато преместите сайта, пипате само първия ред. Имейлът продължава да работи, защото MX записът сочи на друго място. Това е теорията и в повечето случаи тя се спазва.

Двата случая, в които не се спазва, са чести при по-стари хостинг акаунти:

MX записът сочи към самия домейн. Вместо mail.вашиядомейн.bg, MX записът казва просто вашиядомейн.bg. Докато домейнът сочи към стария сървър, където живее и пощата, всичко е наред. В секундата, в която пренасочите домейна към новия сайт, изпращащите сървъри започват да доставят писмата към… новия уеб сървър, който не приема поща.

SPF записът използва +a. Това означава „разреши на сървъра, към който сочи домейнът“. След преместването този сървър вече е друг и SPF записът започва да разрешава грешната машина, а истинският пощенски сървър остава неразрешен. Писмата ви тръгват към папка „спам“.

Какво да проверите, преди да пипате каквото и да е

1. Извадете пълния списък със записи от текущия DNS. Не се доверявайте на паметта си – в една зона обикновено има 20 до 30 реда, а един забравен поддомейн спира да работи веднага след преместването.
2. Вижте към какво сочи MX записът. Ако сочи към самия домейн, първо го променете към mail.вашиятдомейн.bg и изчакайте един ден, преди да местите сайта.
3. Прочетете SPF записа. Ако съдържа +a, заменете го с конкретния IP адрес на пощенския сървър.
4. Проверете настройките в пощенските програми. В Outlook или на телефона входящият и изходящият сървър трябва да са mail.вашиятдомейн.bg, а не самият домейн. Ако е записан домейнът, пощата спира в момента на преместването – и то не заради DNS, а заради самия телефон.
5. Намалете TTL стойностите на записите, които ще променяте, до 5 минути – поне ден предварително. TTL е времето, за което светът запомня стария отговор. С 24-часов TTL една грешка се поправя утре.

Самото преместване

Редът има значение:

1. Качете сайта на новия сървър и се уверете, че работи – най-лесно с временен адрес или през файла hosts на собствения ви компютър.
2. Издайте SSL сертификата за новия сървър преди превключването. Ако смените записа, докато сертификатът още се издава, посетителите виждат предупреждение за сигурност.
3. Сменете само A или CNAME записа на домейна и на www.
4. Оставете MX, webmail, cPanel, FTP и TXT записите точно както са.
5. Проверете сайта от външна мрежа – мобилен интернет върши работа – и веднага след това изпратете тестово писмо към и от адрес в домейна.

Първите 24 часа

DNS не се сменя навсякъде едновременно. Различните доставчици пазят стария отговор различно дълго, затова за един ден част от света вижда новия сайт, а друга част – стария. Това е нормално и не е повод за паника.

Неприятното изключение е, когато някой доставчик комбинира стар и нов отговор – например запомнил е стария MX запис, но пита за домейна наново. Тогава писмата тръгват към грешния сървър. Изпращащите сървъри опитват отново в следващите часове, така че писмата не се губят, но могат да закъснеят. Точно затова първата точка в списъка по-горе е да оправите MX записа преди преместването, а не по време на него.

Полезно е през този ден да следите две неща: отваря ли се сайтът от няколко различни мрежи и пристига ли поща както обикновено.

Струва ли си изобщо да местите и пощата

Обикновено не. Пощата рядко е причината за смяната на хостинга, а мигрирането ѝ носи реален риск от загубени писма и дни борба с настройки по телефоните на всички в екипа. Най-спокойният вариант е сайтът да се премести там, където ще работи по-бързо, а пощата да остане където си е. Двете нямат нужда да живеят на един и същи сървър – и в повечето случаи е по-добре да не живеят.

Когато преместихме сайта на счетоводна кантора „Троя Консулт“, пощата остана при стария доставчик и не спря нито за минута, въпреки че сайтът смени и сървъра, и DNS доставчика.

Кратък списък за проверка

• Пълен списък на DNS записите, свален и запазен
• MX сочи към пощенски поддомейн, не към самия домейн
• SPF без +a, с конкретен IP
• Пощенските програми използват mail.домейн
• TTL намален предварително
• Новият сайт работи и има SSL сертификат преди превключването
• Сменени само записите за сайта и www
• Тестово писмо в двете посоки веднага след смяната

Ако тази проверка ви изглежда като работа, която не искате да вършите – това е част от изработката на сайт при нас. Преместваме домейна и сайта, а пощата остава ваша грижа само дотолкова, доколкото трябва да потвърдите, че писмата пристигат.