Свой почтовый сервер на VPS: порт 25, PTR и почему письма всё равно попадают в спам

Что на самом деле решает получатель — и в каком порядке

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

Первое решение принимается ещё на этапе TCP-соединения: кто это вообще такой и стоит ли с ним разговаривать? В этот момент получателю известны ваш IP-адрес, его обратная DNS-запись и репутация, которую этому адресу приписывают он сам или его поставщики чёрных списков. Второе решение — на уровне SMTP-конверта, HELO и MAIL FROM, где SPF проверяется относительно подключающегося IP. Третье приходит вместе с телом письма: тогда проверяются подписи DKIM, а DMARC решает, совпадает ли результат аутентификации с доменом в видимом заголовке From:. И только после всего этого начинается что-то похожее на фильтрацию содержимого — а к этому моменту исход уже почти предрешён.

Отсюда следуют два вывода. Самые дешёвые победы — в начале цепочки: правильная PTR-запись стоит одного поля в панели управления и убирает целый класс отказов. А конец цепочки — то, из-за чего все переживают, формулировки самого письма, — это как раз то, на что у вас меньше всего влияния, и то, что начинает иметь значение только после того, как всё выше по цепочке уже в порядке.

Порт 25 — самая простая часть проблемы

Почти все крупные облака блокируют исходящий 25 порт по умолчанию, а чтобы его открыть, нужно подавать заявку. AWS, Google Cloud, Azure, Oracle Cloud и большинство крупных брендов VPS поставляют исходящий трафик на 25 порту уже отфильтрованным, а заявка на снятие блокировки — это форма, привязанная к аккаунту, который и так уже содержит вашу личность, вашу карту и ваш номер телефона. Именно на этом этапе планы по самостоятельному хостингу почты чаще всего тихо умирают, и именно поэтому большинство людей попадают на страницы вроде этой по запросу вроде у какого VPS открыт 25 порт.

Стоит чётко понимать, какой порт за что отвечает, потому что эти три постоянно путают. Порт 25 — это связь между серверами: именно через него один MX передаёт письмо другому, он никогда не требует аутентификации и это единственный порт, который имеет значение для доставки почты людям, не являющимся вашими пользователями. Порт 587 — это submission: ваши собственные клиенты аутентифицируются на вашем сервере, прежде чем он ретранслирует их почту. Порт 465 — то же самое, но с TLS с первого байта; его признали устаревшим ещё в девяностых, а затем официально вернули в RFC 8314, и сегодня это разумный вариант по умолчанию. Потеря исходящего 25 порта означает, что вы не можете отправлять почту в мир; потеря входящего 25 означает, что мир не может отправлять почту вам, и вполне возможно потерять один без другого — и потратить полдня, обвиняя во всём DNS.

На BitVPS исходящий 25 порт открыт по умолчанию на всех тарифах и во всех локациях. Не нужна ни форма, ни процедура исключения — потому что снимать нечего. Входящие 25, 465 и 587 порты защищены очисткой трафика, которая понимает почтовые протоколы, а не общим фильтром третьего уровня, — и именно это отличие важно во время атаки: фильтр, понимающий SMTP, может отсечь флуд, не задев при этом легитимный MX-трафик. Подробности — на странице про почтовый сервер, а что именно означает «очистка трафика» в общем смысле, объясняет гид по защите от DDoS.

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

Адрес, который вам достался, решает больше, чем ваша конфигурация

Ваша конфигурация — это горстка DNS-записей и день работы. А IP-адрес — это история, которую писали не вы. Подсеть /24, которая в 2019 году рассылала спам про виагру, это помнит; адрес, доставшийся вам от клиента, которого забанили месяц назад, приходит уже с готовым вердиктом; диапазон с шумными соседями оценивается по принципу «одна компания» у получателей, считающих репутацию на уровне /24. Всё это невозможно увидеть изнутри самой машины, и ничего из этого не исправить более удачным main.cf.

