Почему письма с VPS уходят в спам, даже если SPF, DKIM и DMARC настроены

SPF настроен, DKIM подписывает письма, DMARC не ругается — а получатели всё равно видят ваши письма в папке «Спам» или не видят вовсе. Если записи в DNS в порядке (о том, как устроены SPF, DKIM и DMARC как DNS-записи, — в статье «Что такое ресурсные записи DNS»), проблема почти всегда лежит на уровне ниже: либо сервер физически не может достучаться до получателя по нужному порту, либо получающая сторона не может подтвердить, что ваш IP — это действительно тот сервер, за который он себя выдаёт, либо ваш IP уже находится в одном из спам-списков. Разбираем три вещи, которые редко упоминают в статьях про SPF/DKIM/DMARC, но которые не менее важны для доставляемости: блокировку порта 25, PTR-запись и блэклисты, а также то, как формируется репутация нового IP.

Порт 25 закрыт исходящий — и это может быть не баг, а политика провайдера

Порт 25 — стандартный порт SMTP, по которому почтовые серверы обмениваются письмами друг с другом напрямую (это отдельная история от портов 587 и 465, которые обычно используются для отправки писем через авторизованный релей — например, когда почтовый клиент или скрипт на сервере отправляет письмо через SMTP-сервис вроде SendGrid или Mailgun). Если ваш Postfix или другой MTA на VPS пытается доставить письмо получателю напрямую по 25 порту, а исходящий 25 порт на уровне сети заблокирован хостинг-провайдером, письмо просто не уйдёт — соединение оборвётся ещё до того, как получающий сервер успеет что-то проверить, включая SPF и DKIM.

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

• AWS: по умолчанию исходящий трафик через порт 25 разрешён только на приватные IPv4-адреса, на публичные IPv4 и IPv6 — заблокирован; снять ограничение можно через отдельную форму запроса в консоли («Request to remove email sending limitations») с обоснованием легитимного использования, рассмотрение занимает до 48 часов — и если у вас инстансы в нескольких регионах, заявку нужно подавать отдельно на каждый регион.
• DigitalOcean: SMTP-порты 25, 465 и 587 блокируются на Droplet по умолчанию для предотвращения спама и других злоупотреблений на платформе; официально провайдер рекомендует не поднимать собственный почтовый сервер вообще, а отправлять письма через стороннего email-провайдера (SendGrid, Mailgun и т.п.).
• Google Cloud: подключения к порту 25 на внешние по отношению к VPC-сети адреса блокируются из-за риска злоупотреблений; при этом порты 587 и 465 не ограничены.
• Hetzner: порты 25 и 465 на облачных серверах блокируются по умолчанию против спам-рассылок, снятие блокировки возможно не раньше месяца использования аккаунта и после оплаты первого счёта, решение принимается индивидуально по заявке.

Обобщать одну процедуру на всех нельзя — у каждого провайдера свои условия и сроки снятия блокировки, а некоторые (как DigitalOcean) вообще не предлагают процедуры снятия и советуют пользоваться внешним релеем. Уточните политику своего провайдера отдельно: у AWS, например, это не обычный тикет, а отдельная форма запроса на снятие ограничений в консоли, причём подавать её нужно отдельно для каждого региона, где у вас есть инстансы. Если провайдер вообще не снимает блокировку — остаётся только отправка через внешний SMTP-релей по 587/465 порту.

Проверить у себя, открыт ли исходящий 25 порт, можно одной командой с сервера:

nc -zv -w5 smtp.gmail.com 25

Если в ответе есть succeeded — порт открыт и соединение устанавливается. Если утилиты nc нет под рукой, тот же результат можно получить средствами самого bash:

timeout 5 bash -c "echo > /dev/tcp/smtp.gmail.com/25" && echo "порт открыт" || echo "порт закрыт или фильтруется"

Если порт закрыт, дальше проверять PTR и блэклисты пока смысла нет — письма в любом случае не будут уходить напрямую, пока порт не откроют или пока вы не переключитесь на отправку через внешний SMTP-релей по 587/465 порту.

PTR-запись: получатель должен уметь подтвердить, что вы — это вы

PTR — это запись в обратной DNS-зоне (in-addr.arpa), которая сопоставляет IP-адрес с хостнеймом — направление, обратное обычной A-записи, где хостнейм превращается в IP. В отличие от A, MX или TXT-записей своего домена, которые вы правите через DNS-регистратора, PTR-запись для VPS устанавливаете не вы сами — её задаёт хостинг-провайдер через панель управления или по заявке в поддержку, потому что зона обратного DNS принадлежит владельцу IP-блока, а не арендатору отдельного адреса.

