MTA-STS политика в действие: Как една настройка блокира имейлите от Gmail

Истински казус от практиката на нашия екип

Когато клиент преминава към нашия хостинг, често ни поверява и преместването на своите имейли. Това се нарича имейл миграция – процес, при който пощата се прехвърля от стария към новия сървър, за да може клиентът да продължи да използва същите имейл акаунти без прекъсване.

Обикновено миграцията се извършва чрез IMAP протокол – технология, която ни позволява да копираме всички писма от стария имейл сървър към новия, без да се губи информация. След това актуализираме така наречените DNS записи – те са като „пътни знаци“ в интернет, които показват къде да се доставят имейлите. Ако някой от тези записи сочи грешно, писмата може да отидат на грешен адрес или да не се получат изобщо.

Макар на пръв поглед процесът да изглежда автоматичен, той изисква внимание и прецизност. Понякога различни фактори – като нестабилна връзка със стария сървър, ограничени ресурси или нетипични писма (например без зададена тема) – могат да затруднят прехвърлянето на имейлите.

В описания по-долу случай ще споделим една успешна имейл миграция, която обаче доведе до интересен казус след приключването ѝ – не свързан със самото прехвърляне, а с начина, по който част от външните пощи комуникираха с новия сървър.

След завършването на миграцията винаги извършваме серия от тестове, за да се уверим, че всичко работи коректно.

Тези тестове включват:

• Проверка на изпращане и получаване на имейли към различни доставчици (Gmail, Yahoo, Outlook и др.);
• Тестове от и към различни пощенски акаунти в домейна;
• Потвърждение, че всички стари съобщения са налични и достъпни;
• Проверка на DNS записите и сигурните връзки.

В този случай изпращането на писма премина безупречно, но при тестовете за получаване от външни източници открихме неочаквана ситуация…

Казусът

При един от нашите клиенти – clientdomain.bg – миграцията на имейлите приключи успешно. Всички пощенски кутии и съобщения бяха прехвърлени, а изпращането на писма работеше напълно нормално.

При последващите тестове обаче се появи интересен казус:

• Писма, изпратени от адреси с @clientdomain.bg към Gmail, се доставяха успешно.
• Но писма, изпратени от Gmail към @clientdomain.bg, не пристигаха.

Тъй като Gmail е сред най-разпространените и най-стриктни пощенски услуги, той често първи „улавя“ несъответствия в конфигурацията на даден домейн. Когато Gmail не може да потвърди, че всичко е сигурно и настроено коректно, той временно спира доставката на писма, за да предотврати изпращането им на грешен сървър или към несигурна връзка.

За да проверим дали става дума за такава ситуация, направихме няколко теста:

• Прегледахме DNS записите и спам филтрите – всичко беше напълно коректно.
• Когато се изпращаха писма от Yahoo и Outlook към @clientdomain.bg, те се доставяха успешно.
• А когато Gmail изпращаше писма към други домейни, които използват същия сървър, също нямаше затруднения.

Така изключихме вероятността за обща грешка в сървъра. Остана ясно, че казусът е специфичен само за този домейн и неговата DNS конфигурация.

Причината

След като изключихме възможните причини на сървърно ниво, започнахме да разглеждаме конфигурацията на самия домейн. Тогава открихме нещо интересно – преди време клиентът е активирал политика, наречена MTA-STS (Mail Transfer Agent – Strict Transport Security).

Тази настройка не се среща често, но е важна за сигурността на имейлите. Тя казва на всички пощенски сървъри в интернет:

• „Имейлите, изпращани към @clientdomain.bg, трябва да се доставят само до точно определен мейл сървър.“
• „Връзката между изпращащия и получаващия сървър трябва винаги да бъде криптирана – това означава, че писмата се предават по защитен канал и никой не може да ги прочете по пътя.“
• „Информацията за тази политика трябва да е достъпна през защитен (HTTPS) адрес, за да могат изпращащите сървъри да я проверят, преди да изпратят имейл.“

Тази политика не е задължителна, но Gmail и някои други доставчици я използват, за да подсилят сигурността при доставката на поща.

На практика това означава, че когато някой (например Gmail) се опита да изпрати писмо към @clientdomain.bg, той първо проверява дали такава политика съществува и дали всичко съвпада. Ако нещо липсва или е остаряло, Gmail не рискува и спира доставката, вместо да я изпрати на потенциално грешно място.

При нашата проверка се оказа, че:

• Поддомейнът mta-sts.clientdomain.bg, който е част от тази политика, все още сочеше към стария пощенски сървър.
• А задължителният TXT запис _mta-sts.clientdomain.bg (специален ред в DNS настройките, който съдържа инструкции за пощенските сървъри) липсваше напълно.

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

Защо Gmail блокира, а Yahoo и Outlook – не?

Всеки имейл доставчик има свои политики за сигурност. Gmail е сред най-стриктните – той следва MTA-STS стандартите напълно и не прави изключения. Ако открие несъответствие, предпочита да „спре на червено“, за да защити потребителите си.
Yahoo и Outlook, от друга страна, все още не прилагат MTA-STS толкова строго. Когато не открият нужната информация, те продължават доставката по стандартен, некриптиран начин – затова техните писма пристигаха безпроблемно.

Така открихме източника на казуса: домейнът имаше стара, частично активна MTA-STS конфигурация, която сочеше към предишния сървър и спираше единствено доставките от Gmail.

Нашето решение

След като установихме причината, пристъпихме към корекция на настройките:

• Насочихме поддомейна mta-sts.clientdomain.bg към правилния сървър, за да може имейлите да достигат до реално активната поща.
• Добавихме липсващия TXT запис _mta-sts.clientdomain.bg, който описва политиката и казва на другите пощенски сървъри как да комуникират сигурно с домейна.
• Проверихме, че конфигурационният файл mta-sts.txt е достъпен по защитената връзка (HTTPS), както изисква стандартът.

След направените промени всички настройки вече бяха коректни. Въпреки това Gmail не възстановява доставката веднага, тъй като кешира информацията за MTA-STS политиките – подобно на това, когато браузърът запомня стара версия на страница и трябва време, за да се обнови.

Необходим е период от 24–48 часа, докато новите данни се опреснят и влязат в сила. След това потвърдихме, че имейлите от Gmail вече се доставят напълно нормално в пощенските кутии на клиента към @clientdomain.bg.
Миграцията беше напълно завършена, а комуникацията с всички пощенски доставчици – възстановена.

Какво научихме

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

• Политики като MTA-STS са изключително полезни за сигурността, но изискват актуализация при всяка промяна на инфраструктурата, за да не блокират комуникацията.
• При миграция винаги е важно да се проверят не само стандартните настройки (като MX и DNS записи), но и допълнителните политики за сигурност – SPF, DKIM, DMARC и MTA-STS (това са технологии, които потвърждават, че имейлите се изпращат от оторизирани сървъри и не са фалшиви).
• Така се гарантира, че домейнът не само ще изпраща и получава имейли безпроблемно, но и ще остане защитен от фишинг и неоторизирани изпращачи.

Заключение

В крайна сметка казусът беше разрешен успешно, а имейл услугата на клиента заработи напълно нормално.

Този пример напомня колко важно е вниманието към детайла – не просто да се извърши техническата миграция, а да се разбере как всички елементи на пощенската инфраструктура си взаимодействат.

Благодарение на системния подход и опита на нашия екип, клиентът получи работеща, сигурна и напълно възстановена имейл услуга – готова за безпроблемна комуникация с всеки партньор и клиент.