Когда мы говорим про доставляемость (deliverability) почты с собственного сервера, чаще всего корень проблем — не в «магии антиспама», а в базовой гигиене: корректный PTR (обратная зона), предсказуемый HELO/EHLO, валидная SPF‑запись и опрятная конфигурация Postfix с включённым TLS. Ниже — пошаговая, практичная и воспроизводимая схема проверки, рассчитанная на администраторов, которые хотят быстро вывести исходящую почту из «серой зоны» к стабильной доставке.
Что действительно влияет на доставляемость
Почтовые провайдеры и фильтры смотрят на совокупность сигналов. На первом рубеже — техническая валидность соединения и домена отправителя: обратная DNS‑запись (PTR) для IP, из которого отправляется почта; совпадение HELO/EHLO с реальным именем хоста; позитивный forward‑confirm reverse DNS (FCrDNS), когда имя из PTR резолвится обратно в тот же IP; корректная SPF‑запись, описывающая, кто имеет право отправлять почту от имени домена; и наличие TLS при исходящих соединениях. Если эти условия соблюдены, вы убираете самые грубые красные флаги и получаете шанс на нормальную репутацию и инбокс.
Важно: дальше будут примеры для Postfix. Они подходят для большинства распространённых дистрибутивов. Перед изменениями всегда сохраняйте резервную копию конфигов и следите за логами.
PTR и FCrDNS: обратная зона должна быть связана с именем хоста
PTR — это обратная DNS‑запись для вашего IP. Когда ваш сервер устанавливает SMTP‑соединение, принимающая сторона делает reverse‑lookup IP в PTR, а затем часто проверяет, резолвится ли полученное имя обратно в тот же IP (FCrDNS). Несоответствие или отсутствие PTR — одна из самых частых причин «серая зона/спам/блокировки».
Минимальные требования к PTR
Для исходящей почты у публичного IP должен быть один PTR, указывающий на полное доменное имя (FQDN) вашего почтового хоста, например mail.example.ru. Это имя должно иметь A/AAAA‑запись на тот же IP. На практике это выглядит так: IP → PTR → FQDN → A/AAAA → тот же IP. Такая связка повышает доверие.
Как проверить PTR и FCrDNS
Сначала убедитесь, что задано имя хоста и оно совпадает с тем, что вы планируете использовать в HELO:
hostnamectl status
Проверьте обратную зону и прямую резолюцию:
dig -x 203.0.113.10 +short
host 203.0.113.10
getent hosts mail.example.ru
dig A mail.example.ru +short
Если обратная зона отсутствует или указывает на неожиданное имя (например, на технический PTR провайдера), закажите настройку PTR у владельца подсети вашего IP. Важно: один IP — один PTR. Множественные PTR для одной адресации часто ухудшают оценку.
Нужен выделенный статический адрес под почтовый сервер? Рассмотрите VDS — это упростит управление rDNS и сетью.
HELO/EHLO: здравствуйте, я реальный хост
В SMTP ваш сервер представляется именем в команде HELO/EHLO. Это имя должно быть FQDN, которое вы контролируете, и которое корректно резолвится. По умолчанию Postfix использует $myhostname. Ошибочно отправлять HELO как IP‑адрес, localhost или несуществующий домен — многие фильтры режут такие соединения на входе.
Проверка и установка имени хоста
Задайте FQDN для системы и согласуйте его с DNS:
hostnamectl set-hostname mail.example.ru
Убедитесь, что в /etc/hosts нет конфликтующих записей. Пример корректного фрагмента:
127.0.0.1 localhost
127.0.1.1 mail.example.ru mail
Проверьте, что Postfix видит ожидаемое имя:
postconf myhostname
При необходимости явно укажите, чем представляться во время исходящих соединений:
postconf -e "myhostname = mail.example.ru"
postconf -e "smtp_helo_name = $myhostname"
После изменения параметров не забудьте перезапустить Postfix и посмотреть логи на предмет предупреждений.
SPF: пусть мир знает, с каких IP мы отправляем письма
SPF — это TXT‑запись в DNS домена отправителя, которая перечисляет источники, уполномоченные отправлять почту. Когда ваш сервер стучится в чужой MX, принимающая сторона вычисляет домен из обратного пути (envelope from), запрашивает его SPF и проверяет, есть ли там ваш IP или другой разрешённый механизм.
Минимальная и понятная SPF‑запись
Если вы отправляете почту только с одного сервера, достаточно явно перечислить его IP, а также разрешить A/MX домена, если они действительно указывают на ваш почтовый хост:
example.ru. TXT "v=spf1 a mx ip4:203.0.113.10 -all"
Ключевые моменты:
-allдаёт жёсткую политику «всё остальное запрещено». Для отладки можно временно ставить~all(softfail), но в продуктиве жёсткая политика прозрачнее.- Убедитесь, что суммарное количество DNS‑запросов SPF не превышает 10. Старайтесь ограничивать цепочки
includeиredirect. - Проверьте корректность кавычек и длину. Если запись большая — разбивайте на несколько строк зоны, но итоговая TXT‑строка для клиента должна склеиваться в единый текст.
Проверить опубликованную запись можно так:
dig TXT example.ru +short
Если домен только планируете — оформите его через регистрацию доменов, чтобы сразу получить доступ к DNS‑зоне.
Отдельно рекомендую вспомнить про DMARC/DKIM: мы собрали базовые подходы в материале про DNS‑записи для аутентификации почты.
TLS для Postfix: «минимум обязательно»
Оппортунистический TLS давно стал нормой. Он не гарантирует шифрование к каждому домену, но демонстрирует базовую гигиену, а для ряда получателей становится обязательным требованием. Для исходящих соединений достаточно выставить smtp_tls_security_level = may, включить логирование TLS и удостовериться, что система знает корневые сертификаты.
Базовый набор параметров для начала:
postconf -e "smtp_tls_security_level = may"
postconf -e "smtp_tls_loglevel = 1"
postconf -e "smtp_tls_note_starttls_offer = yes"
Для входящих соединений (если вы принимаете почту) настройте серверный сертификат и приватный ключ, затем включите smtpd_tls_security_level = may. Используйте действительный сертификат, соответствующий имени хоста — получить его можно через SSL-сертификаты.
Базовая проверка конфига Postfix
Прежде чем углубляться в тонкую настройку, пройдите короткий цикл проверки. Он помогает быстро поймать очевидные misconfig‑ошибки, которые и убивают deliverability.
Диагностика конфигурации
Посмотрите только изменённые от дефолта параметры — они важнее всего:
postconf -n
Убедитесь, что ключевые параметры выставлены осмысленно:
myhostname— FQDN, совпадающий с PTR и HELO.mydomainиmyorigin— домен, от имени которого вы отправляете почту.inet_interfacesиinet_protocols— соответствуют вашей сети (IPv4/IPv6).smtp_helo_name— совпадает с$myhostnameи резолвится.smtp_tls_security_levelиsmtpd_tls_security_level— включены как минимум в режимmay.
Проверка синтаксиса и прав на файлы сертификатов/ключей:
postfix check
Проверьте, что служба встала и слушает нужные порты:
systemctl status postfix
ss -lntp | grep :25
Запустите тестовые исходящие соединения и посмотрите, как сервер представляется и что отвечает другая сторона. Это помогает увидеть HELO, TLS и реакцию на SPF снаружи:
openssl s_client -starttls smtp -connect mx.example.net:25 -servername mx.example.net -brief
Параллельно держите хвост логов, чтобы ничего не пропустить:
tail -f /var/log/mail.log
Связка PTR ↔ HELO ↔ SPF: как они должны соотноситься
Чтобы уменьшить поводы для недоверия у принимающих серверов, держите единый нарратив:
- IP имеет PTR, который указывает на
mail.example.ru. mail.example.ruрезолвится в тот же IP по A/AAAA.- Postfix в HELO говорит
mail.example.ru. - SPF домена отправителя перечисляет этот IP и/или A/MX записи, которые действительно указывают на тот же хост.
Формально HELO не обязан совпадать с доменом отправителя в MAIL FROM, но когда эта связка логична и проверяема, меньше поводов попасть под эвристические фильтры.
Типичные ошибки и как их быстро исправить
«Reverse DNS does not match»
Причина: PTR указывает на техническое имя провайдера или на имя, которое не резолвится обратно в ваш IP. Решение: задать понятный PTR на FQDN вашего почтового хоста и убедиться, что A/AAAA возвращают тот же IP.
HELO как IP, localhost или пустая строка
Причина: в системе не выставлен FQDN или Postfix берёт дефолтное некорректное имя. Решение: задать myhostname, проверить /etc/hosts, указать smtp_helo_name.
SPF: none, permerror или слишком общий механизмы
Причины: SPF не опубликован; запись превышает лимиты или содержит синтаксические ошибки; используется +all, что фактически разрешает всем отправлять от вашего домена. Решение: опубликовать корректную запись, упростить механизмы до конкретных IP/A/MX, перейти на -all после тестирования.
Нет TLS на исходящих
Причина: не настроен smtp_tls_security_level и/или отсутствует доверенный стор корневых сертификатов. Решение: включить may, установить пакет с корневыми сертификатами, включить логирование TLS для диагностики.
IPv6 без rDNS или с неподготовленным HELO
Причина: при наличии AAAA‑записи или включённом IPv6 Postfix может выбирать v6‑маршрут, где не настроен PTR и FCrDNS. Решение: либо настраивать PTR/FCrDNS для IPv6, либо ограничить inet_protocols = ipv4, пока не подготовитесь к v6.
Проверочные письма и читаемые логи
Отправьте пару тестовых писем на внешние ящики, внимательно глядя в логи Postfix. Ищите строки со словами connect, EHLO, STARTTLS, status=sent, а также реакцию MX‑сервера. Это даёт фактическое подтверждение того, как вас видит мир: какое имя в HELO, использовался ли TLS, какой код ответа вернул получатель.
Если письмо улетело, но дошло в спам — посмотрите заголовки на стороне получателя: результат SPF, видимое имя HELO, TLS‑параметры, оценка по евристикам. Даже без DKIM/DMARC базовая гигиена уже должна давать заметное улучшение по сравнению с «сырой» конфигурацией.
Чек‑лист перед «боевым» запуском
Этот список можно пройти за час, и он закроет 80% проблем с доставляемостью:
- Сервер имеет статический публичный IP. На временных/динамических IP отправка почти всегда проблемна. Если нужен выделенный адрес — подойдёт VDS.
- PTR на IP указывает на ваш FQDN, а FQDN резолвится обратно в тот же IP.
- HELO/EHLO равен FQDN, которым владеете вы, и он резолвится.
- Опубликована SPF‑запись домена отправителя, включающая IP вашего хоста и/или его A/MX. Политика
-allпосле тестов. - Включён оппортунистический TLS для исходящих и корректные корневые сертификаты.
- Postfix проходит
postfix checkбез ошибок,postconf -nне содержит неожиданностей. - Логи чистые: нет постоянных deferral по причине rDNS, HELO, TLS, SPF.
Немного практики: минимальный фрагмент main.cf
Для ориентира приведу сжатый набор параметров, которые часто оказываются критичными именно для deliverability. Не копируйте бездумно — сверяйте с вашей системой и задачей:
myhostname = mail.example.ru
mydomain = example.ru
myorigin = $mydomain
inet_interfaces = all
inet_protocols = all
smtp_helo_name = $myhostname
smtp_tls_security_level = may
smtp_tls_loglevel = 1
smtp_tls_note_starttls_offer = yes
smtpd_tls_security_level = may
После изменения параметров выполните перезапуск службы и проверку логов. Далее протестируйте исходящие соединения на несколько крупных MX, чтобы увидеть, как вас встречают в реальном мире.
Куда двигаться дальше
Когда база закрыта и письма перестали отваливаться на rDNS/HELO/SPF, самое время заняться углублениями: DKIM‑подписи, политика DMARC, мониторинг отчётов, MTA‑STS и TLSRPT, подробная настройка рейтинговых ограничителей и очередей Postfix, гигиена контента (содержимое, ссылки, вложения), серые списки. Но фундамент остаётся тем же: чистый DNS, аккуратный HELO и предсказуемый SMTP‑диалог.
Если вы поднимаете почтовый сервер на новом хосте, начинайте именно с этого чек‑листа. Практика показывает: исправление PTR, приведение HELO к FQDN и публикация адекватной SPF‑записи дают мгновенный и измеримый прирост deliverability — без сложных интеграций и долгих расследований.
