Сайт находится в Timeweb, домен куплен у другого регистратора, а DNS обслуживаются отдельным сервисом. После создания почтового ящика письма отправляются, но попадают в Спам. Здесь важно понять, какая панель действительно публикует записи домена. Одинаково выглядящие таблицы DNS в разных кабинетах не обязательно описывают действующую зону.
Не переносите все записи наугад и не меняйте NS только ради почты. Для диагностики сначала достаточно установить текущую делегацию, получить рекомендуемые значения для используемого отправителя и сверить их с публичным DNS. Такой порядок помогает избежать поломки сайта и других почтовых систем того же домена.
Разделите три роли
Регистратор управляет регистрацией и делегацией домена. DNS-провайдер публикует его записи. Почтовый сервис подписывает и передаёт сообщения. Все роли могут принадлежать одной компании, но это не обязательное условие. Покупка домена в Timeweb не доказывает, что сейчас используются его NS, а размещение сайта не доказывает отправку через его почту.
Запишите текущие NS и источник этих данных. Затем найдите рабочую зону в соответствующем кабинете. Если в локальной панели хостинга есть нужная TXT-запись, а авторитетный сервер её не возвращает, исправление ещё не опубликовано там, где его ищут внешние получатели.
SPF должен описывать реальные отправляющие системы
В инструкции Timeweb по почтовым DNS-записям есть пример SPF для его серверов и совместного использования с другим сервисом. Применяйте такие значения к своей схеме после проверки, кто действительно отправляет почту. Не добавляйте хостинг в разрешённые источники только потому, что на нём расположен сайт, если сайт использует исключительно внешний SMTP.
На одном имени домена не создают несколько независимых SPF-записей. При добавлении нового источника изменяют существующую политику, сохраняя нужные действующие отправители. Перед правкой составьте список: переписка сотрудников, уведомления сайта, CRM, рассылочная система. Иначе исправление сайта может одновременно сломать аутентификацию писем отдела продаж.
DKIM начинается с подписанного сообщения
В полученной копии найдите DKIM-Signature. Значение d= указывает домен подписи, s= — селектор. Именно эта пара определяет имя записи, которую будет искать проверяющая сторона. Не перебирайте только популярные имена mail или default: нужный селектор должен следовать из реального письма или настроек отправляющей системы.
Если подписи нет, публикация случайного ключа не добавит её в письмо. Нужно включить подписывание на фактическом отправителе. Если подпись есть, проверьте соответствующий открытый ключ в действующем DNS. Закрытый ключ остаётся у подписывающей системы; его нельзя вставлять в TXT-запись, форму тестирования или публичную переписку с поддержкой.
Что здесь делают MX и DMARC
MX указывает, куда принимается входящая почта домена. Сам по себе правильный MX не доказывает, что исходящий IP разрешён или письмо подписано. Поэтому замена MX не является универсальным способом исправить попадание исходящей почты в Спам. Сначала определите, есть ли вообще проблема входящего маршрута.
DMARC связывает успешную SPF- или DKIM-проверку с видимым From. Наличие записи _dmarc ещё не подтверждает успех этой проверки. Ужесточать политику ради «улучшения репутации» без проверки всех законных потоков не стоит. При несогласованном отправителе изучите конкретные домены, а не только цвет значка в панели.
Проверьте опубликованное изменение письмом
После правки сохраните старое и новое значение, время и результаты DNS-запросов. Учитывайте кэширование: отдельный ответ ещё может отражать предыдущую версию. Когда нужные значения видны, создайте новую контрольную отправку. Старое письмо не получает другую подпись задним числом, а сохранённый отчёт не обязан пересчитываться при каждом открытии.
Используйте тест размещения Check через тот же ящик или приложение. Сравните аутентификацию новой копии, её источник и папку с исходным замером. Содержимое оставьте прежним, чтобы не смешивать проверку DNS с изменением текста. Если работает несколько отправителей, каждый из них требует своей контрольной отправки.
Отделите исправленный DNS от результата фильтра
Можно подтвердить, что новый ключ опубликован и конкретное письмо прошло DKIM. Это ещё не доказывает причину прежнего Спама и не гарантирует будущие Входящие. Если аутентификация проходит, а папка остаётся прежней, продолжайте диагностику отдельным опытом, сохранив уже работающие настройки.
Методология Check объясняет разницу между опубликованными DNS-настройками, проверкой копии и наблюдением папки. Для передачи задачи другому администратору оставьте карту ролей и точные имена записей. Она предотвращает повторную правку неработающей зоны и помогает воспроизвести результат после очередного переноса инфраструктуры.
Видео-памятка: что проверить
Видео без звука, 24 секунды. Текстовая версия краткого плана:
- Настройки публикуют там, где находятся авторитетные DNS.
- MX описывает входящую почту и не подтверждает отправителя.
- DKIM проверяют по селектору реального письма.