Це найчастіша аварія всього переходу на Cloudflare, і в неї впізнаваний почерк: сайт працює прекрасно, ба навіть швидше, ніж раніше, а пошта мертва. Жодної видимої помилки, жодного попередження. Просто нічого не приходить, а той, хто пише в компанію, отримує відмову або, що гірше, не отримує нічого.
Причина майже завжди одна з двох нижче, і в обох випадках це лагодиться за пів години.
Чому так стається
Коли міняють сервери імен, DNS-зона не переїжджає — вона відбудовується наново. Cloudflare намагається прочитати наявну і скопіювати її, але скопіювати може лише те, що попередній провайдер показує публічно, а деякі панелі показують менше, ніж містять.
Відтоді світ питає в Cloudflare, де стоїть пошта компанії. Якщо в Cloudflare цього запису немає, відповідь буде «його немає». Це не поломка, це неповна зона, яка впевнено відповідає.
Перевірка 1: чи є записи MX
Це перше, на що дивляться, ще до будь-яких теорій.
У DNS-зоні на Cloudflare мають бути ті самі записи MX, що були до переходу, з тими самими пріоритетами. Якщо ти на Google Workspace чи Microsoft 365, ці записи описані в документації провайдера, і їх копіюють звідти. Якщо пошта хостингова, запис вказує на вузол твого постачальника, і його треба дістати зі старої панелі, а не відтворювати з памʼяті.
Дві поширені помилки саме тут:
- зовсім немає другого MX. Пошта починає ходити з перебоями, а це гірше, ніж не ходити зовсім, бо ніхто не бачить закономірності;
- запис вказує на домен замість поштового вузла. Виглядає правильно, але ні:
mail.твійдомен.itітвійдомен.it— різні імена, і друге зазвичай веде на сайт.
Перевірка 2: помаранчева хмарка
Це підступніша помилка, бо зона виглядає правильною.
У Cloudflare біля кожного запису є значок хмарки. Помаранчева означає «трафік іде через нас»: Cloudflare відповідає замість твого сервера і ховає його IP-адресу. Сіра означає «просто відповідай», тобто звичайний DNS.
Помаранчеве проксі створене для вебтрафіку. На всьому іншому воно шкодить:
- запис, на який вказують MX, має бути сірим. Якщо
mail.твійдомен.itпомаранчевий, світ отримує адресу Cloudflare, а це не поштовий сервер. Доставки не буде; - піддомени, якими користуються зовнішні сервіси, мають бути сірими: вебпошта, панелі, точки інтеграцій, запис, через який шле облікова система;
- записи TXT і записи автентифікації хмарки не мають, але перевіряти їх усе одно треба: SPF, ключі DKIM і запис DMARC — це TXT, і саме їх найлегше загубити при частковому імпорті.
Просте правило: помаранчеве лише на тому, що віддає вебсторінку. Усе інше сіре.
Перевірка 3: те, що імпорт губить завжди
Крім MX і хмарок, у відбудованій зоні майже завжди бракує ось цього. Варто пройтись по одному:
- запис SPF, без якого вихідна пошта починає падати в спам за кілька годин;
- ключі DKIM, що живуть на неочевидних піддоменах, яких ніхто не памʼятає;
- запис DMARC, якщо він був;
- перевірочні TXT для Google, Microsoft, Search Console тощо: їхня відсутність нічого не ламає одразу, але одного дня сервіс «розверифіковується», і ніхто не повʼязує причину;
- запис autodiscover чи автоматичні налаштування поштового клієнта, без яких Outlook перестає налаштовуватись сам;
- CNAME зовнішніх сервісів: розсилки, рахунки, відстеження відправлень.
Як полагодити зараз
- Дістань стару зону. Якщо попередня панель ще доступна — вивантаж її. Якщо ні, записи можна опитати по одному, і публічна історія DNS теж допомагає.
- Звір рядок за рядком із поточною зоною в Cloudflare. Не на око, а поруч.
- Поверни MX з початковими пріоритетами і зроби сірим усе, що не є вебом.
- Перевір справжнім листом із зовнішньої адреси в компанію і назад. Автоматичні тести кажуть, чи існує запис; чи лист доходить — каже тільки лист.
- Дочекайся поширення, яке залежить від TTL, виставлених до зміни. Якщо вони були високі, чекати доведеться довше — саме тому їх знижують перед міграцією, а не після.
А листи, що приходили, поки все було зламане?
Залежить від того, хто їх слав. Серйозний сервер не викидає лист після першої невдалої спроби: він ставить його в чергу і повторює днями. Тож немала частина пошти прийде сама, щойно записи повернуться.
Не повернуться ті листи, які відхилили остаточно, і ті, що їх слали системи без повторів — вебформи, автоматичні сповіщення, деякі платформи виставлення рахунків. Про них варто попередити ключових контрагентів, а не сподіватися.
Як сюди не потрапити
Перехід на Cloudflare — гарна ідея: швидкий DNS, керований HTTPS, кеш і захист у комплекті. Проблема не в ідеї, а в послідовності.
Порядок, який не шкодить: вивантажити зону, знизити TTL за добу, відбудувати і звірити, зробити сірим усе, що не веб, змінити сервери імен у неробочий час і перевірити пошту одразу після, а не наступного дня.
Якщо пошта стоїть просто зараз і ти волієш, щоб хтось подивився зону замість вгадування, налаштування й підтримка Cloudflare — це саме ця робота. А якщо виявиться, що проблема глибша за сам перехід, продовжуємо на корпоративній пошті.