Міграція домену: вплив на доставлення пошти

Що змінюється, коли ви мігруєте домен

Міграція домену на папері виглядає просто: спрямувати трафік на новий домен, скопіювати вміст і рухатися далі. З поштою так не буває. Домен відправника, записи DNS, ланцюжок автентифікації та довіра, яку ви вибудували з поштовими провайдерами, змінюються одночасно, і навіть одного відсутнього запису достатньо, щоб виникли проблеми з доставленням електронної пошти після міграції домену.

Зазвичай першими змінюються 4 речі: репутація відправника, SPF, DKIM і DMARC. Одержувач не бачить цих деталей, але Gmail, Outlook і Yahoo бачать, і вони порівнюють старі сигнали з новими, перш ніж вирішити, чи потрапить ваше повідомлення у вхідні, на вкладку «Промоакції» чи взагалі нікуди. Перейменування без плану — це лотерея.

Довіра формується повільніше, ніж DNS. Якщо новий домен почне надсилати 5 000 повідомлень у перший день, поштові провайдери можуть сприйняти його як нового відправника без історії. Бренд може зберегти логотип, тон і якість списку, але все одно втратити місце у вхідних, бо домен змінився і змінився сам характер надсилання.

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

Поширені проблеми з доставленням електронної пошти після міграції

Перший симптом часто тихий: повідомлення потрапляють у спам лише в одного провайдера, а потім це поширюється ще на 2 чи 3. Така картина зазвичай вказує на проблеми з репутацією або автентифікацією, а не з контентом. Невеликі збої швидко стають помітними.

Ще одна поширена проблема — відкладення доставки. Поштові провайдери можуть тимчасово відхиляти повідомлення й просити відправника спробувати пізніше. Якщо система надсилання надто агресивно повторює спроби, затримка може перетворитися на загальне уповільнення, і кампанія, яка мала зайняти 10 хвилин, розтягується на години.

Деякі команди після міграції бачать сплески відмов. Такий сплеск може означати, що новий домен не має потрібних записів DNS, поштовий потік спрямовано не туди або одержувачі більше не хочуть приймати листи від відправника, якого не впізнають. Тут важливий текст помилки, адже «тимчасова» та «постійна» відмова — це зовсім різні ситуації.

Повне блокування надсилання — жорсткіший варіант. Провайдер просто відмовляється приймати пошту. Таке може статися після різкої зміни обсягу, невдалого проходження перевірки автентифікації або поганого сигналу репутації, пов’язаного з новим доменом. Одна заблокована кампанія може вплинути і на наступні 3, якщо ніхто не зупиниться й не перевірить код причини.

Як міграція домену впливає на SPF, DKIM і DMARC

SPF, DKIM і DMARC — це три записи, які найчастіше ламаються під час міграції. SPF може не спрацювати, якщо новий сервіс надсилання не додано до списку. DKIM може не пройти перевірку, якщо змінився селектор або ключ не був скопійований. DMARC може провалитися, якщо вирівнювання між видимим доменом From і автентифікованим доменом більше не збігається.

Проблему з вирівнюванням легко не помітити. Повідомлення може успішно пройти DKIM для одного домену й усе одно не пройти DMARC, бо адреса From показує інший домен, а поштовим провайдерам важливі обидва. Якщо ідентичність відправника та ідентичність автентифікації розходяться, доставлення у вхідні зазвичай страждає.

Деякі міграції залишають стару поштову платформу, змінюючи лише сайт. Але й тоді автентифікація може зламатися. Зміна хостингу DNS, новий піддомен або нова вихідна IP-адреса можуть змінити весь шлях. Якщо вам потрібно чітко розкласти технічну частину, стаття про налаштування DKIM SPF DMARC для транзакційної пошти стане корисним доповненням, як і практичне налаштування SPF DKIM DMARC після міграції.

Ще одна пастка: під час перенесення платформи DKIM-ключі іноді генерують заново, але новий ключ не публікують у DNS до запуску. Через це пошта підписується ключем, який жоден отримувач не може перевірити. Лист може й далі виходити із сервера, але без підтвердження він стає значно менш надійним.