Поэтому проверяйте адрес до того, как возьмёте обязательства, а не после. Публичные чёрные списки расскажут часть истории: Spamhaus реально влияет на доставку — SBL и CSS фиксируют замеченных отправителей спама, PBL перечисляет диапазоны, чей оператор заявил, что они не должны отправлять почту напрямую, а DBL заносит в список домены, а не адреса. На Barracuda и SpamCop тоже стоит взглянуть, и они быстро снимают блокировку, если причина устранена. Но две репутации, от которых зависит большая часть результата, — приватные: у Google и Microsoft есть собственные оценки по IP и по домену, которые вообще нельзя запросить иначе как через Postmaster Tools и SNDS, и только когда вы отправляете достаточно писем, чтобы у них вообще сложилось какое-то мнение.

Два предостережения насчёт чек-листов, которые вы найдёте в других местах. Половина из них до сих пор советует проверять SORBS: владелец отключил SORBS 5 июня 2024 года, и его зоны теперь не отвечают вообще ничем, так что запрос к нему — это не чистая справка, а мёртвый запрос в никуда. А к уровням 2 и 3 UCEPROTECT стоит относиться скептически — они заносят в список соседей и целые автономные системы по принципу ассоциации, а затем предлагают заплатить за ускоренное удаление, поэтому большинство серьёзных получателей их просто игнорирует. Гоняться за листингом уровня 3 — верный способ потратить выходные и не добиться ничего. А вот собственный портал репутации Spamhaus воспринимать всерьёз стоит.

Это как раз тот момент, где хостинг-провайдер либо помогает, либо нет. BitVPS проверяет каждый адрес по основным спискам ещё при выдаче и заменяет его ещё до того, как вы впервые залогинитесь, если адрес там засветился; выделяет почтовым клиентам адреса из подсетей /29, которые не использовались другим почтовым клиентом последние двенадцать месяцев, и может перенести /29 между машинами в одном дата-центре без смены вашего IP — а это огромное значение имеет, когда у адреса уже есть репутация, на выстраивание которой вы потратили полгода. Ничего из этого не делает адрес «хорошим» — это делает его нейтральным, а больше честно предложить не может ни один хостинг.

PTR, HELO и A-запись должны рассказывать одну и ту же историю

Это самая частая причина отказа для грамотно настроенного почтового сервера — и при этом самая дешёвая вещь на этой странице, которую можно исправить. Три имени должны совпадать. Ваш сервер объявляет имя хоста в HELO; у этого имени хоста есть A-запись, указывающая на адрес, с которого идёт подключение; а у этого адреса есть PTR-запись, указывающая обратно на имя хоста. Резолвите вперёд — попадаете на адрес; резолвите назад — попадаете на имя. Этот цикл называется forward-confirmed reverse DNS, и с февраля 2024 года валидная PTR-запись у Gmail — это не приятный бонус, а прямое требование к каждому отправителю, массовому или нет.

Четыре способа всё сломать, в порядке убывания частоты. PTR-записи нет вообще, потому что хостинг не предоставляет такое поле. PTR есть, но она общего вида от провайдера — что-то, заканчивающееся на домен хостинговой компании, что для любого получателя означает: это арендованный адрес из диапазона, который в основном почту не рассылает. Имя в HELO неверное: значение по умолчанию из инсталлятора, короткое неполное имя хоста или localhost — ни одно из них не резолвится. И отдельный случай, который ловит даже внимательных людей: на машине есть IPv6, MTA предпочитает IPv6, когда получатель публикует AAAA-запись, а PTR на v6-адресе нет — так что почта в Gmail по IPv4 доходит прекрасно, а та же самая почта по IPv6 отклоняется. Либо настройте PTR для v6 как положено, либо закрепите транспорт через smtp_address_preference = ipv4, пока не настроите.

На BitVPS поле PTR настраивается самостоятельно в панели для любого адреса IPv4 и IPv6, принимает любой FQDN без принудительного суффикса провайдера, изменения расходятся глобально меньше чем за пять минут, а массовое редактирование охватывает до десяти адресов за раз. Подробности — на странице про сеть, а важно это именно из-за этого раздела: хостинг, который заставляет вас открывать тикет ради обратной DNS, — это хостинг, который заставит вас открывать тикет при каждом пересоздании сервера.

