PTR и FCrDNS для почтового сервера: почему без обратного DNS письма уходят в спам
Разбираем, почему письма с «чистого» сервера с зелёными SPF, DKIM и DMARC всё равно падают в спам — и как за пять минут настроить и проверить PTR-запись и forward-confirmed reverse DNS.
EvilMail Team8 июля 2026 г.11 мин чтения
Почему письмо режется на этапе, о котором вы не подумали
Знакомый сценарий: подняли Postfix, аккуратно прописали SPF, сгенерировали DKIM-ключ, включили DMARC, прогнали домен через все чекеры — везде зелёные галочки. А Gmail с упорством кладёт письма в «Спам», Outlook отбивает соединение с 550 5.7.1, и вы который день грешите на репутацию IP.
В девяти случаях из десяти дело не в контенте, не в репутации и даже не в аутентификации. Дело в том, что forward-confirmed reverse DNS не сходится: PTR-записи либо нет вообще, либо она ведёт на generic-хостнейм провайдера вроде 212-22-69-210.static.example-hoster.net, либо HELO вашего сервера не совпадает с PTR. Принимающий MTA сначала выясняет, «кто ты по IP-адресу», и только потом читает заголовки. Если на первом же вопросе ответ невнятный — до чтения DKIM-подписи дело может и не дойти.
Разберём цепочку целиком: как Postfix объявляет себя миру, что именно проверяет приёмная сторона, где обрывается связка и как всё продиагностировать за пять минут. В примерах — данные боевой инфраструктуры: IP 203.0.113.10 и хост mail.evilmail.pro
.
Что такое PTR и FCrDNS — и почему их нельзя путать
PTR-запись живёт в обратной зоне in-addr.arpa (для IPv6 — ip6.arpa). Одна запись на один IP-адрес: она отвечает на вопрос «какому имени принадлежит этот адрес». Ключевой момент, на котором спотыкаются почти все: PTR не лежит в вашей обычной DNS-зоне. Обратную зону делегирует владелец блока адресов — хостер или, если у вас собственная сеть в RIPE, вы сами через inetnum и делегирование in-addr.arpa на свои NS. В панели вашего домена этой записи нет и быть не может.
FCrDNS (Forward-Confirmed reverse DNS) — двусторонняя проверка в два шага:
IP → PTR → hostname: 203.0.113.10 отвечает mail.evilmail.pro
hostname → A/AAAA → IP: mail.evilmail.pro должен вернуть 203.0.113.10
Сошлись оба конца на одном адресе — FCrDNS пройден. И вот здесь главная ловушка: PTR может стоять, а FCrDNS проваливаться, если прямая A-запись хоста смотрит не на тот IP — например, на балансировщик или CDN. PTR есть, а forward не подтверждается.
Как принимающая сторона реально это проверяет
Крупные приёмники в 2026 году не деликатничают. Gmail в требованиях к отправителям (действуют с февраля 2024 и никуда не делись) прямо требует валидный PTR и совпадение forward/reverse для любой регулярной отправки — не только для «bulk». Outlook и Microsoft 365 режут ещё грубее: соединение с IP без обратной записи получает 550 5.7.1 Client host ... does not have a PTR record, и письмо даже не попадает в очередь.
На стороне самого сервера работают postscreen и rspamd. Postscreen делает rDNS-lookup на этапе установки соединения; rspamd начисляет вес за символ RDNS_NONE (обратной записи нет вообще) и штрафует generic-PTR, где в имени видны октеты IP. Каждый такой символ — дополнительные баллы к спам-оценке ещё до того, как фильтр взглянул на тело письма.
Что именно видит приёмник — читается в заголовке Received. Сравните две строки:
text
Received: from mail.evilmail.pro (mail.evilmail.pro [203.0.113.10]) — хорошо
Received: from unknown ([203.0.113.10]) — плохо
Во втором случае имя unknown — прямой сигнал, что PTR либо отсутствует, либо не разрешается. В Postfix за это отвечают две директивы, которые постоянно путают:
reject_unknown_reverse_client_hostname — проверяет только наличие PTR-записи. Нет PTR → reject.
reject_unknown_client_hostname — требует полный FCrDNS: PTR должен быть, и прямая запись имени должна возвращаться к тому же IP. Не сошлось → reject.
Вторая директива строже, и на приёме она бьёт по легитимным отправителям с криво настроенным, но не мошенническим DNS. Об этом ниже.
Настраиваем правильно: три записи, которые должны сойтись
Правило одного имени: PTR, HELO и баннер MX — это один и тот же FQDN. В нашем примере все три указывают на mail.evilmail.pro. Собираем связку по шагам.
1. PTR-запись. Октеты IPv4 записываются в обратном порядке и дополняются суффиксом in-addr.arpa:
text
210.69.22.212.in-addr.arpa. IN PTR mail.evilmail.pro.
Ставится в панели хостера или через делегирование обратной зоны на ваши NS. TTL 3600 более чем достаточно — запись меняется раз в жизнь сервера.
2. Прямая A-запись (и AAAA, если есть IPv6). Это тот самый forward, который подтверждает PTR:
text
mail.evilmail.pro. IN A 203.0.113.10
mail.evilmail.pro. IN AAAA 2a01:...:... ; только если у IPv6 реально есть rDNS
Классическая ловушка с IPv6: PTR прописали только на v4, а Postfix при наличии AAAA-маршрута предпочитает исходящий IPv6 — и уходит с адреса, у которого обратной записи нет. Результат — RDNS_NONE на ровном месте. Нет полноценного rDNS на IPv6 — не оставляйте это как есть: либо заведите PTR и на v6, либо принудительно отправляйте по v4.
3. HELO/EHLO Postfix должен быть FQDN, совпадающим с PTR. По умолчанию Postfix берёт HELO из myhostname, и если там короткое имя (просто mail, а не mail.evilmail.pro) — HELO невалиден, и это отдельный минус в глазах приёмника.
Конфиг Postfix, который закрывает вопрос
Минимальный набор в main.cf, который приводит исходящий HELO и баннер в порядок:
ini
myhostname = mail.evilmail.pro
mydomain = evilmail.pro
myorigin = $mydomain
# исходящий HELO — жёстко тот же FQDN, что и PTR
smtp_helo_name = mail.evilmail.pro
# нет полноценного rDNS на IPv6 → шлём по v4
smtp_address_preference = ipv4
# приём: отсекаем соединения без PTR, но не ломаем кривой forward
smtpd_client_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unknown_reverse_client_hostname
Обратите внимание: на приёме мы ставим reject_unknown_reverse_client_hostname, а неreject_unknown_client_hostname. Разница принципиальна. На потоке из тысяч доменов видно, что жёсткий полный-FCrDNS-reject регулярно отбивает нормальных отправителей, у которых forward и reverse не сходятся по недосмотру администратора, а не по злому умыслу. Наличие PTR — обязательное условие, а вот идеальную симметрию forward/reverse лучше оставить спам-фильтру (rspamd): он начислит вес, а не оборвёт соединение.
Если исходящих IP несколько, каждому нужен свой PTR, а в master.cf имеет смысл развести транспорты, чтобы каждый помеченный адрес представлялся своим smtp_helo_name.
Внешние проверки, которым можно доверять: mail-tester.com (цель 10/10, отдельно читаем блок про reverse DNS — там прямо написано, разрешается PTR или нет), отправка на [email protected] от Port25 с разбором rDNS, и SMTP-диагностика MXToolbox. А в самом Gmail откройте пришедшее письмо → «Показать оригинал» и прочитайте Received и Authentication-Results: если в Received стоит имя mail.evilmail.pro, а не голый [203.0.113.10] — PTR отработал.
Где это ломается чаще всего
Из практики обслуживания тысяч доменов — топ причин по частоте, с симптомом для каждой:
PTR не тронут и указывает на generic хостера. В Received видно 212-22-69-210.static.hoster.net, в rspamd — штраф за generic-rDNS. Лечится только через панель хостера или RIPE.
PTR поставили, а HELO забыли.myhostname = короткое mail, HELO невалиден. Симптом: письма проходят, но спам-оценка выше нормы, HELO_NOT_FQDN в логах.
IPv6 без rDNS. Самый коварный: v4 идеален, но Postfix ушёл по AAAA. В заголовке приёмника — IPv6-адрес и unknown, символ RDNS_NONE.
Несколько исходящих IP, PTR только на одном. Часть писем чистая, часть отбивается — «плавающая» проблема, которую сложно поймать.
A-запись хоста смотрит на балансировщик/CDN. PTR есть, forward не подтверждается, FCrDNS красный. Симптом: dig -x и dig дают разные IP.
Чеклист перед первой массовой отправкой
PTR существует и равен FQDN: dig -x 203.0.113.10 +short → mail.evilmail.pro.