Перевірки DNS, MX і маршрутизації пошти

DNS — це панель керування, а записи MX визначають, куди має надходити вхідна пошта. Після міграції перевірте і шлях відправлення, і шлях отримання. Домен може працювати для вебтрафіку, тоді як маршрут пошти все ще вказує на неправильний хост, що призводить до втрати відповідей, невдалих перевірок і заплутаних звернень у підтримку.

Спочатку перевірте запис MX. Потім підтвердьте записи A або CNAME, які підтримують поштовий хост, і переконайтеся, що всі піддомени, які використовуються для надсилання, відстеження або відповідей, і далі резолвляться. Запис, який о 9:00 виглядає нешкідливим, до полудня може зламати скидання пароля.

Обробка відповідей заслуговує окремої перевірки. Якщо видима адреса From уже на новому домені, а скринька reply-to все ще на старому, користувачі можуть потрапити в глухий кут. Це не завжди шкодить доставленню напряму, але шкодить довірі, а довіра впливає на подальшу взаємодію.

Командам, які надсилають і маркетингову, і транзакційну пошту, варто перевіряти маршрутизацію з обох боків. Неправильний запис MX може не зупинити розсилку, але здатен заблокувати листи для підтвердження акаунта або підтвердження замовлення. Якщо поштовий стек змішаний, порівняйте його з тим, що означає SMTP relay для node.js, перш ніж вважати шлях надсилання чистим.

Репутація відправника та міркування щодо прогріву

Міграція домену може скинути або послабити сигнали репутації навіть тоді, коли список адрес не змінився. Поштові провайдери читають патерни, а не обіцянки. Якщо відправник переходить із 200 листів на день до 20 000 на новому домені, такий стрибок виглядає ризиковано, особливо якщо рівень взаємодії ще невідомий.

Прогрів допомагає, бо розподіляє ризик на 7, 14 або 30 днів замість того, щоб змушувати новий домен доводити себе відразу. Починайте з найбільш залучених отримувачів, а до старіших сегментів переходьте лише після стабільного розміщення у вхідних. Це не ефектно, але працює частіше, ніж велике запускове розсилання.

Обсяг — лише одна частина репутації. Рівень скарг, відмов і позитивна взаємодія також формують картину. Відправник із хорошими показниками відкриття на старому домені все одно може просісти після міграції, якщо новий домен одночасно починає з «холодної» історії та нового IP.

Іноді рішення — не технічне, а поведінкове. Сповільніться. Надішліть наступні 3 кампанії лише залученим користувачам. Слідкуйте за рівнем відповідей і розміщенням у вхідних, перш ніж додавати менш активні контакти. Міграція домену винагороджує терпіння значно більше, ніж ентузіазм.

Діагностичні кроки для пошуку проблем із доставленням

Почніть із тексту відмови. Прочитайте SMTP-код, зрозумілий для людини текст і будь-яку примітку від провайдера. Код 4xx означає тимчасову проблему; код 5xx — жорстку відмову. Саме ця різниця вирішує, чи потрібно повторити спробу, чи розслідувати проблему, чи припинити надсилання на цю адресу.

Потім перегляньте заголовки повідомлення. Заголовки показують шлях, яким пройшла пошта, результати автентифікації та іноді точне місце, де повідомлення втратило довіру. Якщо заголовки відсутні або неповні, ви шукаєте причину наосліп. Для будь-якої міграції домену це дуже погана позиція.

Чорні списки теж важливі, хоча вони не пояснюють усе. Якщо вихідна IP-адреса або домен є в основному списку, вам потрібно з’ясувати чому і чи актуальне це внесення. Один список може заблокувати кампанію, але чистий список не гарантує потрапляння у вхідні.

Тут економлять час інструменти для тестування. Запускайте перевірки до й після кожної зміни та порівнюйте результати замість того, щоб дивитися на один зелений індикатор. Посібник про інструменти для тестування доставлення електронної пошти · YourTrend допоможе структурувати такі перевірки, особливо коли проблема неочевидна лише з поштової скриньки.

