SPF, DKIM и DMARC: настройка защиты корпоративной почты

SPF, DKIM и DMARC — три записи в DNS домена, по которым почтовые серверы получателей отличают письма вашей компании от подделок. SPF перечисляет серверы, которым разрешено отправлять почту от имени домена, DKIM добавляет письму криптографическую подпись, DMARC задаёт, что делать с письмом, не прошедшим ни одну проверку. Настраивают все три и именно в таком порядке.

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

• 24 768 жалоб на компрометацию деловой переписки получило ФБР за 2025 год (IC3 2025 Internet Crime Report)
• 3,05 млрд $ ущерба по этим жалобам — второе место по сумме ущерба среди видов мошенничества (IC3 2025 Internet Crime Report)

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

Что такое SPF, DKIM и DMARC и как они работают вместе

SPF, DKIM и DMARC — три независимые проверки, которые сервер получателя выполняет в момент приёма письма. Каждая отвечает на свой вопрос, и ни одна по отдельности домен не защищает.

• SPF (Sender Policy Framework) — TXT-запись со списком серверов и диапазонов адресов, которым разрешено отправлять почту от имени домена. Проверка сравнивает адрес подключившегося сервера с этим списком. Механизм описан в RFC 7208.
• DKIM (DomainKeys Identified Mail) — криптографическая подпись заголовков и тела письма. Закрытый ключ лежит на отправляющем сервере, открытый публикуется в DNS по имени вида selector._domainkey.домен.
• DMARC (Domain-based Message Authentication, Reporting and Conformance) — запись _dmarc.домен, которая говорит получателю, что делать с непрошедшим письмом, и куда присылать отчёты. Политики описаны в RFC 7489: none, quarantine или reject.

Ключевое понятие в DMARC — выравнивание: домен из видимого поля «От» должен совпадать с доменом, который подтвердил SPF или подписал DKIM. В мягком режиме совпадают корневые домены, в строгом — полные имена. Без выравнивания SPF может пройти, а DMARC всё равно не пройдёт — именно так отсекаются письма, отправленные с чужого домена под вашим именем.

Важно DMARC без SPF и DKIM бесполезен: ему нечего проверять. Сначала две первые записи, и только потом третья.

Как настроить SPF и не упереться в лимит DNS-запросов

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

1. Выпишите отправителей: корпоративная почта, сервис рассылок, CRM, формы на сайте, биллинг, служба поддержки, система уведомлений.
2. Возьмите у каждого сервиса рекомендованный механизм include из его документации — свои адреса сервисы меняют сами, и перечислять их вручную не нужно.
3. Соберите одну запись вида v=spf1 с нужными include и завершающим правилом, опубликуйте её в DNS домена.
4. Поставьте в конце жёсткий отказ -all вместо мягкого ~all, когда убедитесь, что список отправителей полон.
5. Проверьте результат в заголовках тестового письма: там должна появиться строка аутентификации с результатом pass.

Главное ограничение SPF — не длина записи, а число обращений к DNS. RFC 7208 разрешает не больше десяти запросов на всю проверку, считая вложенные include, и требует вернуть permerror, если лимит превышен. Для DMARC это равносильно непройденной проверке. Тот же документ советует ограничить двумя и «пустые» запросы — те, что не вернули ни одной записи.

Ошибка Добавить ещё один include «на всякий случай» и выйти за десять запросов. Запись выглядит правильной, но проверку не проходит ни одно письмо. Лишние include убирают, тяжёлые заменяют перечислением конкретных адресов.

Как включить DKIM и какой ключ выбрать

DKIM включают в панели почтового сервиса: он генерирует пару ключей и выдаёт готовую TXT-запись для DNS. Имя записи складывается из селектора и суффикса _domainkey — например google._domainkey для Google Workspace.

• Длина ключа. В документации Google Workspace сказано прямо: длинные ключи надёжнее коротких, и рекомендуется 2048 бит, если DNS-провайдер их поддерживает. Для писем на личные адреса Gmail минимально допустимый ключ — 1024 бита.
• Селектор. У каждого сервиса свой, поэтому одна и та же почта может подписываться несколькими ключами: отдельно деловая переписка, отдельно рассылки.
• Подпись у всех отправителей. Сервис рассылок, CRM и биллинг тоже должны подписывать письма вашим доменом, иначе после включения строгой политики DMARC они перестанут доходить.
• Смена ключей. Старый селектор выключают не сразу: письма, уже отправленные в путь, подписаны прежним ключом.

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

Как опубликовать DMARC и что показывают отчёты

DMARC — одна TXT-запись по имени _dmarc.домен. Минимальный рабочий вариант состоит из версии, политики и адреса для отчётов. Google в инструкции по настройке советует подождать 48 часов после настройки SPF и DKIM и начинать с политики none.

• p — что делать с непрошедшим письмом: none (ничего), quarantine (считать подозрительным) или reject (отклонить).
• rua — адрес для сводных отчётов: серверы получателей присылают их раз в сутки в виде XML.
• pct — доля писем, к которой применяется политика. Нужен на время перехода, чтобы включать строгий режим постепенно.
• sp — отдельная политика для поддоменов; без неё поддомены наследуют основную.
• adkim и aspf — режим выравнивания для DKIM и SPF: мягкий по корневому домену или строгий по полному имени.

Сводные отчёты — главная причина включать DMARC даже в режиме none. Из них видно все серверы, которые отправляют письма от имени домена: ваши сервисы, забытый старый сайт и чужие серверы, рассылающие подделки. Читать XML руками неудобно, поэтому отчёты заводят в сервис-анализатор или на отдельный ящик с автоматическим разбором.