SPF, DKIM и DMARC: что доказывает каждый из них и что такое выравнивание

Все три публикуются в виде DNS-записей, настраиваются за час, и почти везде их описывают плохо — обычно как три взаимозаменяемых оберега от спама, а не как три разных утверждения. SPF (RFC 7208) говорит, каким адресам разрешено отправлять почту с данным отправителем конверта. DKIM (RFC 6376) добавляет криптографическую подпись поверх заголовков и тела письма, чтобы сообщение могло доказать, какой домен взял на себя ответственность за него. Ни один из них вообще ничего не говорит об адресе, который реально видит ваш получатель.

Это как раз задача DMARC (RFC 7489), и поэтому важным словом здесь становится выравнивание. DMARC проходит, когда проходит SPF или DKIM и домен, который был аутентифицирован, совпадает с доменом в видимом заголовке From:. Именно тут и живёт классическая ошибка: ваше письмо проходит SPF, потому что адрес для отказов находится в домене, который контролирует отправляющий хост, но этот домен не тот, что указан в From:, поэтому выравнивания нет, а без подписи DKIM как запасного варианта DMARC проваливается на письме, которое в логах выглядело безупречно аутентифицированным. Другая классическая ошибка — опубликовать p=reject в первый же день, ещё до того, как прочитан хоть один отчёт, а через месяц обнаружить, что система выставления счетов всё это время тихо отклонялась. Начинайте с p=none и адресом rua, читайте, что приходит, и уже потом ужесточайте политику.

Два практических замечания, которые важнее, чем кажутся на первый взгляд. Держите SPF-запись в пределах десяти DNS-запросов — каждый include: стоит один, и если вложить туда три SaaS-сервиса, лимит превысится и это превратится в постоянную ошибку, а не мягкий сбой. И меняйте селекторы DKIM время от времени, а не никогда: добавить селектор дёшево, а наличие уже опубликованного второго — это разница между пятиминутной ротацией ключа и настоящим простоем.

Планка поднялась в 2024 году — и снова в 2025-м

Двадцать лет базовым уровнем для отправки почты было примерно «имей PTR и не попади в Spamhaus». Это изменилось в феврале 2024 года, когда Google и Yahoo опубликовали почти идентичные требования к отправителям и начали их применять на практике. Теперь каждому отправителю — включая вас, отправляющего четыре письма в день, — нужна валидная forward-confirmed PTR-запись, TLS на соединении и хотя бы один из механизмов, SPF или DKIM. Отправителям, у которых больше примерно пяти тысяч писем в день на одного получателя, нужны SPF и DKIM и запись DMARC, рабочий заголовок отписки в один клик по RFC 8058 и доля жалоб на спам ниже 0.3%.

Microsoft последовала за ними 5 мая 2025 года с правилом того же типа для Outlook.com, Hotmail и Live: домены, отправляющие больше пяти тысяч писем в день на эти потребительские почтовые ящики, обязаны иметь SPF, DKIM и DMARC, а несоответствующая требованиям почта сначала направляется в «Спам», а затем и вовсе отклоняется. И поддержку отправителей Microsoft, и рекомендации Yahoo стоит потратить десять минут на чтение, прежде чем отправлять хоть что-то.

Практическое следствие для личного или маленького командного сервера не в том, что пороги вас поймают — не поймают, — а в том, что неаутентифицированная почта по умолчанию теперь выглядит по-настоящему подозрительно. Раньше письмо без записи DMARC с адреса без истории было обычным делом. В 2026 году это выглядит в точности как профиль всего того, для отлова чего и строились фильтры. Настраивайтесь так, будто вы массовый отправитель, даже если это не так, — потому что это стоит вам одного дня, а альтернатива — оцениваться по меркам группы, к которой вы на самом деле не относитесь.

Прогрев адреса, которого никто раньше не видел

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

