Почта на своём домене: MX, SPF, DKIM и DMARC без путаницы
Объясняем, куда приходят письма, кто вправе отправлять почту от домена, как работает подпись DKIM и когда усиливать политику DMARC.
Содержание
Почта домена использует несколько DNS-записей, и каждая отвечает на свой вопрос. MX говорит, куда доставлять входящие письма. SPF перечисляет допустимые источники отправки. DKIM позволяет проверить криптографическую подпись сообщения. DMARC связывает результаты SPF/DKIM с доменом в видимом поле From и публикует политику обработки.
Настраивать их следует по инструкции фактического почтового сервиса. Нельзя склеивать примеры разных поставщиков: один лишний источник в SPF или чужой DKIM-ключ ослабляет защиту и ломает доставку.
Составьте список всех почтовых потоков
До DNS перечислите, кто отправляет письма от домена:
- почтовые ящики сотрудников;
- сайт и формы обратной связи;
- CRM и служба поддержки;
- сервис рассылок;
- платёжные и системные уведомления;
- старый сервер, который ещё используется при переносе.
Для каждого потока запишите домен в видимом From, технический MAIL FROM, способ подписи DKIM и владельца настройки. MAIL FROM — адрес, который SMTP использует для возврата ошибок; он может отличаться от адреса автора, который видит человек.
Не добавляйте сервис в DNS «на будущее». Любое разрешение отправлять почту от домена расширяет круг систем, компрометация которых повлияет на его репутацию.
MX направляет входящие письма
MX означает mail exchanger — сервер, принимающий почту для домена. Значением является доменное имя почтового сервера, а не его IP. К записи добавляется числовой приоритет: отправитель сначала пробует сервер с меньшим числом.
Если почтовый провайдер выдал несколько MX, добавьте весь набор с указанными приоритетами. Не заменяйте его одним сервером и не придумывайте резервный адрес. Резервный MX должен быть действительно настроен принимать и передавать вашу почту, иначе он станет источником потерь или спама.
Удалите MX прежнего провайдера только после переноса ящиков и проверки новой доставки. Старые и новые серверы могут принять разные письма, если оставить два несогласованных набора с равным приоритетом.
SPF описывает допустимые источники отправки
SPF публикуется как TXT-запись и начинается с версии v=spf1. Механизмы политики разрешают конкретные IP-адреса или включают правила почтового сервиса. Получатель сравнивает источник SMTP-соединения с этой политикой.
У одного имени должна быть одна SPF-политика. Если сайт и сервис рассылок отправляют от одного домена, их разрешения объединяют в одну строку по документации обоих поставщиков. Две отдельные записи v=spf1 создают постоянную ошибку проверки.
Не используйте разрешение «всему интернету» и не добавляйте диапазон, происхождение которого не понимаете. SPF имеет ограничение на число DNS-поисков во время проверки; длинная цепочка include может привести к ошибке. Поставщик должен сообщить точный фрагмент и порядок удаления при отключении услуги.
SPF проверяет технический домен MAIL FROM или HELO, а не обязательно адрес, видимый пользователю. Поэтому одной SPF-записи недостаточно для защиты поля From.
DKIM подтверждает подпись сообщения
DKIM добавляет к письму цифровую подпись. Отправляющий сервис хранит закрытый ключ и подписывает выбранные заголовки и тело. Получатель извлекает из подписи домен d= и селектор s=, затем находит открытый ключ в DNS.
Селектор позволяет иметь несколько ключей одновременно. Если сервис выдал селектор mail1, запись обычно располагается по имени mail1._domainkey.example.com. Точное имя и значение копируйте из панели поставщика. Не переносите пробелы, кавычки и разбиение длинной TXT-строки между разными интерфейсами без проверки итогового DNS-ответа.
Закрытый ключ не публикуется в DNS. Если вы управляете собственным почтовым сервером, ограничьте доступ к нему и предусмотрите ротацию. При смене ключа сначала опубликуйте новый открытый ключ, затем переведите подпись и только после окончания перехода удалите старый.
DMARC связывает проверку с видимым отправителем
DMARC публикуется в TXT по имени _dmarc.example.com. Он проверяет, прошёл ли SPF или DKIM и согласован ли прошедший домен с доменом в видимом поле From. Это называется alignment — выравнивание идентификаторов.
Политика p=none запрашивает наблюдение без просьбы помещать не прошедшие письма в карантин или отклонять их. p=quarantine просит относиться к ним как к подозрительным, а p=reject — отклонять. Решение в итоге принимает получающая сторона, но публикация политики выражает позицию владельца домена.
Начинайте с отчётов и p=none, если ещё не знаете все источники. Агрегированные отчёты показывают, какие системы отправляют почту, как проходят SPF/DKIM и совпадают ли домены. Адрес для отчётов должен уметь принимать и обрабатывать большой машинный поток; личный ящик быстро заполнится.
После исправления законных отправителей постепенно усиливайте политику и контролируйте результат. Мгновенный p=reject на домене с неизвестными системами способен отклонить счета, сбросы пароля и обращения клиентов.
Настраивайте по одному поставщику и проверяйте письмо
Добавьте MX и убедитесь, что письмо приходит в новый ящик. Затем настройте отправку одного сервиса, опубликуйте его SPF/DKIM и отправьте сообщение на внешний тестовый ящик. В технических заголовках результата должны быть spf=pass и/или dkim=pass, а DMARC — pass при согласованном домене.
Повторите для сайта, CRM и рассылок. Проверка одного письма от сотрудника не подтверждает остальные пути. После изменений следите за отказами доставки и DMARC-отчётами.
Если письма перестали уходить после правки SPF, верните сохранённую рабочую TXT-запись и соберите новую политику вне production. Если сломался DKIM, временно верните прежний селектор и ключ; не публикуйте закрытый ключ. При проблеме DMARC ослабьте политику до режима наблюдения, но продолжите разбирать невыравненные источники.
DNS-диагностика записей разобрана в статье о dig и nslookup, а защита аккаунта, через который их меняют, — в уроке о доступе к домену.
Источники
Самопроверка
Проверьте, что материал усвоен
Ответьте на все вопросы. Результат сохранится только в этом браузере и будет учтён в статистике прочитанных материалов.
Разбираем коротко
Частые вопросы
Можно ли настроить только MX и отправлять почту?
MX отвечает за приём. Отправка может технически работать без него, но для подтверждения источников и защиты домена нужны согласованные SPF, DKIM и DMARC.
Сколько SPF-записей должно быть у одного имени?
Одна SPF-политика в TXT для соответствующего имени. Источники нескольких сервисов объединяют по их документации, а не публикуют отдельные конкурирующие записи.
Нужно ли сразу ставить DMARC p=reject?
Сначала инвентаризируйте законных отправителей, настройте SPF и DKIM, проверьте выравнивание и отчёты. Жёсткую политику включают поэтапно, чтобы не отклонить собственные письма.
