Подключение и перенос корпоративной почты: реестр отправителей, сохранение переписки, точные DNS-записи своего сервиса, проверка Authentication-Results и план возврата MX.
Определите состав почтовой системы
Посчитайте пользователей, общие адреса, алиасы, объём и срок хранения. Отдельно учтите письма сайта, CRM и рассылочного сервиса: они могут отправляться от того же домена через разные системы. Не считайте все источники автоматически разрешёнными после подключения одного ящика.
Выберите владельца аккаунта и порядок выдачи доступа. Общий пароль отдела затрудняет отзыв прав и расследование. Если сервис поддерживает делегирование и общие ящики, сопоставьте это с задачей вместо пересылки пароля всем сотрудникам.
Сохраните исходную зону
До изменения MX запишите действующие NS и все почтовые записи. Уточните, где находится активная DNS-зона. Если сайт переезжает, переносите только нужные записи и не меняйте почтовый маршрут без согласованного плана.
Заранее подготовьте новые ящики, перенос старой переписки и временное сосуществование, если это требуется. Изменение MX не копирует письма из прежнего сервиса. Не удаляйте старые данные до проверки нового доступа и полноты переноса.
Назначение записей
| Запись | Роль | Откуда брать значение |
|---|---|---|
| MX | Куда доставлять входящие | У выбранного почтового сервиса |
| SPF | Какие источники разрешены политикой | Из документации всех легитимных отправителей |
| DKIM | Проверка подписи сообщения | Публичный ключ/selector сервиса |
| DMARC | Политика и отчёты аутентификации | После учёта источников и проверки |
| Проверочная TXT | Подтверждение управления | Из вашего кабинета |
Составьте реестр всех легитимных отправителей
Один домен часто используют сотрудники, WordPress, CRM, сервис уведомлений и рассылочная платформа. У каждого может быть собственный технический адрес возврата и DKIM-подпись. До изменения политики перечислите источники и владельцев. Если проверить только письмо сотрудника, можно пропустить отказ формы сайта или важных уведомлений магазина.
| Источник | Что выяснить | Как проверить |
|---|---|---|
| Ящики сотрудников | Штатный SMTP или веб-интерфейс | Тест наружу и ответ |
| WordPress | Транспорт и фактический From | Обезличенная отправка формы |
| CRM | Домен подписи и возврата | Тестовый сценарий CRM |
| Рассылочная система | Подтверждённый домен и политика сервиса | Тест на контролируемую выборку |
| Прочие приложения | Владелец, способ отправки, необходимость | Отдельный журнал и тест |
Не разрешайте неизвестный IP только потому, что он появился в отчёте. Сначала свяжите его с утверждённым сервисом. Иначе попытка улучшить доставку может расширить перечень посторонних отправителей. При прекращении сервиса обновляйте реестр и соответствующую конфигурацию, сохраняя работающие источники.
Настройте записи без копирования чужих примеров
Не создавайте несколько независимых SPF-политик для одного имени: учтите легитимные источники в корректной общей конфигурации. DKIM требует точного selector и ключа выбранного сервиса. Значения из скриншота чужого аккаунта не подойдут.
Строгую политику DMARC вводите после проверки отправителей и анализа отчётов. Иначе можно отклонить собственные письма CRM или сайта. Адрес для отчётов должен существовать и иметь ответственного; это отдельный поток технических данных.
Что сверять в служебных заголовках
Для тестового сообщения откройте исходные заголовки у получателя. Смотрите Authentication-Results доверенной принимающей системы, видимый From, технический Return-Path и домен подписи DKIM. Простой SPF pass для технического домена сервиса не означает автоматически успешное согласование с доменом автора в DMARC. Проверяйте результат соответствующей проверки, а не ищите любое слово pass в тексте письма.
В октябре 2026 года первичный документ DMARC — RFC 9989, заменивший RFC 7489; агрегированная отчётность описана отдельно в RFC 9990. Для конкретного поставщика всё равно нужна его актуальная инструкция и фактическое поведение. Не копируйте старую политику из сторонней статьи без проверки поддерживаемых параметров и используемой схемы доменов.
Тестовый идентификатор: MAIL-DEMO-001
Отправитель: согласованный тестовый ящик
Маршрут: сотрудник / сайт / CRM
Доставка: получено / отклонено / неизвестно
Authentication-Results: SPF / DKIM / DMARC
Ответное письмо: получено / не получено
Содержимое: обезличенноеПересылка и почтовые списки могут менять путь и содержимое сообщения. Для такого сценария проведите отдельный тест и изучите документацию поставщика; не делайте вывод о всей почтовой системе по одному переадресованному письму. Заголовки могут содержать адреса и инфраструктурные данные — перед передачей обезличьте ненужное.
Проверьте четыре направления
Отправьте согласованные тестовые письма наружу и внутрь, проверьте ответ и сообщение от сайта. Используйте собственные контролируемые адреса, без массовой рассылки. Откройте служебные заголовки и исследуйте результаты SPF/DKIM/DMARC, а не только наличие письма во входящих.
Успешная аутентификация не гарантирует попадание во входящие у каждого получателя. На доставку влияют репутация, содержание и политика принимающей стороны. Не обещайте «100% доставки» только после добавления TXT.
Как вводить политику и разбирать отчёты
Сначала подтвердите все утверждённые источники и результаты тестов, затем согласуйте политику обработки не прошедших проверку сообщений. Строгое правило без реестра отправителей способно затронуть собственную CRM. Не рассматривайте мониторинговую политику как полную защиту от подделки: у этапов разная цель и требуется последующее решение по собранным данным.
Для агрегированных отчётов назначьте существующий адрес или согласованный сервис анализа, владельца и правила хранения. Отчётность не следует бесконтрольно отправлять в личный ящик подрядчика. Ошибка настройки адреса отчётов может оставить команду без наблюдения, хотя основная отправка работает. Не включайте индивидуальные сообщения с персональными данными в открытый отчёт проекта.
- Соберите легитимные источники и их документацию.
- Проверьте тестовые сообщения каждого маршрута.
- Разберите неизвестные источники, не разрешая их автоматически.
- Согласуйте целевую политику и область доменов.
- Повторите тесты после изменения и наблюдайте отказы.
Перенос архива и контроль после смены MX
MX изменяет направление новых входящих сообщений и не копирует историю старого ящика. До переключения подготовьте пользователей, алиасы, общие адреса, доступ и способ переноса архива. Проверьте выборку папок, вложений и временных меток. Число сообщений может отличаться из-за представления папок и служебных элементов, поэтому используйте понятный протокол сверки, а не один общий итог без объяснения.
На время перехода предусмотрите доступ к прежнему сервису и обработку сообщений, которые ещё могли попасть туда. Не очищайте старые ящики после первого удачного теста. Согласуйте, кто собирает остаток переписки, как исключаются дубли и когда завершено сосуществование. Переезд сайта может вообще не требовать смены почтового поставщика; это решение принимают отдельно.
Эксплуатация и уход сотрудника
Назначьте правила архива, восстановления, делегирования и отзыва доступа. При увольнении учитывайте приложения, активные сессии и резервные методы входа. Не передавайте ящик новому человеку без согласованного решения владельца данных.
Наблюдайте ошибки доставки и объём. Для собственных серверов добавляются обязанности по обновлению, репутации IP, резервам и очередям. Небольшой компании готовый сервис часто проще, но выбор делается по реальному набору функций и бюджету.
Возврат маршрута без потери новых писем
Если новую систему не удалось принять, возврат MX направит последующую почту по старой схеме после обновления соответствующих ответов. Он не перенесёт уже полученные на новой стороне сообщения. Поэтому сохраните оба состояния, соберите разницу и согласуйте перенос. Частая смена MX без журнала усложняет определение, где находится нужное письмо.
Перед возвратом проверьте, что прежние ящики активны и не истёк договор. Восстановите только нужные записи, не стирая TXT других работающих сервисов. Проверьте приём, отправку, ответы, сайт и CRM. Если причина не установлена, фиксируйте временное восстановление как обход, а не обещание окончательного исправления.
FAQ и итог подключения
MX достаточно для писем из WordPress?
Нет. MX относится к приёму. Отправка сайта требует своего транспорта и проверки аутентификации и доставки.
SPF pass означает DMARC pass?
Не автоматически. Важны домены и их согласование в используемой схеме. Смотрите результат DMARC у доверенного получателя.
Изменение MX переносит старую переписку?
Нет. Архив переносится и проверяется отдельным процессом.
После настройки можно обещать 100% доставки?
Нет. Аутентификация не определяет все решения получателя, репутацию и папку размещения.
Приёмка включает доступ сотрудников, сохранённую историю, все легитимные отправители, тесты приёма и ответа, а также назначенного ответственного за ошибки и продление. Держите схему почты отдельно от размещения сайта и не публикуйте секреты настройки.
Источники и дата
Редакционная переработка: 26.10.2026. Источники относятся к своим версиям продуктов; параметры конкретного проекта необходимо подтвердить отдельно.