Оценивайте ситуацию инструментами, которые дают сами получатели, а не заглядывая в собственный почтовый ящик. Postmaster Tools от Google показывает репутацию домена и IP, долю жалоб на спам и процент прохождения аутентификации — как только вы подтвердите домен, хотя инструмент останется пустым, пока вы не отправите достаточно писем, чтобы было что агрегировать, а для личного сервера это может означать «никогда», и это нормально. SNDS от Microsoft делает то же самое для Outlook.com и работает в паре с Junk Mail Reporting Program, которая пересылает жалобы напрямую вам. Одноразовый сервис проверки полезен, чтобы за десять секунд поймать сломанную запись, и бесполезен для всего остального — о репутации он не скажет ничего, потому что истории с вами у него тоже нет.

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

Что запускать и сколько для этого нужно железа

Почти всем подходит один из четырёх вариантов. Postfix в связке с Dovecot для IMAP и rspamd для фильтрации — это эталонное развёртывание: три демона, конфигурация простым текстом, и любое сообщение об ошибке, которое вы увидите, уже где-то разобрано. OpenSMTPD делает ту же работу с конфиг-файлом, который можно прочитать за один присест, и это ценится куда больше, чем звучит, в три часа ночи. Stalwart — это единый бинарник, говорящий на SMTP, IMAP и JMAP со встроенной фильтрацией, и сегодня это самый приятный вариант для развёртывания с нуля. А Mailcow или Mail-in-a-Box собирают всё это за вас, включая веб-почту, ценой стека, который вы не выбирали и который непросто разобрать на части.

Требования к железу зависят не столько от числа ящиков, сколько от того, что вы навешиваете сверху. Сами по себе SMTP и IMAP дёшевы; пара десятков почтовых ящиков — это статистическая погрешность для любой современной машины. Память съедает фильтрация. rspamd скромен — несколько сотен мегабайт с загруженными картами. А вот ClamAV нет: одна только база сигнатур уводит его далеко за гигабайт резидентной памяти, и это компонент, из-за которого небольшой инстанс с наибольшей вероятностью уйдёт в своп, — а на почтовом сервере это значит, что очередь растёт, а доставка замедляется настолько, что получатели начинают вас откладывать. Запускайте его, если хватает RAM, пропускайте, если не хватает, и пусть основную нагрузку несёт rspamd.

В пересчёте на реальные тарифы: Starter за $8.50 с 2 vCPU, 4 GB оперативной памяти и 60 GB NVMe спокойно тянет Postfix, Dovecot и rspamd для личного домена — если не подключать ClamAV. Growth за $13.50 с 4 vCPU, 8 GB и 120 GB — это тот размер, при котором вы вообще перестаёте об этом думать: двадцать-тридцать почтовых ящиков с полноценной фильтрацией и солидный запас для хранилища писем, которое будет расти годами. Первым на самом деле заканчивается место на диске, потому что письма хранят вечно все, кто их хоть раз получил.

Разворачиваем всё в правильном порядке

1. Настройте домен и разверните сервер. Определитесь с именем хоста, под которым сервер будет представляться, — по соглашению используется mail.example.com, — опубликуйте его A-запись, добавьте AAAA только если планируете отправлять почту по IPv6, и опубликуйте MX-запись домена, указывающую на это имя. Выберите локацию ближе всего к тем, с кем вы переписываетесь; на BitVPS сервер запускается примерно через шестьдесят секунд после подтверждения оплаты, с уже открытым исходящим 25 портом.

2. Настройте соответствующую обратную DNS. Укажите PTR для адреса IPv4 — и для адреса IPv6, если вы опубликовали AAAA, — точно таким же, как имя хоста из первого шага. Прямая и обратная зоны должны совпадать в обе стороны. Это одно поле в панели, и это самая ценная минута из всей процедуры.

3. Откройте нужные порты в обе стороны. Исходящий 25 — для отправки, входящий 25 — для приёма, 587 и 465 — чтобы ваши пользователи могли отправлять письма через submission, 993 — для IMAP, всё остальное закрыто. Файрвол, который разрешает исходящий 25, но блокирует входящий, первый час отладки будет выглядеть в точности как проблема с DNS, хотя ею не является.

