Добавить в корзинуПозвонить
Найти в Дзене

Почта уходит в спам: пошаговая диагностика DNS

Письмо отправлено — а клиент его не видит. Счёт завис в папке «Нежелательные», срочный договор не дочитан. В 90% случаев дело не в тексте письма, а в четырёх DNS-записях, которые почтовые серверы проверяют каждые несколько секунд. Разберём, что именно проверяется и как это исправить. Когда ваше письмо достигает сервера получателя, тот прогоняет его через цепочку проверок: SPF → DKIM → DMARC → PTR → чёрные списки. Это не фильтр по ключевым словам — это проверка подлинности отправителя на уровне сетевой инфраструктуры. Сбой в любом звене — и письмо либо отклонено сразу, либо маркируется как подозрительное. Причём ошибка в одной записи может обнулить правильно настроенные остальные. SPF — это TXT-запись в DNS домена, которая перечисляет IP-адреса серверов, имеющих право слать почту от вашего имени. Получатель сверяет адрес отправляющего сервера с этим списком. Три ошибки, которые встречаются чаще всего: Правильная запись заканчивается на ~all (мягкий отказ) или -all (жёсткий отказ). На
Оглавление

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

Как почтовые серверы фильтруют входящую почту

Когда ваше письмо достигает сервера получателя, тот прогоняет его через цепочку проверок: SPF → DKIM → DMARC → PTR → чёрные списки. Это не фильтр по ключевым словам — это проверка подлинности отправителя на уровне сетевой инфраструктуры.

Сбой в любом звене — и письмо либо отклонено сразу, либо маркируется как подозрительное. Причём ошибка в одной записи может обнулить правильно настроенные остальные.

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

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

Три ошибки, которые встречаются чаще всего:

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

Правильная запись заканчивается на ~all (мягкий отказ) или -all (жёсткий отказ). На этапе внедрения рекомендуем ~all, после проверки доставляемости — переход на -all.

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

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

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

  • Нет DKIM-записи — с 2024 года Gmail и Яндекс требуют DKIM для массовых отправителей. Без подписи письма автоматически понижаются в рейтинге.
  • Ключ короче 2048 бит — ключи в 512 бит считаются небезопасными и отклоняются большинством провайдеров. Минимум — 1024 бит, норма — 2048 бит.
  • Несовпадение селектора — имя селектора в заголовке письма (например, mail) должно точно совпадать с DNS-записью mail._domainkey.домен.рф.

В IT For Prof при настройке серверной почты всегда генерируем ключи RSA 2048 бит и настраиваем автоматическую ротацию.

DMARC: кто решает, что делать с подозрительными письмами

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

Три уровня политики:

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

Типичная ошибка — оставить p=none навсегда. Это не защищает домен от подделки и не улучшает репутацию отправителя. Обязательно настройте параметр rua= — он указывает адрес для получения агрегированных отчётов.

Последовательность внедрения: p=none (2–4 недели, анализ отчётов) → p=quarantine (2–4 недели, проверка ложных срабатываний) → p=reject (постоянно).

PTR-запись и чёрные списки

PTR-запись — это обратный DNS: по IP-адресу сервера она возвращает его доменное имя. Если A-запись говорит «какой IP у mail.example.com», то PTR отвечает «какой домен у этого IP».

Стандарт RFC 5321 требует, чтобы PTR-запись и A-запись совпадали — это называется Forward-Confirmed reverse DNS. Если PTR отсутствует или не совпадает, многие серверы (включая Gmail) отклоняют соединение ещё до приёма письма.

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

Чёрные списки (DNSBL) — распределённые базы данных IP-адресов, замеченных в рассылке спама. Самый авторитетный — Spamhaus ZEN, который используют большинство крупных провайдеров. Попадание туда блокирует доставку писем полностью.

Попасть в чёрный список можно из-за некорректной настройки SPF/DKIM, взломанного аккаунта или «грязного» IP, доставшегося от предыдущего владельца арендованного сервера.

Мониторинг: как не пропустить изменения

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

В IT For Prof мы используем шаблон для системы мониторинга Zabbix, который каждые 6 часов проверяет 15+ параметров почтового домена:

  • SPF: наличие записи, корректность политики, соблюдение лимита в 10 запросов
  • DKIM: наличие, длина ключа (предупреждение при 1024 бит, норма при 2048+)
  • DMARC: наличие, уровень политики, обнаружение понижения
  • PTR: совпадение прямой и обратной записи для каждого почтового сервера
  • Чёрные списки: проверка IP в Spamhaus ZEN, SpamCop и других базах

При обслуживании серверов клиентов мы подключаем этот мониторинг к общей системе уведомлений. Время реагирования на проблему с доставкой — 10–15 минут.

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