Как перейти от p=none к p=reject без потери писем

Переход делают постепенно: сначала находят по отчётам всех законных отправителей, потом ужесточают политику. Резкий reject на непроверенном домене отправляет в отказ собственные счета и уведомления.

1. Опубликуйте политику none с адресом для отчётов и соберите данные за две-три недели: столько нужно, чтобы в выборку попали редкие отправители вроде месячных актов.
2. Разберите отчёты и для каждого источника решите, ваш он или нет. Свои доведите до прохождения SPF и DKIM с выравниванием, чужие оставьте — их отсечёт политика.
3. Вынесите массовые отправки на отдельные поддомены: рассылки, уведомления из CRM, транзакционные письма. Тогда проблема в рассылке не задевает деловую переписку.
4. Включите quarantine с небольшим значением pct и поднимайте его до полного охвата, следя за отчётами и обращениями партнёров.
5. Поставьте reject, когда доля непрошедших писем перестанет меняться и будет состоять только из чужих источников.
6. Задайте политику для поддоменов через sp, а для доменов, с которых почту не отправляют, опубликуйте отдельный отказ.

Совет Не меняйте политику в период, когда почта критична: перед сдачей отчётности, во время тендера или распродажи. Ошибку выравнивания в режиме reject заметит не ваш сотрудник, а контрагент.

Что требуют Gmail и Outlook.com от отправителей

Gmail предъявляет требования к аутентификации всем отправителям с 1 февраля 2024 года, Outlook.com — с 5 мая 2025 года. Для крупных отправителей обе службы требуют уже не одну запись, а все три.

Требования опубликованы в рекомендациях Google для отправителей и в политике Outlook.com для почтовых администраторов. У Gmail есть ещё один порог, за которым следят отдельно: доля спам-жалоб в Postmaster Tools должна оставаться ниже 0,3 % (Google Email Sender Guidelines).

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

Частые ошибки и что проверить перед запуском

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

• У домена одна SPF-запись, а не две: вторая делает проверку недействительной.
• Проверка SPF укладывается в лимит DNS-запросов с запасом на будущие сервисы.
• DKIM включён у всех отправителей, а не только у корпоративной почты.
• Поле «От» в письмах из CRM и рассылок — на вашем домене, а не на домене сервиса.
• Запись _dmarc существует, политика не ниже quarantine, адрес для отчётов читает конкретный человек.
• Для поддоменов задана своя политика, а для доменов без исходящей почты опубликован отказ.
• У DNS домена есть ответственный, и доступ к панели регистратора не заперт на одном подрядчике.
• Отчёты просматривают регулярно, а не только в первые две недели после включения.

Что настроить после DMARC: MTA-STS и BIMI

Три записи закрывают подделку адреса, но не шифрование канала и не узнаваемость письма. Дальше идут два шага. MTA-STS (RFC 8461) публикует политику, по которой чужие серверы обязаны доставлять вам почту только по проверенному TLS, а в режиме enforce — отказываться от доставки, если TLS недоступен. BIMI показывает логотип компании в списке писем, и по требованиям BIMI Group политика DMARC для этого должна быть quarantine или reject: логотип дают только домену со строгой политикой.

Что учесть компании в Узбекистане

Технически требования одинаковы в любой стране, но порядок работ зависит от того, у кого лежит DNS домена. У домена в зоне uz записи правят в панели аккредитованного регистратора или у провайдера, которому делегированы серверы имён, и доступ туда нередко остался у подрядчика, делавшего сайт. Первый шаг — вернуть этот доступ компании.

• Почта и рассылки у разных провайдеров. Типичный набор: корпоративная почта у одного сервиса, рассылки у второго, уведомления из CRM у третьего. Каждого нужно внести в SPF и научить подписывать письма вашим DKIM.
• Счёт и акт идут письмом. Текущую переписку компании ведут в Telegram, но счёт, акт и договор отправляют по почте. Это и есть цель подделки: достаточно письма с похожего адреса и новых банковских реквизитов.
• Персональные данные. Закон «О персональных данных» № ЗРУ-547 требует от оператора правовых, организационных и технических мер защиты (lex.uz), а почта остаётся каналом, через который данные уходят наружу чаще всего — об этом мы писали в разборе про утечку персональных данных.
• Люди. Записи в DNS не спасают от письма с действительно чужого домена, похожего на ваш. Здесь работает обучение сотрудников кибербезопасности и привычка сверять реквизиты по телефону.

Как мы настраиваем защиту почты

В Syntra Systems защита почты входит в работы по кибербезопасности. Начинаем с инвентаризации отправителей: часто выясняется, что писем от имени домена уходит больше, чем знает бухгалтерия — старые формы на сайте, забытый сервис рассылок, тестовый сервер. Затем собираем SPF с запасом по лимиту запросов, включаем DKIM у каждого отправителя и ведём домен от none до reject по отчётам, а не наугад.

Эти записи — часть общей картины, которую мы закладываем, когда проектируем защиту: подробнее об этом в статье про безопасность на этапе проектирования. Аудит информационной безопасности, в котором проверяется и почта, стоит от 1 200 $, выстраивание защиты данных и доступов — от 4 000 $, мониторинг событий безопасности — от 800 $ в месяц. Состав работ — на странице кибербезопасности.

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

Фото на обложке: Feyza Yıldırım, Pexels