4. Установите MTA и дайте ему настоящую идентичность. Postfix, OpenSMTPD или Stalwart; укажите в качестве имени HELO имя хоста из первого шага; включите TLS с сертификатом для этого имени. Let's Encrypt бесплатен и именно его предъявляет большая часть интернета. Отправьте письмо самому себе и прочитайте заголовки, прежде чем двигаться дальше — все следующие шаги предполагают, что этот сработал.

5. Опубликуйте SPF, DKIM и DMARC. SPF-запись, перечисляющую отправляющий адрес и заканчивающуюся на ~all, пока вы тестируете. Ключ DKIM на 2048 бит с опубликованным селектором и включённой подписью. Запись DMARC на p=none с адресом rua, чтобы начали приходить отчёты. Три DNS-записи, никаких затрат, максимум час работы.

6. Смотрите на результаты аутентификации, а не на входящие. Отправьте письма на Gmail, на Outlook.com и одному корпоративному получателю, затем откройте Authentication-Results у каждого. Вам нужны spf=pass, dkim=pass, dmarc=pass, а выравнивание должно быть по домену из видимого From:. Попадание в «Спам» при трёх пройденных проверках — это проблема репутации; попадание в «Спам» при провале одной из них — это проблема конфигурации. Чинятся они совершенно по-разному, и если их перепутать, можно потерять недели.

7. Ужесточайте политику, когда отчёты станут чистыми. После недели-двух отчётов DMARC, в которых ни один легитимный источник не проваливается, переходите к p=quarantine, затем позже к p=reject, и меняйте SPF с ~all на -all. Ужесточение до чтения отчётов — это именно то, как люди месяц блокируют собственные счета, даже не замечая этого.

8. Добавьте то, что все забывают. Опубликуйте MTA-STS и TLS-RPT, чтобы другие отправители знали, что с вами нужно настаивать на TLS, добавьте DANE, если ваша зона подписана, поставьте rspamd перед почтовым ящиком, делайте резервную копию почтового хранилища куда-то не на эту же машину и шифруйте её на диске — гид по полному шифрованию диска на VPS объясняет, что это защищает, а что нет. И следите за исходящей очередью: тихо растущая очередь — это первый симптом проблемы с репутацией, и он проявляется за дни до того, как вы заметите пропавшие ответы.

Когда self-hosting — неподходящий инструмент

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

Есть ещё один компромисс с анонимностью, который в большинстве материалов вообще не упоминают. Почтовый сервер — это наименее анонимная вещь, которую вы можете запустить. Он публикует домен, стабильный адрес, PTR-запись, называющую этот домен, MX-запись, связывающую всё это вместе, и выдаёт каждому получателю полный набор заголовков, описывающих путь письма. Анонимность и публичный MX тянут в противоположные стороны, и если вы здесь ради приватности, а не ради контроля, прочитайте насколько на самом деле отслеживаем криптохостинг, прежде чем что-то разворачивать. Self-hosting действительно убирает третью сторону из вашей хранимой почты и её метаданных — это реальный и стоящий выигрыш, — но саму почту это анонимной не делает и не может сделать, потому что половина любой переписки живёт в чужом почтовом ящике.

Схема, которая работает для большинства, — это разделение. Почту, которая обязательно должна дойти, держите у провайдера с репутацией, а второй домен для переписки, которую хочется убрать со сторонней инфраструктуры, разверните у себя — и пусть каждый несёт ту нагрузку, с которой справляется лучше. Это стоит одной дополнительной DNS-зоны, означает, что ни одна из систем не делает работу, с которой справляется плохо, и именно так поступает значительная часть людей, которые держат почтовый сервер на BitVPS. Что бы вы ни отправляли — только с согласия получателей: купленные базы не разрешены нашей политикой допустимого использования и это самый быстрый способ сжечь адрес, который был чистым, когда мы его вам выдали.