Связаться с нами

Корпоративная почта попадает в спам — пошаговая диагностика

Корпоративная почта попадает в спам — диагностика причин
No Comment
Блог

Почему корпоративная почта попадает в спам: причины и решения

Содержание

Как почтовые серверы решают, что письмо — спам

Корпоративная почта попадает в спам — диагностика причин

Корпоративная почта попадает в спам — одна из самых частых проблем при использовании собственного почтового сервера. Письма клиентам уходят в папку «Нежелательные», счета теряются, а срочные уведомления остаются непрочитанными. В 90% случаев причина не в содержимом письма, а в неправильной настройке DNS-записей домена.

Почтовый сервер получателя проверяет каждое входящее письмо по цепочке: SPF → DKIM → DMARC → PTR → чёрные списки DNSBL. Если хотя бы одно звено настроено неправильно, письмо может быть отклонено или помечено как спам. В этой статье разберём каждую проверку, покажем команды диагностики и дадим готовый чек-лист для настройки почтового сервера.

Мы в IT For Prof ежемесячно диагностируем десятки доменов с проблемами доставки. Ниже — системный подход, основанный на реальных кейсах и RFC-стандартах.

Подробнее — в нашей статье настройка SPF, DKIM и DMARC.

Подробнее — в нашей статье чёрных списках DNSBL.

SPF: разрешение на отправку от имени домена

SPF (Sender Policy Framework, RFC 7208) — DNS-запись типа TXT, которая перечисляет серверы, имеющие право отправлять почту от имени вашего домена. Почтовый сервер получателя сравнивает IP-адрес отправителя со списком в SPF-записи.

Корпоративная почта попадает в спам чаще всего из-за трёх ошибок в SPF:

  • +all или отсутствие механизма all — разрешает отправку от имени домена с любого IP. Спамеры могут подделать ваш адрес, и ваш домен попадёт в чёрные списки.
  • ?all — нейтральная политика. Почтовый сервер получателя не отклоняет письмо, но и не доверяет ему. Большинство провайдеров (Yandex, Mail.ru) понижают рейтинг таких писем.
  • Превышение лимита в 10 DNS-запросов — RFC 7208 §4.6.4 ограничивает количество include, redirect, a, mx и exists механизмов до 10. При превышении SPF-проверка возвращает PermError, и письмо может быть отклонено.

Правильная SPF-запись заканчивается на -all (hard fail) или ~all (soft fail). Мы рекомендуем ~all на этапе внедрения и переход на -all после проверки доставляемости.

				
					# Проверка SPF-записи домена
dig TXT example.com +short | grep "v=spf1"

# Пример корректной SPF-записи
# v=spf1 mx ip4:193.187.96.0/24 include:_spf.google.com ~all

# Подсчёт DNS-запросов (include, a, mx, redirect, exists)
# Лимит: 10 (RFC 7208 §4.6.4)
Диаграмма проверки DNS-записей для корпоративной почты

DKIM: цифровая подпись письма

DKIM (DomainKeys Identified Mail, RFC 6376) добавляет к каждому письму криптографическую подпись. Получатель проверяет подпись по открытому ключу, опубликованному в DNS.

Основные проблемы DKIM, из-за которых корпоративная почта попадает в спам:

  • Отсутствие DKIM-записи — письма без подписи автоматически понижаются в рейтинге. Gmail и Yandex с 2024 года требуют DKIM для массовых отправителей.
  • Ключ короче 2048 бит — RFC 6376 §3.3.3 определяет минимальный размер ключа в 1024 бит, но рекомендует 2048 бит. Ключи длиной 512 бит считаются небезопасными и отклоняются большинством провайдеров.
  • Несовпадение селектора — селектор в заголовке письма (например, s=mail) должен совпадать с DNS-записью mail._domainkey.example.com.

При настройке серверной инфраструктуры мы всегда генерируем ключи RSA 2048 бит и настраиваем автоматическую ротацию через OpenDKIM.

				
					# Проверка DKIM-записи домена
dig TXT mail._domainkey.example.com +short

