Домен, SSL и почта: SPF, DKIM, DMARC для деловой почты

Чтобы деловая почта на вашем домене доходила до адресатов и не подделывалась, в DNS нужны три записи: SPF (кому разрешено слать письма от домена), DKIM (цифровая подпись письма) и DMARC (политика, что делать с письмами, не прошедшими проверку). Вместе с корректно настроенным SSL на сайте они составляют минимальный набор доверия для домена компании. Ни одна из этих записей не сложна, но ошибки в них приводят к тому, что счета и коммерческие предложения оказываются в папке «Спам».

Ниже порядок настройки, типичные ошибки и способы проверки. Конкретные значения записей зависят от вашего почтового провайдера, поэтому актуальные параметры всегда берите из его документации.

Как связаны домен, DNS, SSL и почта

Домен это имя, которое вы арендуете у регистратора. DNS это справочник, где для этого имени указано, на какой сервер вести посетителей сайта, какой сервер принимает почту и какие дополнительные проверки действуют. Все настройки лежат в виде записей разных типов: A и AAAA для сайта, MX для почты, TXT для текстовых служебных записей, CNAME для псевдонимов.

SSL-сертификат отвечает за шифрованное соединение с сайтом (адрес начинается с https). К почте он относится косвенно: сертификаты используются и для защиты соединения между почтовыми серверами, но обычно этим занимается провайдер почты. Проверки SPF, DKIM и DMARC работают отдельно и целиком живут в DNS.

Первое, что я проверяю в проектах такого рода: кто реально управляет DNS. Нередко доступ к зоне домена остался у веб-студии, которая делала сайт пять лет назад, или у сотрудника, который давно ушёл. Прежде чем что-то настраивать, убедитесь, что вы знаете регистратора домена, владельца аккаунта и можете войти в панель управления.

SPF: список серверов, которым разрешено отправлять письма

SPF это TXT-запись на корневом домене, где перечислены источники, которым разрешено отправлять почту от вашего имени. Получающий сервер смотрит на адрес отправителя, находит запись и проверяет, совпадает ли IP-адрес отправившего сервера с разрешёнными.

Пример структуры записи (значения условные):

example.kz.  TXT  "v=spf1 include:_spf.mailprovider.example ip4:203.0.113.10 ~all"

Что здесь есть:

• v=spf1 обозначает версию;
• include: подключает список серверов вашего почтового провайдера;
• ip4: разрешает конкретный адрес, например сервер сайта, который шлёт уведомления;
• ~all или -all в конце определяет, как относиться ко всему остальному: мягко (подозрительно) или жёстко (отклонять).

Типичные ошибки:

1. Две SPF-записи на одном домене. По стандарту запись должна быть одна, иначе проверка завершится ошибкой. Если у вас несколько сервисов, объедините их в одну строку.
2. Слишком много include. Есть ограничение на число DNS-запросов при проверке, и превышение приводит к сбою.
3. Забытые сервисы: рассылка, CRM, формы на сайте, бухгалтерская система. Всё, что шлёт письма с вашего домена, должно быть учтено.
4. Сразу строгий режим без проверки. Начинайте с мягкого и переходите к жёсткому только когда убедились, что легитимные источники не потеряны.

DKIM: подпись, которая подтверждает, что письмо не подменено

DKIM работает на паре ключей. Почтовый сервер подписывает исходящие письма закрытым ключом, а открытая часть публикуется в DNS. Получатель берёт открытый ключ, проверяет подпись и убеждается, что письмо отправлено с авторизованного сервера и не менялось по дороге.

В DNS это обычно TXT-запись (или CNAME, если провайдер так устроил) на специальном поддомене с «селектором»:

selector1._domainkey.example.kz.  TXT  "v=DKIM1; k=rsa; p=<открытый ключ от провайдера>"

Ключ и имя селектора вы получаете в панели почтового сервиса. Копировать нужно целиком и аккуратно: частая ошибка, это обрезанный из-за переноса строки ключ или лишние пробелы и кавычки, которые добавил интерфейс регистратора. Длинные значения некоторые панели просят разбивать на части, следуйте их инструкциям.

Каждый сервис, который отправляет от вашего имени, должен иметь свою подпись. Если рассылки идут через отдельный сервис, DKIM настраивается и для него. Закрытый ключ нигде не публикуется и не пересылается, он остаётся у провайдера.

DMARC: политика и отчёты

DMARC связывает SPF и DKIM и объясняет получателям, что делать, если проверки не прошли. Кроме того, он присылает вам отчёты, по которым видно, кто и откуда отправлял письма с вашего домена. Запись ставится на поддомен _dmarc:

_dmarc.example.kz.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.kz"

Параметр p определяет политику:

• none: ничего не блокировать, только собирать отчёты;
• quarantine: подозрительные письма отправлять в спам;
• reject: отклонять письма, не прошедшие проверку.

Правильный путь такой: начать с p=none, пару недель изучать отчёты, найти все легитимные источники и исправить SPF и DKIM для них, затем перейти на quarantine, а потом, при чистых отчётах, на reject. Если сразу поставить строгую политику, можно потерять письма от забытого сервиса, например от системы выставления счетов.

Выравнивание (alignment) тоже важно: DMARC требует, чтобы домен в адресе «От кого» совпадал с доменом, прошедшим SPF или DKIM. Сервис рассылок, который подписывает письма своим доменом, а не вашим, не пройдёт DMARC, пока вы не подключите ему DKIM на вашем домене.

Порядок внедрения шаг за шагом

Для типовой компании я рекомендую такую последовательность:

1. Составить список всех систем, которые отправляют письма с вашего домена: основная почта, сайт, CRM, рассылки, бухгалтерия, служба поддержки.
2. Проверить текущие записи в DNS и найти дубликаты SPF.
3. Настроить DKIM в каждом сервисе и опубликовать ключи.
4. Привести SPF к одной записи со всеми источниками.
5. Добавить DMARC с p=none и адресом для отчётов.
6. Через две-четыре недели разобрать отчёты и исправить расхождения.
7. Поднять политику до quarantine, а затем, если всё чисто, до reject.

Для отчётов удобно использовать специальный сервис-обработчик: сырые отчёты приходят в формате XML и читаются тяжело. Выберите сервис по вашим требованиям и оценкам, я не навязываю конкретный.

SSL и домен: что проверить на стороне сайта

Хотя к почте сертификат относится косвенно, он часть общей гигиены домена. Проверьте:

• сертификат действителен и продлевается автоматически, а ответственный за контроль назначен;
• http перенаправляет на https;
• все поддомены, которые используются, покрыты сертификатом;
• в DNS нет записей на старые, неиспользуемые серверы (так называемые «висячие» записи, на которые можно перехватить поддомен);
• включена блокировка переноса домена и двухфакторная аутентификация в аккаунте регистратора.

Последний пункт часто упускают. Потеря контроля над регистратором это потеря и сайта, и почты. О защите учётных записей подробнее в материале про пароли и двухфакторную аутентификацию в компании.

Как проверить, что всё работает

Проверить можно без сложных инструментов. Отправьте тестовое письмо на ящик у крупного почтового сервиса и откройте полные заголовки письма. В них будут строки с результатами spf=pass, dkim=pass и dmarc=pass. Если где-то стоит fail или neutral, смотрите именно на эту проверку.

Есть и сторонние сервисы, которые принимают тестовое письмо и показывают оценку настроек. Они удобны, но результаты стоит перепроверять по заголовкам: сервис может не знать о ваших особенностях.

Типичные симптомы проблем:

• письма клиентам уходят в спам, хотя раньше доходили;
• получатели говорят, что получили письмо, которое вы не отправляли (признак подделки);
• рассылка проходит, а обычная почта нет, или наоборот: значит, настроен только один источник.

Частые вопросы

Нужны ли все три записи или достаточно одной?

Рекомендуется настроить все три. SPF и DKIM проверяют разные аспекты, а DMARC объединяет их и добавляет политику и отчёты. Крупные почтовые сервисы всё чаще предъявляют требования именно к такой связке, особенно для массовых рассылок, поэтому настройка одной записи даёт лишь частичный эффект.

Сколько времени распространяются изменения в DNS?

Зависит от параметра TTL, который задан у записи. Обычно от нескольких минут до нескольких часов, иногда дольше. Перед важными изменениями удобно заранее снизить TTL, чтобы при ошибке быстрее откатиться.

Можно ли настроить это самостоятельно?

Если у вас есть доступ к DNS и вы аккуратны, то да: инструкции есть у каждого провайдера почты. Риск в том, что ошибка в записи может нарушить доставку писем. Поэтому сначала сохраните текущие записи, вносите изменения по одной и проверяйте результат после каждой.

Достаточно ли DMARC для защиты от фишинга?

Он защищает от подделки именно вашего домена в адресе отправителя, но не закрывает схожие домены с опечатками и не заменяет обучение сотрудников. Это один слой защиты из нескольких.

Если вам нужна помощь с аудитом домена и почты или с настройкой отправки писем с сайта, загляните на страницу про ИТ-инфраструктуру и проекты или напишите в Telegram.