Проверить свою текущую PTR-запись можно так:

dig -x ВАШ_IP +short

или короче:

host ВАШ_IP

Важный момент, который часто путает: хостнейм, который вернёт PTR, обычно не совпадает с тем, что показывает команда hostname на самом сервере (то есть с содержимым /etc/hostname) — и это нормально, само по себе не проблема. Для доставляемости почты имеет значение не совпадение PTR с внутренним именем сервера, а совпадение PTR с именем, которое ваш почтовый сервер называет получателю при подключении командой HELO/EHLO. Это имя настраивается отдельно в конфигурации MTA — у Postfix это параметры smtp_helo_name и myhostname в main.cf. Если PTR указывает на mail.example.com, а Postfix при подключении представляется как vps-12345.localdomain, для многих принимающих серверов это уже повод отнестись к письму с подозрением.

Требование к PTR — не формальность и не перестраховка отдельных придирчивых серверов. Gmail описывает это прямо в своих правилах для отправителей: публичный IP-адрес отправляющего SMTP-сервера должен иметь соответствующую PTR-запись, которая резолвится в хостнейм, и IP-адрес отправителя должен совпадать с IP-адресом, на который резолвится этот хостнейм в прямой записи. Это и есть механизм forward-confirmed reverse DNS (FCrDNS): IP превращается в имя через PTR, а затем это же имя должно резолвиться обратно в тот же самый IP через обычную A-запись — оба направления обязаны сойтись.

Это не теоретическое требование — Postfix реально умеет проверять его на входящих письмах (в готовых образах эти ограничения обычно выключены и требуют ручной настройки администратором, но проверяющих серверов в интернете, где это включено, хватает). В документации Postfix это описано явно:

• reject_unknown_reverse_client_hostname — отклонить запрос, если у IP-адреса клиента нет записи, сопоставляющей адрес с именем.
• reject_unknown_helo_hostname — отклонить запрос, если у имени, переданного в HELO/EHLO, нет DNS-записи A или MX.
• reject_non_fqdn_helo_hostname — отклонить запрос, если имя в HELO/EHLO указано не в виде полного доменного имени (FQDN) или адресного литерала.

То есть отсутствие или неправильная PTR — не миф и не редкость, а реально задокументированный и широко применяемый механизм отказа на стороне принимающих серверов. Если у вашего VPS до сих пор стоит PTR по умолчанию вроде 123-45-67-89.example-provider.net, а письма уходят от имени домена компании, это стоит поправить в первую очередь — через панель управления провайдера или через тикет в поддержку.

Проверка блэклистов (DNSBL): как это работает и где новичок обычно ошибается

DNSBL (DNS-based blackhole list) — это способ узнать, числится ли IP-адрес в спам-списке, через обычный DNS-запрос. Октеты IP-адреса разворачиваются в обратном порядке и дописываются к имени зоны конкретного списка. Например, для IP 1.2.3.4 и зоны Spamhaus ZEN запрос выглядит как 4.3.2.1.zen.spamhaus.org. Ответ читается по коду:

• нет ответа / NXDOMAIN — IP не в списке;
• 127.0.0.2 — SBL, прямой источник спама;
• 127.0.0.4 — CBL/XBL, обнаружена активность вредоносного ПО или ботнета;
• 127.0.0.10 / 127.0.0.11 — PBL, диапазон адресов, с которых не должна идти прямая почта (часто динамические адреса или отдельные VPS-подсети).

Частая ловушка при ручной проверке. Если делать dig-запрос к зоне Spamhaus через публичный DNS-резолвер сервера — например, Cloudflare (1.1.1.1) или Google (8.8.8.8), которые многие VPS используют по умолчанию, — Spamhaus вернёт код 127.255.255.254. Это не означает, что IP в блэклисте: по документации Spamhaus, такой ответ означает «запрос пришёл через публичный/открытый резолвер», и его нельзя воспринимать как подтверждение листинга. Новички регулярно путают этот код с реальным блэклистингом и начинают чинить несуществующую проблему.

Чтобы проверить правильно через dig, нужно обращаться напрямую к авторитетным серверам зоны, а не через резолвер по умолчанию:

dig +short NS zen.spamhaus.org
dig @ОДИН_ИЗ_ПОЛУЧЕННЫХ_NS ОБРАТНЫЕ.ОКТЕТЫ.IP.zen.spamhaus.org