Слідкуйте за таймлайном. Якщо скарги починаються через 2 години після міграції, це вказує на автентифікацію або маршрутизацію. Якщо падіння починається після третьої кампанії, більш імовірні репутація та обсяг. Патерни кращі за здогади.

Як виправити доставлення після міграції домену

Спочатку виправте записи. Опублікуйте правильні значення SPF include, за потреби оновіть DKIM-ключі та підтвердьте вирівнювання DMARC. Потім переконайтеся, що платформа надсилання справді використовує оновлені записи, а не кешовані налаштування зі старого домену. Зміна DNS, яка ніколи не доходить до поштового сервера, нічого не змінює.

Далі виправте інфраструктуру надсилання. Оновіть домен MAIL FROM, домен для відповідей, трекінгові посилання та всі піддомени, що використовуються для автентифікації або обробки відмов. Якщо обробка відмов досі прив’язана до старого домену, скарги та відмови можуть збиратися не там, де треба. Це створює повільний витік.

Повідомлення для одержувачів також може допомогти, особливо для транзакційної пошти. Якщо сповіщення про акаунт або білінг можуть потрапити до обережної аудиторії, повідомте ключовим користувачам, що домен змінився і листи тепер приходитимуть з іншої адреси. Для команд, яким потрібен глибший операційний погляд, події email webhook для транзакційної пошти допоможуть відстежувати події доставки після виправлення.

Правила виключення потрібно переглянути до того, як ви щось надішлете повторно. Старі скарги, відписки та жорсткі відмови мають і далі залишатися виключеними на новому домені. Якщо вам потрібна суворіша політика, стаття про керування списком виключень електронної пошти · YourTrend варта уваги перед наступною кампанією.

Не поспішайте з повторним надсиланням. Якщо у 2 основних поштових провайдерів були проблеми, спочатку усуньте першопричину, а потім протестуйте ще раз на невеликій вибірці. Друга невдача може бути важчою для відновлення, ніж перша.

Найкращі практики, щоб запобігти майбутнім проблемам із доставленням

Плануйте міграцію так, ніби пошта є в кімнаті вже з першого дня. Команди, що працюють із сайтами, часто сприймають перенесення домену як проєкт із контентом або хостингом, але в пошти є власні залежності. Залучіть поштового провайдера, власника DNS, команду підтримки та того, хто керує автентифікацією. Чотири людини на одній зустрічі можуть зекономити 4 дні пізніше.

Створіть передзапусковий чекліст. Перед перемиканням підтвердьте SPF, DKIM, DMARC, MX, маршрутизацію reply-to, обробку відмов і домени для відстеження. Потім протестуйте щонайменше у 2 великих провайдерів, бо однієї перевірки вхідних недостатньо. Якщо вам потрібна ширша рамка, найкращі практики доставлення електронної пошти дають ширшу базу для щоденного надсилання.

Прогрів слід закладати в план міграції, а не додавати після першої скарги. Використовуйте поетапний календар із 3 групами отримувачів: дуже залучені користувачі, нещодавно активні користувачі та всі інші. Така послідовність зменшує шанс, що новий домен почне своє життя з уникальних проблем.

Моніторинг має залишатися активним щонайменше 30 днів після запуску. Відстежуйте рівень відмов, скарги на спам, перевірки розміщення у вхідних і збої автентифікації. Якщо запис ламається на 12-й день, команда повинна це побачити раніше, ніж користувачі. Те саме стосується обробки відписок; якщо новий домен змінює шлях посилання або логіку футера, перегляньте, чому найкращі практики відписки від електронної пошти важливі перед наступним надсиланням.

І остання звичка допомагає більше, ніж здається: ведіть журнал міграції. Записуйте старий запис, новий запис, дату, відповідального та причину кожної зміни. Коли проблеми з доставленням електронної пошти після міграції домену з’являться через 3 тижні, цей журнал може зекономити години пошуку навмання.