# Пример ответа (ключ 2048 бит, разбит на два TXT-фрагмента)
# "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQE..." "...FAAOCAQ8AMIIBCgKCAQEA..."

# Генерация нового ключа OpenDKIM (2048 бит)
opendkim-genkey -s mail -d example.com -b 2048

DMARC: политика обработки неподписанных писем

DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) объединяет SPF и DKIM в единую политику. Запись указывает почтовому серверу получателя, что делать с письмами, не прошедшими проверку.

Три уровня политики DMARC (§6.3):

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

Типичная ошибка — оставить p=none навсегда. Это не защищает домен от спуфинга и не улучшает репутацию. Google и Yandex с 2024 года учитывают DMARC-политику при фильтрации.

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

Подробнее — в нашей статье мониторинг DNS-записей почтового домена через Zabbix.

				
					# Проверка DMARC-записи
dig TXT _dmarc.example.com +short

# Пример корректной DMARC-записи
# "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100"

# Последовательность внедрения:
# 1. p=none (2-4 недели, анализ отчётов)
# 2. p=quarantine (2-4 недели, проверка ложных срабатываний)
# 3. p=reject (постоянно)
Мониторинг DNS-записей почтового домена

PTR-запись и обратный DNS

PTR-запись (Pointer Record) связывает IP-адрес сервера с его доменным именем. Это обратная DNS-запись: если A-запись отвечает на вопрос «какой IP у mail.example.com?», то PTR-запись — «какой домен у IP 193.187.96.108?».

RFC 5321 §4.1.3 требует, чтобы имя в команде EHLO при SMTP-соединении можно было разрешить обратно через PTR. Это называется Forward-Confirmed reverse DNS (FCrDNS): PTR-запись IP → hostname, и A-запись hostname → тот же IP.

Если PTR-запись отсутствует или не совпадает, корпоративная почта попадает в спам практически гарантированно. Многие почтовые серверы (в том числе Gmail) отклоняют соединения без валидного PTR ещё до приёма письма.

PTR-запись настраивается у хостинг-провайдера (владельца IP-блока), а не в DNS-зоне домена. Для VPS и выделенных серверов обычно доступна в панели управления.

				
					# Проверка PTR-записи по IP-адресу
dig -x 193.187.96.108 +short
# Ожидаемый результат: mail.example.com.

# Проверка FCrDNS (Forward-Confirmed reverse DNS)
PTR=$(dig -x 193.187.96.108 +short)
dig A $PTR +short
# Должен вернуть: 193.187.96.108

Чёрные списки DNSBL

DNSBL (DNS-based Blackhole List, описан в RFC 5782) — распределённые чёрные списки IP-адресов, замеченных в рассылке спама. Почтовые серверы проверяют IP отправителя в DNSBL при каждом входящем соединении.

Основные DNSBL-списки:

  • Spamhaus ZEN (zen.spamhaus.org) — объединяет SBL, XBL и PBL. Самый авторитетный список, используется большинством крупных провайдеров.
  • SpamCop (bl.spamcop.net) — автоматическое удаление через 24 часа после прекращения жалоб.
  • Barracuda BRBL — требует отдельной регистрации для делистинга.

Попадание в DNSBL — часто следствие других проблем: отсутствия SPF/DKIM, взломанного аккаунта, рассылающего спам, или наследования «грязного» IP от предыдущего владельца VPS.

Подробнее о проверке и выходе из чёрных списков читайте в нашей статье (готовится к публикации).

				
					# Проверка IP в Spamhaus ZEN
# Формат: обратный IP + зона
dig 108.96.187.193.zen.spamhaus.org +short
# Пустой ответ = не в списке
# 127.0.0.x = в списке (код указывает тип блокировки)

# Проверка IP в SpamCop
dig 108.96.187.193.bl.spamcop.net +short

Корпоративная почта попадает в спам — чек-лист диагностики

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

Проверьте наличие TXT-записи с v=spf1. Убедитесь, что запись заканчивается на ~all или -all. Подсчитайте количество include, a, mx, redirect, exists — не более 10. Команда: dig TXT example.com +short