Для тех, кому возиться с dig не хочется, проще и надёжнее воспользоваться веб-чекером — например, mxtoolbox.com/blacklists.aspx. Такие сервисы обращаются к зонам напрямую и не имеют проблемы с публичным резолвером. Если нужна регулярная автоматическая проверка (а не разовая), для Spamhaus правильнее получить бесплатный DQS-ключ вместо постоянных прямых запросов к их публичным зеркалам — разовая ручная диагностика через dig, как описана выше, для такого использования не предназначена.

Вторая ловушка, отдельно от Spamhaus: список SORBS как сервис закрыт компанией Proofpoint 5 июня 2024 года, его зоны больше не поддерживаются — если где-то в старых статьях или чек-листах вам встретится рекомендация проверять IP через SORBS, это устаревший совет. Домен sorbs.net, на котором была официальная зона, сейчас не резолвится вовсе. А вот похожий по написанию домен sorbs.org кем-то зарегистрирован отдельно и не имеет отношения к оригинальному сервису — его зона dnsbl.sorbs.org отвечает одним и тем же IP-адресом буквально на любой запрос, включая заведомо случайный несуществующий поддомен, то есть это не DNSBL, а wildcard-ответ постороннего домена. Практический вывод: SORBS в любом написании из своих чек-листов и настроек стоит просто убрать. А для проверки любой другой блэклист-зоны через dig есть универсальная защита от такой ловушки: настоящий ответ DNSBL всегда лежит в диапазоне 127.0.0.0/8 — если зона вернула что-то за его пределами (как в примере с sorbs.org выше) или отвечает «найдено» даже на случайный несуществующий поддомен, результатам этой зоны доверять нельзя.

Репутация IP и «прогрев» нового сервера

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

Gmail прямо рекомендует отправителям при увеличении объёма начинать с малого объёма писем вовлечённым (engaged) пользователям и постепенно наращивать объём со временем, избегая резких скачков. Это и называется «прогревом» IP — особенно актуально для нового VPS с новым адресом, у которого попросту нет репутационной истории, и почтовые сервисы поначалу доверяют ему меньше по умолчанию.

Отдельный момент касается общих (shared) IP-адресов — частая ситуация, когда VPS-провайдер переиспользует адреса между клиентами. Gmail отдельно предупреждает: активность любых отправителей, использующих общий IP-адрес, влияет на репутацию всех отправителей с этого адреса. Если IP до вас использовался кем-то, чья рассылка была помечена как спам, его репутация может быть уже испорчена не по вашей вине. Из этого практический вывод: блэклисты и репутацию нового IP стоит проверять сразу после получения адреса от провайдера, ещё до начала реальной отправки — чтобы отличить чужую проблему от своей.

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

Чек-лист: что проверить по порядку, если письма не доходят

1. Убедитесь, что SPF, DKIM и DMARC настроены и проходят проверку — это база, без которой остальное не имеет смысла.
2. Проверьте, открыт ли исходящий порт 25: nc -zv -w5 smtp.gmail.com 25. Если закрыт — обратитесь в поддержку провайдера с обоснованием или переключитесь на отправку через внешний SMTP-релей по 587/465 порту.
3. Проверьте PTR-запись своего IP: dig -x ВАШ_IP +short. Убедитесь, что она указывает на осмысленный хостнейм, а не на дефолтное имя от провайдера.
4. Сверьте PTR с тем, что ваш почтовый сервер называет в HELO/EHLO (в Postfix — smtp_helo_name/myhostname). Хостнейм в HELO/EHLO должен совпадать с тем, что возвращает PTR, а PTR-хостнейм в свою очередь должен резолвиться обратно в тот же самый IP через A-запись — оба направления должны сойтись.
5. Проверьте IP по блэклистам через веб-чекер (например, mxtoolbox.com/blacklists.aspx) или через dig напрямую к авторитетным NS-серверам зоны — не через публичный резолвер вроде 1.1.1.1 или 8.8.8.8, иначе получите ложный код 127.255.255.254 у Spamhaus. SORBS (в любом написании домена) в проверку не включайте — сервис закрыт с июня 2024 года.
6. Если проверяете вручную через dig — сделайте контрольный запрос к случайному несуществующему поддомену той же зоны. Настоящий DNSBL на такой запрос ответит пусто; если зона вернула что-то вне диапазона 127.0.0.0/8 или «находит» даже случайный адрес, результатам не доверяйте.
7. Если сервер новый — не отправляйте сразу большой объём писем. Начните с малого объёма вовлечённым получателям и наращивайте постепенно.
8. Проверьте письма на скрытый через HTML/CSS контент — Gmail отдельно предупреждает, что это может стать причиной попадания в спам.