Защита почты: какие ошибки конфигурации используют злоумышленники
Введение
Корпоративная почта остается одним из основных каналов проникновения злоумышленников в инфраструктуру компаний. Причина — для начала атаки бывает достаточно одного письма. Например, злоумышленник может получить доступ, если сотрудник откроет вредоносное вложение или перейдет по ссылке из фишингового письма.
Популярность этого вектора атак среди атакующих только растет. По данным Threat Zone 2026, в 2025 году 64% целевых атак на организации в России и других странах СНГ начинались с фишингового письма. Годом ранее показатель составлял 57%. При этом каждый четвертый кластер атакующих использовал вредоносные вложения, чтобы получить доступ к инфраструктуре.
Защита корпоративной почты не ограничивается фильтрацией фишинга, спама и вредоносных файлов. Важную роль играет конфигурация самой почтовой инфраструктуры. Ошибки в настройке записей SPF, DKIM и DMARC могут упростить подмену отправителя, неправильно настроенный relay — превратить сервер в инструмент для чужих рассылок, а отсутствие ограничений на SMTP‑соединения и попытки аутентификации — облегчить перебор учетных данных или создать дополнительную нагрузку на инфраструктуру.
В статье — основные настройки, которые стоит проверить на почтовом сервере: от аутентификации отправителя и защиты SMTP до DNS, TLS, ограничений на соединения и корректной обработки получателей.
Краткое описание настроек, а также готовые команды вы найдете в чек‑листе для базовой самопроверки защищенности почты.
Частые угрозы: спуфинг и его подтехники
Spoofing (подмена отправителя) — это тип кибератаки, при которой злоумышленник искажает данные об источнике письма, чтобы обмануть пользователя. В таблице — часто используемые техники атакующих.
| Техники атаки | Действие злоумышленников | Пример |
|---|---|---|
|
Header spoofing (подмена заголовков) |
Подменяют видимые поля заголовка, прежде всего «От кого». Доступ к чужому ящику не требуется |
|
|
Domain spoofing (подмена домена) |
Указывают в поле «От кого» реальный домен другой компании |
Письмо «от службы поддержки» знакомого банка |
|
Internal spoofing (внутренняя подмена) |
Имитируют отправку внутри компании: от имени коллеги, руководителя или отдела |
|
|
Envelope spoofing (подмена конверта) |
Подменяют технический адрес отправителя в SMTP‑команде |
|
|
Display name spoofing (подмена отображаемого имени) |
Меняют только отображаемое имя (псевдоним), которое сразу видит пользователь |
|
|
Look‑alike, cousin domain (домен‑двойник, домен‑кузен) |
Регистрируют похожий по написанию или смыслу домен |
|
Ограничения защиты, которые важно понимать:
- Технический отправитель и поле «От кого» — разные идентификаторы. Они могут различаться. Поэтому подмена конверта и подмена заголовков — независимые атаки и часто применяются вместе.
- Записи SPF, DKIM и DMARC не проверяют отображаемое имя. Даже строгая политика
rejectне помешает злоумышленнику поставить в письме, которое он отправляет с собственного домена, имя «Генеральный директор». - Домен‑двойник — это чужой домен. Настройки вашего
company.ruфизически не могут запретить отправку сcompаnу.ru. Здесь помогают только мониторинг похожих доменов и эвристический анализ входящей почты. - Проверка входящей почты — не гарантия. Письмо с домена‑двойника или с подмененным именем пройдет все проверки, потому что ваш домен при этом не компрометируется.
Защита имеет два независимых направления, которые нельзя смешивать:
- Настройка записей SPF, DKIM и DMARC своего домена защищает получателей вашей корреспонденции от использования вашего домена посторонними отправителями.
- Проверка записей SPF, DKIM и DMARC на входящей почте позволяет вашему серверу выявлять письма с поддельными идентификаторами.
К чему могут приводить ошибки настройки
| Ошибка | Возможные последствия |
|---|---|
|
Нет SPF или политика слишком мягкая |
Вашу доменную маску используют для фишинговых атак на ваших клиентов и сотрудников |
|
Нет DKIM |
Снижается доверие принимающих серверов, письма чаще попадают в папку «Спам» |
|
DMARC застрял в режиме |
Проверка работает, но подделка не блокируется |
|
Открытый ретранслятор |
Ваш IP уходит в черные списки, вы лишаетесь доставки всей корпоративной почты |
|
Нет ограничений на аутентификацию |
Перебор паролей ведет к компрометации почтового ящика, который затем используется для внутренней рассылки спама и атаки на партнеров |
|
Нет ограничения размера и соединений |
Деградация и отказ почтовой службы для всех сотрудников |
|
Нет PTR и корректного имени сервера |
Часть площадок‑получателей отклоняет или понижает ваши письма |
Аутентификация отправителя в DNS: SPF, DKIM, DMARC
Ниже — правила настройки SPF, DKIM и DMARC для вашего домена, способы проверки этих механизмов на входящей почте, а также ошибки, из‑за которых защита перестает работать.
SPF — список разрешенных отправляющих серверов
Стандарт: RFC 7208.
Определяет, каким IP‑адресам разрешено отправлять почту от имени домена в рамках технической SMTP‑идентификации (домен из MAIL FROM). Публикуется как одна TXT‑запись на домен.
Ниже — пример такой записи:
team.ru. TXT "v=spf1 ip4:123.123.123.123 ip4:123.123.123.124 -all"
| Элемент | Значение |
|---|---|
|
|
Версия формата |
|
|
Разрешенный IP‑адрес отправляющего сервера |
|
|
Подключение списка другого домена (обычно внешние сервисы рассылок) |
|
|
Все прочие источники запрещены («жесткий» отказ) |
|
|
Все прочие нежелательны, но не запрещены прямо («мягкий» отказ) — не целевое состояние |
|
|
Разрешены любые источники — такое значение недопустимо |
Важно помнить:
- Есть лимит в 10 обращений к DNS на механизмы
include/a/mx/ptr/exists/redirect. При превышении результат проверки выдаетсяpermerror(постоянная ошибка), и часть писем ломается. Считайте количество обращений до добавления каждогоinclude. - SPF проверяет технический отправителя, а не поле «От кого». Успешный результат означает право IP‑адреса отправлять от имени домена из конверта. Это не подтверждает право использовать домен из «От кого». Отсюда — обязательная связка с DKIM и DMARC.
- Каждому поддомену нужна отдельная запись SPF.
- Для одного домена разрешена только одна запись SPF. Несколько TXT‑записей
v=spf1на одном домене — ошибка конфигурации. Тогда все источники объединяются в одну строку.
- Публикация нескольких независимых записей
v=spf1на одном домене — критическая ошибка. - Использование механизма
+allилиallбез префикса полностью открывает политику и обнуляет защиту. - Выбор «мягкого» отказа
~allчасто обоснован незнанием компании, какие сервисы отправляют почту от ее имени. Однако этот механизм подвергает риску всех корреспондентов организации. - Выставление «жесткого» отказа
-allдо инвентаризации источников приведет к отклонению живого рабочего трафика. Под удар попадут сервисы рассылок, уведомления, CRM, мобильные устройства, банковские и кадровые системы. Чтобы этого избежать, сначала выполните полный учет исходящей архитектуры и проверьте все источники. Только затем включайте строгую политику.
DKIM — криптографическая подпись письма
Стандарты: RFC 6376 (формат), RFC 8301 (требования к ключам), RFC 8463 (современные алгоритмы).
Принимающая сторона проверяет, что письмо подписано ключом домена и подписанные части не менялись при передаче. Публичный ключ публикуется в DNS по селектору (идентификатору ключа):
selector1._domainkey.team.ru. TXT "v=DKIM1; k=rsa; p=<ПУБЛИЧНЫЙ_КЛЮЧ>"
Заголовок в письме: DKIM-Signature: v=1; d=team.ru; s=selector1; ..., где d= — домен подписи, s= — селектор, по которому получатель находит ключ.
Рекомендуемые параметры ключей и подписи:
| Требование | Значение |
|---|---|
|
Длина RSA‑ключа |
Не менее 2048 бит |
|
Алгоритм хеширования |
Только SHA‑256 (SHA‑1 запрещен) |
|
Подписываемые заголовки |
Минимум — поле «От кого». Рекомендуется также подписывать «Кому», «Тема» и «Дата» |
Гигиена ключей:
- Закрытый ключ должен храниться строго на подписывающей системе, а открытый — публиковаться в DNS.
- Ключи следует регулярно менять, а использование отдельных селекторов для каждого сервиса позволяет делать это без приостановки отправки писем.
- Подпись должна быть настроена на всех легитимных отправляющих системах (шлюз, корпоративная почта, сервисы рассылок — у внешнего сервиса в вашем DNS публикуется его открытый ключ).
- Использование одного закрытого ключа на нескольких независимых системах недопустимо: взлом любой из них ставит под угрозу всю безопасность.
- Восприятие валидной подписи как доказательство того, что письмо написал конкретный человек. Подпись гарантирует лишь целостность сообщения со стороны того, кто подписал:
d=evil.exampleдаст «проверка пройдена», но к вашему домену отношения не имеет.
DMARC — политика проверки согласованности и отчетности
Стандарт: RFC 7489.
DMARC связывает результаты SPF и DKIM с доменом из поля «От кого» — эта процедура называется согласованностью (alignment). Проверка DMARC считается пройденной, если хотя бы один механизм прошел проверку и находится в согласованности с доменом из «От кого».
Вот пример TXT‑записи DMARC в DNS:
_dmarc.team.ru. TXT "v=DMARC1; p=none; rua=mailto:dmarc@team.ru; pct=100"
| Параметр | Назначение |
|---|---|
|
|
Политика для основного домена: нет действий, в спам, отклонять |
|
|
Политика для поддоменов (иначе наследует |
|
|
Доля почты, к которой применяется политика (для плавного включения) |
|
|
Адрес для получения сводных отчетов |
|
|
Адрес для расширенных отчетов команды форензики (редко требуется) |
|
|
Режим согласованности: ослабленный (по умолчанию) или строгий |
|
|
Интервал между сводными отчетами в секундах |
Порядок внедрения DMARC (сразу включать отклонение не рекомендуется):
- Опубликовать запись DMARC с политикой
p=none(«только наблюдение»). - Собирать и разбирать сводные отчеты.
- Провести инвентаризацию всех легитимных отправителей.
- Донастроить SPF или DKIM для отправителей, которые не проходят проверку.
- Проверить согласованность: домен, прошедший SPF или DKIM, должен совпадать с доменом в поле «От кого».
- Включить политику
p=quarantine(«в спам») и постепенно расширять ее: сначала на 25% писем, не прошедших проверку, затем на 50% и 100%. - Проверить по отчетам, что легитимные письма не попадают в спам.
- Включить политику
p=reject(«отклонять»).
Целевое состояние защищаемого домена — p=reject. Политика p=none защитой не является, потому что тогда проверка выполняется, но блокировки нет.
Поддоменам, которые не должны отправлять почту, следует поставить sp=reject (или отдельную _dmarc с p=reject), а также v=spf1 -all и отсутствие DKIM. Это закрывает внутреннюю подмену с неиспользуемых поддоменов.
Проверка входящей почты
Входящий сервер тоже должен проверять SPF, DKIM и DMARC у полученных писем и учитывать эти результаты при решении о доставке.
Результат проверки зависит от корректности настройки отправляющей стороны, поэтому SPF: FAIL — не всегда говорит о попытке провести атаку. Легитимное письмо может не пройти SPF из‑за пересылки копии письма, неверно настроенного внешнего сервиса, отсутствия нужного IP в записи, промежуточного ретранслятора, изменения конверта при передаче.
Решение следует принимать по совокупности признаков:
- SPF,
- DKIM,
- DMARC,
- PTR (обратная DNS‑запись),
- TLS,
- репутация IP,
- поведение в SMTP.
Практические правила:
- Записывать результаты проверок в заголовок
Authentication-Results(RFC 8601) — по нему далее работают фильтрация и расследования. - Без специализированной антиспам‑системы использовать записи SPF, DKIM или DMARC как один из основных признаков оценки домена отправителя, а не как единственное основание для блокировки письма.
- Отдельно выявлять внутреннюю подмену. Письмо «с вашего домена», пришедшее с внешнего IP‑адреса или с несоответствием SPF и DKIM домену отправителя, всегда подозрительно, даже если формально проверки пройдены чужими сервисами.
- Учитывать ловушку совместимости DMARC и SMTP согласно RFC 7960. При политике «отклонять» нельзя отвергать письмо на этапе команды получателя с последующей отправкой уведомления о недоставке. Корректным решением будет принять конверт, но не доставлять само письмо.
Редкие, но полезные механизмы
Ниже — стандарты и методы защиты, которые применяются для специфических задач.
Стандарт Null MX — запрет приема почты для неиспользуемых доменов (RFC 7505)
Домен или поддомен, который не принимает почту, должен заявить об этом явно. Иначе его MX‑записи используются злоумышленниками, а вы получаете чужие отчеты о недоставке.
; Поддомен не принимает почту: noc.team.ru. MX 0 . ; Null MX — «почту не принимаем» noc.team.ru. TXT "v=spf1 -all" ; и отправлять не должен _dmarc.noc.team.ru. TXT "v=DMARC1; p=reject; adkim=s; aspf=s"
«Зарезервированные» и неиспользуемые домены
Для доменов, которые ничего не отправляют, целевую политику следует сразу ужесточать:
_dmarc.parked.example. TXT "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; pct=100"
Стандарт BIMI — знак бренда в письме
BIMI (знак бренда) показывает ваш логотип в почтовом клиенте получателя (Gmail, Apple Mail, Yahoo Mail; поддержка у российских площадок ограничена и меняется — нужно проверять актуальность).
Требование: включить для DMARC политику «отклонять» и добавить опубликованный логотип в формате SVG Tiny PS. Для отображения логотипа у крупных провайдеров нужен сертификат бренда VMC/CMC.
default._bimi.team.ru. TXT "v=BIMI1; l=https://team.ru/logo.svg; a=https://team.ru/ca.pem"
Протокол ARC — цепочка заверенных посредников (RFC 8617)
Сервисы пересылки почты (форвардеры) и списки рассылки нарушают согласованность SPF (меняются конверт и IP) и иногда DKIM (добавляется текст письма). ARC позволяет доверенному посреднику переподтвердить авторство с помощью специальных заголовков аутентификации: ARC-Seal, ARC-Message-Signature, ARC-Authentication-Results. Эта настройка необходима, если ваша система работает как сервис для пересылки чужой почты.
Отчетность по шифрованию в связке с обязательным TLS
Использование MTA‑STS (политика обязательного шифрования) без отчетности создает слепую зону, скрывающую сбои доставки по защищенному соединению. Публикация записей TLSRPT (_smtp._tls, RFC 8460) должна предшествовать переводу MTA‑STS в обязательный режим.
Корректные коды ответов SMTP (RFC 5248)
Использование кодов 4.х.х для временных ошибок и 5.х.х для постоянных ошибок должно строго соответствовать их назначению. Возврат кода постоянной ошибки вместо временной искажает логику повторных попыток отправки, нарушает корректность доставки и приводит к потере легитимных писем.
Автоответы и уведомления о доставке (RFC 3834, RFC 3464)
Чтобы не создавать петли маршрутизации, следует:
- Запретить отправку автоответов («в отпуске», «адрес неизвестен», «я на больничном») на подозрительный трафик и спам, а также адреса списков рассылки. Это генерирует обратное рассеивание трафика и подтверждает активность ящика для спамеров.
- Учитывать заголовок
Auto-Submittedи значенияPrecedence: bulk/list. - Формировать уведомление о недоставке корректно и только в случае, когда письмо было принято для существующего получателя.
Отписка в один клик (RFC 8058)
Для массовых рассылок обязателен заголовок List-Unsubscribe-Post: List-Unsubscribe=One-Click — это требование Gmail и Yahoo с 2024 года, а также значимый фактор снижения жалоб на спам.
Транспорт и шифрование
Если в компании шифрование не настроено или остается необязательным, письма и пароли ее сотрудников можно перехватить при передаче. Злоумышленнику достаточно «вклиниться» в соединение и заставить серверы обменяться данными открытым текстом.
Ниже — что настроить, чтобы почта и учетные данные передавались только по защищенному каналу: от версий TLS и сертификатов до политики MTA‑STS.
TLS/STARTTLS
Базовый протокол SMTP передает данные открытым текстом, поэтому для защиты трафика необходимо настроить обязательное шифрование соединений.
- Использовать корректный сертификат. Он должен быть действующим, не самоподписанным, с валидными полями CN/SAN и разумным сроком действия.
- Ограничить версии протоколов. Разрешить только TLS 1.2 и TLS 1.3. Протоколы SSLv3, TLS 1.0, TLS 1.1 и слабые наборы шифров необходимо отключить.
- Защитить передачу учетных данных. На узле приема почты от клиентов требуется устанавливать защищенное соединение до авторизации.
- Разделять шифрование и аутентификацию. Расширение STARTTLS защищает только канал передачи. Проверку доменных идентификаторов письма выполняют SPF, DKIM и DMARC — это разные уровни защиты.
MTA‑STS и DANE (RFC 8461 и RFC 7672)
Необязательное («возможностное») шифрование уязвимо к downgrade‑атаке и перехвату сессии. MTA‑STS объявляет, что домен принимает почту только по шифрованию с проверяемым сертификатом, и что делать при сбое.
Пример TXT‑записи в DNS для включения политики MTA‑STS:
_mta-sts.team.ru. TXT "v=STSv1; id=2026092901Z"
Файл политики раздается по HTTPS: https://mta-sts.team.ru/.well-known/mta-sts.txt
version: STSv1 mode: testing ; сначала тест, затем enforce (обязательно) mx: mail.team.ru mx: *.mx.team.ru max_age: 604800
Внедрять политику следует постепенно:
- Сначала включить тестовый режим (
testing). Только после проверки всех систем настраивается обязательный режим (enforce). - Параллельно собирать отчетность. Для контроля доставки необходимо активировать отчеты TLSRPT.
- Учитывать ограничения DANE. Использование механизма DANE для привязки сертификата к DNS (RFC 7672) выступает альтернативой или дополнением к MTA‑STS, однако этот стандарт требует внедрения DNSSEC, который в российской практике распространен ограниченно.
Узел приема почты от клиентов и аутентификация (RFC 6409, STD 72, BCP 134, RFC 8314)
| Порт | Назначение | Кто подключается |
|---|---|---|
|
|
Пересылка между серверами (MX) |
Другие почтовые серверы из интернета |
|
|
Прием почты от клиентов (submission), STARTTLS и аутентификация |
Почтовые программы сотрудников |
|
|
Прием почты от клиентов, устаревший вариант с неявным TLS |
Только легитимные клиенты, не должен быть доступен из внешней сети |
Правила настройки доступа и проверки подлинности:
- Разделять SMTP‑аутентификацию и ретрансляцию. Аутентификация подтверждает личность пользователя, а политика ретрансляции определяет его права на отправку. Эти условия проверяются независимо.
- Ограничивать внешний доступ к портам исходящей почты и администрирования. Порты
465/tcp,587/tcpи веб‑интерфейс должны быть доступны только из внутренней сети или через VPN. Снаружи открывается только порт25/tcpна принимающем MX. - Проводить аутентификацию строго поверх шифрования. Передача учетных данных через
AUTH=PLAINилиLOGINбез предварительного TLS‑соединения недопустима.
Шифрование по ГОСТу
Для выполнения требований по переходу на отечественное ПО или аттестации ФСТЭК России используется TLS 1.3 с шифрованием по ГОСТу (описано в RFC 9367). Такие наборы реализуются через сертифицированные модули, например «КриптоПро TLS» или «ВиПиНет».
ГОСТ‑транспорт необходимо строить как отдельный контур — например, для связи между своими площадками и российскими облаками. Поддержка ГОСТа у внешних серверов крайне ограничена, поэтому отказ от стандартного TLS приведет к потере почты от зарубежных и многих российских адресатов.
Контроль доступа к серверу и нагрузки на него
Даже если домен защищен от подмены, а соединения зашифрованы, сам сервер может пересылать спам злоумышленников, пропускать перебор паролей или отказывать под нагрузкой. Рассказываем, как ограничить доступ к серверу, задать лимиты на соединения и письма и не раскрывать список адресов компании.
Открытый ретранслятор
В состоянии открытого ретранслятора внешний отправитель может переправлять почту через чужой сервер без авторизации и проверки прав.
Возможные последствия:
- массовая рассылка спама и фишинга с ваших адресов,
- попадание IP и домена в черные списки,
- ухудшение репутации домена,
- повышенная нагрузка на инфраструктуру,
- использование вашего сервера для атак на сторонние организации.
Правило разделения:
MAIL FROM:<external@example.com> → RCPT TO:<user@team.ru> ; прием для обслуживаемого домена — это нормально MAIL FROM:<external@example.com> → RCPT TO:<user@other-corp.ru> ; ретрансляция «на сторону» без авторизации — запрещено
Какие требования должен соблюдать сервер:
- Разрешать ретрансляцию только авторизованным пользователям и доверенным сетям.
- Разделять прием почты от клиентов на порту 587 и серверный режим пересылки на порту 25.
- Регулярно проверять конфигурацию тестом на маршрутизацию от внешнего отправителя к внешнему получателю и настроить мониторинг.
Перебор паролей к аутентификации в SMTP
Возможные последствия:
- компрометация учетной записи,
- отправка писем от имени реального сотрудника и рассылка спама через его почтовый ящик,
- компрометация других сервисов при повторном использовании пароля.
Для защиты от подбора учетных данных применяются следующие меры безопасности:
- Настроить аутентификацию только поверх шифрования, чтобы пароли передавались строго внутри защищенного TLS‑соединения.
- Ограничить число неудачных попыток входа с одного IP‑адреса и включить временную блокировку или задержку через
fail2ban. - Закрыть порты приема почты для внешних сетей, если в них нет необходимости.
- Внедрить сложные уникальные пароли и многофакторную аутентификацию.
Ограничение частоты соединений и отправки
Возможные последствия: даже при закрытом ретрансляторе возможен поток соединений и писем.
Следует задавать лимит отдельно для доверенных систем, внутренних сетей и внешних клиентов:
- одновременные соединения,
- соединения с одного IP‑адреса,
- письма за интервал времени,
- получатели в одной SMTP‑сессии,
- неудачные команды,
- неудачные попытки аутентификации.
Слишком жесткие ограничения заблокируют легитимных крупных отправителей и корпоративные сервисы. Настройки необходимо калибровать по журналам, а не «на глаз».
Сбор списка существующих адресов
Возможные последствия: перебор имен пользователей на основе различий в ответах сервера позволяет составить базу реальных адресов компании:
RCPT TO:<user1@team.ru> → 250 OK ; адрес существует RCPT TO:<unknown@team.ru> → 550 User unknown ; адрес не существует
Рекомендации по защите от сбора адресов:
- Настроить одинаковые ответы сервера для существующих и несуществующих адресов там, где это возможно.
- Ограничить скорость и количество проверок получателей, чтобы заблокировать внешним системам массовый перебор.
- Внедрить инструменты защиты от автоматического сканирования, если полностью скрыть разницу в ответах не получается.
- Отключить функцию catch‑all на домене, так как сбор всей ошибочной почты резко увеличивает спам‑нагрузку. Такой режим подходит только для адреса
postmaster(RFC 2142).
Проверка существования получателя и «обратное рассеивание» (RFC 3464, RFC 5248)
Для защиты от лишней нагрузки и генерации паразитного трафика рекомендуется:
- Проверять существование получателя до принятия тела письма и сразу отклонять неизвестные адреса на SMTP‑этапе.
- Избегать опасной практики, когда сервер принимает письмо для несуществующего адреса, а затем отправляет отправителю отчет о недоставке. Такая схема порождает обратное рассеивание, при котором ложные уведомления уходят на чужие адреса, и создает лишнюю нагрузку.
- Контролировать очередь недоставленных сообщений и корректно настраивать обработку статусов доставки.
Ограничение размера письма
Нужно установить оптимальный максимальный размер письма, а при необходимости — отдельные лимиты для входящей почты, исходящей почты, внутренних систем и доверенных сервисов. Значение должно быть согласовано с лимитами внешних почтовых систем, иначе легитимные письма с вложениями будут отклоняться.
«Серый список» (факультативно, RFC 6647)
Временный отказ первому соединению (450) отсекает часть примитивного спама, но добавляет задержки доставки и требует корректной повторной попытки со стороны отправителя. Применять следует точечно и с пониманием, что крупные легитимные отправители чаще всего обходят этот механизм повтором.
Репутация и доставка
Проблемы с доставкой обычно замечают только когда клиенты компании не получают счета, а ее партнеры — договоры. Часто проблема кроется настройках: у сервера нет корректной обратной DNS‑записи, IP‑адрес попал в черный список или почта не соответствует требованиям крупных площадок. Эти параметры стоит проверить заранее, а репутацию отслеживать постоянно.
Обратная DNS‑запись и имя сервера
Для исходящего сервера обязательна согласованная петля:
123.123.123.123 → PTR → mail.team.ru → A → 123.123.123.123
Имя сервера должно корректно использоваться в приветствии EHLO/HELO.
- Обратную запись настраивает владелец адресного пространства или провайдер, а не зона вашего домена.
- Обратная запись — не аутентификация. Корректный PTR не дает права отправлять почту от имени
team.ru(эти задачи решают SPF, DKIM, DMARC). Отсутствие или несогласованность PTR приводят к тому, что часть принимающих площадок снижает доверие, отправляет письма в папку «Спам» или отклоняет соединение.
Черные списки и мониторинг репутации
Нужно поддерживать репутацию IP‑адресов и доменов, а также регулярно проверять их на попадание в списки нежелательных адресов. Отдельная практика — «прогрев» новых адресов: репутация формируется независимо у каждого принимающего в течение 3–6 недель реального легитимного трафика. При недостаточном объеме адрес не «прогревается».
Требования крупных принимающих площадок
Российские площадки. Следует проверять актуальные требования тех площадок, куда вы отправляете почту, — правила периодически меняются.
| Площадка | Где смотреть требования |
|---|---|
|
«VK Почта» |
https://corp.mail.ru/ru/ (раздел для отправителей) |
|
Yandex 360 для бизнеса |
|
|
VK WorkSpace |
|
|
«Р7‑Офис», российские облачные почтовые платформы |
Документация соответствующего поставщика |
Ожидания российских площадок совпадают с мировыми: для успешной доставки необходимы настроенные механизмы SPF, DKIM и строгая политика DMARC в режиме отклонения сообщений. Также сервер должен иметь корректную обратную запись DNS и валидное имя, передавать трафик по шифрованному каналу, поддерживать минимальный уровень жалоб на спам, а для массовых рассылок — обязательный механизм отписки.
Международные площадки (важно, если у вас зарубежные корреспонденты). С 2024 года Gmail и Yahoo ужесточили правила для массовых отправителей:
| Требование | Условия требования |
|---|---|
|
SPF, DKIM и DMARC |
Настройка всех трех механизмов обязательна. Минимальным требованием является режим мониторинга, однако рекомендуется переход к политике отклонения писем |
|
Согласованность конверта |
Домен в техническом заголовке |
|
Отписка в один клик |
Внедрение стандарта RFC 8058 становится обязательным требованием для всего рассылочного трафика |
|
Низкий уровень жалоб |
Выход за установленный порог жалоб пользователей на спам приводит к блокировке отправки |
|
Шифрование в транзите |
Обеспечение поддержки протокола TLS на этапе доставки сообщений |
|
Отсутствие поддельных заголовков |
Подмена поля «От кого» приводит к отказу в доставке |
Заключение
Фильтрация фишинга и спама — только часть защиты почты. Ошибки конфигурации не исправят фильтры. Слабая политика SPF или DMARC позволит рассылать фишинг от имени вашего домена клиентам и партнерам, открытый ретранслятор превратит ваш сервер в инструмент для чужих рассылок, а без обратной DNS‑записи ваши письма уйдут в спам.
Настроить почту «раз и навсегда» не получится: со временем у компании появляются новые сервисы рассылок и меняются провайдеры, почтовые площадки обновляют требования к отправителям, а ключи DKIM должны обновляться по графику. Поэтому настройки стоит проверять регулярно, желательно раз в квартал.
Начните с того, без чего домен и сервер остаются уязвимыми:
- Проведите инвентаризацию исходящей почты.
- Настройте SPF, DKIM и DMARC в режиме наблюдения.
- Закройте ретранслятор и включите шифрование.
Когда отчеты DMARC покажут, что все легитимные отправители учтены, переходите к политике «отклонять», внедрите MTA‑STS и настройте мониторинг репутации. Большинство этих настроек — записи в DNS и параметры почтового сервера, их можно проверить своими силами.
- Готовые команды
dig,opensslиswaks: проверка DNS‑записей, шифрования и сертификата, тест на открытый ретранслятор. - Список сервисов для проверки домена и разбора сводных отчетов DMARC.
- Больше 40 пунктов проверки по 12 областям: от SPF и DKIM до лимитов и репутации.
- Шаблоны DNS‑записей и справочные приложения.
Оставьте контакты — пришлем чек‑лист на почту.