Проверьте DNS-запись selector._domainkey.example.com. Убедитесь, что ключ не менее 2048 бит. Сервис dkimcore.org показывает размер ключа по TXT-записи. Команда: dig TXT mail._domainkey.example.com +short

Проверьте _dmarc.example.com. Если политика p=none, запланируйте переход на p=quarantine или p=reject. Убедитесь, что настроен rua= для отчётов.

Выполните dig -x IP_АДРЕС +short, затем dig A РЕЗУЛЬТАТ +short. Полученный IP должен совпадать с исходным. Если PTR отсутствует — настройте через панель хостинга. Это критичная проверка: без PTR Gmail и Yandex отклоняют письма.

Как предотвратить проблемы: мониторинг DNS

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

Мы разработали open-source шаблон для Zabbix 7.0, который автоматически проверяет 15+ DNS-записей почтового домена каждые 6 часов: zabbix-mail-dns-audit.

Шаблон проверяет:

  • SPF: наличие, корректность all-механизма, лимит DNS-запросов, использование устаревшего ptr-механизма
  • DKIM: наличие записи, размер ключа (WARNING при 1024, OK при 2048+)
  • DMARC: наличие, уровень политики, обнаружение даунгрейда
  • PTR/FCrDNS: валидность обратной записи для каждого MX-хоста
  • DNSBL: проверка IP в Spamhaus ZEN, SpamCop и других списках

При администрировании серверов наших клиентов мы подключаем мониторинг DNS к общей системе — время реагирования на проблемы составляет 10-15 минут.

				
					# Установка шаблона мониторинга
git clone https://github.com/IT-for-Prof/zabbix-mail-dns-audit.git
cp mail.dns.audit /usr/lib/zabbix/externalscripts/
chmod +x /usr/lib/zabbix/externalscripts/mail.dns.audit

# Импортируйте YAML-шаблон в Zabbix → Configuration → Templates
# Создайте хост с макросом {$MAIL_DOMAIN}=example.com

Заключение

Корпоративная почта попадает в спам из-за неправильной настройки DNS-записей: SPF, DKIM, DMARC, PTR и попадания в чёрные списки DNSBL. Каждая из этих проверок — обязательное звено в цепочке доставки.

Ключевые шаги:

  • Настройте SPF с ~all или -all, не более 10 DNS-запросов
  • Генерируйте DKIM-ключи не менее 2048 бит
  • Внедрите DMARC поэтапно: none → quarantine → reject
  • Убедитесь, что PTR/FCrDNS настроен корректно
  • Настройте автоматический мониторинг DNS через Zabbix

Нужна помощь с настройкой корпоративной почты? Мы проводим бесплатный аудит DNS-записей и помогаем настроить SPF, DKIM, DMARC для гарантированной доставки. Более 200 компаний уже доверили нам свою почту.

Подробнее — в нашей статье чек-лист из 15 проверок доставляемости.

Заказать аудит почты

Часто задаваемые вопросы (FAQ)

Ответы на частые вопросы о том, почему корпоративная почта попадает в спам и как это исправить.

Каждый почтовый сервер использует собственные фильтры. Проверьте SPF, DKIM и DMARC через dig, убедитесь в отсутствии IP в DNSBL. Если записи в порядке — свяжитесь с администратором сервера получателя и запросите лог отклонения.

Начните с проверки SPF и PTR — это две самые частые причины. SPF-запись можно исправить за 5 минут в DNS-панели. PTR настраивается через хостинг-провайдера и вступает в силу обычно в течение часа.

Да. DMARC объединяет проверки SPF и DKIM в единую политику и добавляет отчётность. Без DMARC почтовый сервер сам решает, что делать с письмами без подписи. С DMARC — решаете вы.

Используйте команду dig обратный_IP.zen.spamhaus.org +short для проверки в Spamhaus ZEN. Для автоматической проверки по нескольким спискам настройте мониторинг через zabbix-mail-dns-audit.

Базовая настройка DNS-записей для одного домена входит в стоимость услуги корпоративной почты под ключ. Мы также проводим бесплатный аудит существующих DNS-записей — свяжитесь с нами для диагностики.