Стоит ли поднимать свой почтовый сервер в 2026 году?

Краткий ответ

Собственный почтовый сервер по-прежнему актуален в 2026 году, если разделить задачу на две части. Прием почты на собственном VPS несет низкие риски и работает стабильно, так как вы выступаете получателем, и вам не требуется доверие со стороны других систем. Отправка почты, которую примут крупные почтовые провайдеры — это иная задача, зависящая от репутации IP-адреса, которую вы наследуете, а не создаете с нуля.

Опытные администраторы используют гибридную схему. Их собственный сервер хранит почтовые ящики и архивы, а исходящая почта отправляется через аутентифицируемый релей по порту 587. Полностью самостоятельный хостинг в обоих направлениях все еще оправдан в ряде специфических случаев, которые описаны в конце этой статьи.

Самая сложная часть self-hosting почты — это доставляемость

Установка почтового сервера занимает выходные. Современный стек предоставляет SMTP (simple mail transfer protocol) для передачи почты, IMAP (internet message access protocol) для её чтения, фильтрацию спама и веб-интерфейс в одном compose-файле, и руководство Установка почтового сервера Mailcow на VPS охватывает эти аспекты. Установка — это не самая сложная часть.

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

Вы увидите отказ. Gmail отправляет постоянный отказ следующего вида:

550-5.7.1 [203.0.113.5      19] Our system has detected that this message is
550-5.7.1 likely unsolicited mail. To reduce the amount of spam sent to Gmail,
550-5.7.1 this message has been blocked.

Microsoft отправляет другой ответ, заканчивающийся кодом из черного списка, который может варьироваться:

550 5.7.1 Unfortunately, messages from [203.0.113.5] weren't sent. Please
contact your Internet service provider since part of their network is on
our block list (S3150).

Прежде всего смотрите на первую цифру кода. Код, начинающийся с 4, означает временную проблему, поэтому ваш сервер сохраняет сообщение и повторяет попытку. Код, начинающийся с 5, означает постоянную ошибку, поэтому сообщение сразу возвращается отправителю. Отложенная доставка 4xx, которая не проходит, означает ограничение скорости или лимит репутации, и она может разрешиться сама собой. Ошибка 5xx — это окончательное решение, и она не исчезнет.

Почему почта с нового сервера попадает в спам?

IP-адрес не является новым. Вы не получаете «чистый» адрес. Вам достается адрес из пула провайдера, который уже использовался ранее, и его история переходит вместе с ним. Если предыдущий владелец рассылал спам, ваше самое первое письмо может быть отклонено еще до того, как вы отправите второе.

Проверьте адрес, прежде чем разворачивать на нем какие-либо сервисы. Публичные черные списки (blocklists) отвечают через DNS, при этом четыре октета адреса указываются в обратном порядке:

sudo apt update && sudo apt install -y bind9-dnsutils netcat-openbsd swaks
dig +short 10.0.0.10.zen.spamhaus.org

Пустой ответ означает, что адрес не находится в списке. Ответ внутри 127.0.0.0/8 означает, что адрес в списке, а последний октет указывает на то, какой именно список сработал. Важный нюанс: Spamhaus отклоняет запросы, поступающие через крупные публичные резолверы, поэтому тот же запрос через 8.8.8.8 вернет 127.255.255.254 независимо от реального статуса. Этот код означает, что запрос был отклонен, а не то, что адрес находится в списке. Выполняйте проверку через резолвер вашего собственного сервера или используйте веб-интерфейс для поиска.

Чистый результат — это необходимое, но недостаточное условие. Отсутствие в списках означает лишь то, что на этот адрес в последнее время никто не жаловался. Это не дает положительной репутации, а именно она позволяет письмам попадать во «Входящие». Репутация зарабатывается отправкой небольших объемов востребованной почты в течение нескольких недель.

Ваши соседи по сети также имеют значение, так как некоторые получатели оценивают репутацию всего сетевого блока, а не отдельного адреса. Когда другой клиент в том же диапазоне /24 начинает рассылать спам, доставка вашей почты может замедлиться из-за ассоциации с ним. Именно из-за такого подхода на уровне блока жалобы на злоупотребления приходят на почту VPS за трафик, который владелец аккаунта никогда не отправлял: жалоба следует за диапазоном адресов.

Что нужно подтвердить перед началом: порт 25 и PTR-запись

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

Проверьте путь с самого сервера:

nc -vz gmail-smtp-in.l.google.com 25

Открытый путь выводит succeeded! в течение секунды. Заблокированный путь зависает и по истечении времени выдает ошибку без указания причины блокировки, так как молча отброшенный пакет выглядит точно так же, как обычная сетевая проблема.

Второе требование — PTR-запись, также называемая обратной DNS-записью. Получатели берут IP-адрес, с которого к ним подключились, запрашивают его PTR-запись для получения имени, а затем запрашивают это имя, чтобы получить адрес обратно. Когда они совпадают, это называется forward-confirmed reverse DNS. Это простая проверка того, что подключающийся хост принадлежит тому, за кого себя выдает.

dig -x 203.0.113.5 +short
dig +short mail.example.com

Первый запрос должен вернуть имя вашего почтового хоста. Второй должен вернуть тот же адрес, с которого вы начали. Только владелец IP-адреса может опубликовать его PTR-запись, поэтому это настройка, которую выполняет ваш хостинг-провайдер или предоставляет доступ к ней в панели управления. Отсутствие PTR-записи или использование общего имени, например 203-0-113-5.static.example-isp.net, является сильным негативным сигналом, так как у настоящих почтовых серверов почти всегда есть соответствующее имя, а у источников массового спама — часто нет.

Если ваш хостинг также назначает IPv6 и ваш сервер отдает ему предпочтение, все вышесказанное относится и к IPv6-адресу, причем Gmail в этом вопросе более строг. Отправка через IPv6 с адреса без PTR-записи приводит к отклонению письма с сообщением о том, что оно не соответствует правилам отправки IPv6 в части PTR-записей и аутентификации. Если вы не можете настроить PTR-запись для IPv6, отправляйте почту только через IPv4. В Postfix для этого используется smtp_address_preference = ipv4, чтобы отдать предпочтение IPv4, или inet_protocols = ipv4, чтобы полностью отключить IPv6.

Три вопроса, которые нужно задать любому хостинг-провайдеру

1. Открыт ли исходящий TCP-порт 25 на новом аккаунте, и если нет, то каков точный процесс и сроки его открытия?
2. Могу ли я настроить PTR-запись для своего IPv4-адреса и для IPv6-адреса, и где это делается?
3. Если окажется, что мой адрес находится в черном списке из-за предыдущего клиента, перенесете ли вы меня на другой адрес?

Задайте все три вопроса до покупки, а не после. Хостинг, который четко отвечает на первые два и говорит «нет» на третий, все еще пригоден для работы, так как вы можете проверить адрес в первый же день и отказаться от услуг. Хостинг, который отказывается отвечать на них в письменном виде, уже показал вам, чего ожидать от размещения почты на его мощностях.

Что на самом деле подтверждают SPF, DKIM и DMARC

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

SPF (sender policy framework) — это TXT-запись, содержащая список серверов, которым разрешено отправлять почту для вашего домена. Получатель сверяет её с адресом отправителя конверта (envelope sender), который передаётся в команде SMTP MAIL FROM, а не с заголовком From:, который видит пользователь.

DKIM (domainkeys identified mail) добавляет криптографическую подпись к заголовкам сообщения, охватывая тело письма и выбранный список заголовков. Соответствующий открытый ключ размещается в DNS под выбранным вами селектором. Любой получатель может проверить, что сообщение отправлено владельцем закрытого ключа и не было изменено в процессе передачи.

DMARC (domain-based message authentication, reporting and conformance) связывает две предыдущие записи с доменом в видимом заголовке From: и указывает получателям, как действовать в случае неудачной проверки.

example.com.                  TXT  "v=spf1 mx -all"
mail._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
_dmarc.example.com.           TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Ключевое понятие здесь — выравнивание (alignment). DMARC не проходит проверку только потому, что пройден SPF. Он считается успешным, если пройден SPF или DKIM, а домен, прошедший проверку, совпадает с доменом в заголовке From:. Именно здесь пересылаемая почта часто терпит неудачу: ретранслятор, который перезаписывает адрес отправителя конверта на свой собственный, всё равно обеспечивает прохождение SPF, но домен, прошедший проверку, принадлежит ретранслятору. В итоге выравнивание нарушается, и DMARC выдаёт ошибку, если только ваша собственная подпись DKIM не присутствует и не является валидной. Подписывайте письма ключом, опубликованным в вашем домене, и проблема исчезнет.

Выравнивание также объясняет работу пересылки (forwarding). Когда список рассылки или старый университетский адрес пересылает ваше сообщение дальше, сервером-отправителем становится IP-адрес пересылающего сервера, которого нет в вашей SPF-записи, поэтому SPF не проходит проверку у конечного получателя. DKIM сохраняет работоспособность при пересылке, пока заголовки, которые он подписал, не были изменены. Именно DKIM должен работать в таких случаях.

Сначала опубликуйте p=none с адресом для отчётов rua= и изучайте сводные отчёты в течение двух недель, прежде чем ужесточать политики. Эти отчёты — единственный источник информации о письмах, отправленных от вашего имени, которые вы не отправляли, и единственный способ обнаружить забытый вами сервис пересылки. Переход сразу к p=reject пропускает этот этап и приводит к блокировке легитимной почты без возможности отследить, что именно вызвало сбой.

Затем протестируйте всю цепочку целиком. Отправьте одно сообщение на аккаунт, который вы контролируете у крупного провайдера, и откройте его исходный код:

swaks --to you@gmail.com --from postmaster@example.com --server 127.0.0.1
sudo journalctl -t postfix/smtp -f

swaks выводит SMTP-сессию в реальном времени. Собственная строка лога Postfix для доставки заканчивается на status=sent (250 2.0.0 OK ...), если принимающий сервер принял сообщение. Любой другой результат записывает текст отказа дословно, и именно по этой строке следует искать причину. В доставленном сообщении исходный код содержит заголовок Authentication-Results:, в котором указан статус каждой проверки (pass или fail) и домен, который прошёл аутентификацию. Все три проверки должны иметь статус pass, а домен должен совпадать с вашим.

Как узнать о проблемах с репутацией?

Механизм обратной связи (feedback loop) — это система, при которой почтовый провайдер отправляет вам копию сообщения каждый раз, когда один из его пользователей нажимает кнопку «Спам». Без этого механизма первым признаком проблем становится отказ в доставке, о котором вы узнаете с опозданием в несколько недель.

Программы различаются, и не все они подходят для одного VPS с единственным IP-адресом. По состоянию на август 2026 года Microsoft предоставляет сервис данных и жалоб для конкретных адресов, на который может зарегистрироваться владелец адреса; Yahoo предлагает механизм обратной связи по жалобам, привязанный к домену подписи DKIM; а Google публикует сводные данные о репутации вместо отдельных жалоб в панели управления, которая остается пустой, пока вы не начнете отправлять значительный ежедневный объем писем их пользователям. Ознакомьтесь с актуальными условиями каждой программы, прежде чем полагаться на них, так как эти правила меняются, и никто не обязан предоставлять вам доступ к этим данным.

Опубликованные Google требования к массовым отправителям, действующие с февраля 2024 года, являются наиболее четким публичным заявлением о том, чего ожидает крупный получатель почты. Отправитель, рассылающий более 5000 сообщений в день на личные аккаунты Gmail, обязан проходить аутентификацию через SPF и DKIM, публиковать политику DMARC, предоставлять возможность отписки в один клик для массовых рассылок и поддерживать уровень жалоб на спам ниже 0,3 процента. Личная почта с небольшого сервера находится значительно ниже этого порога, но одни и те же сигналы анализируются при любом объеме трафика, а уровень жалоб — это тот показатель, который невозможно увидеть без механизма обратной связи.

Разделение ответственности: прием почты на своем сервере, отправка через релей

Прием почты — это часть задачи, которая практически не имеет недостатков. Никому не нужно доверять вам, чтобы отправить письмо на ваш адрес. Ваша MX-запись, DNS-запись, указывающая на почтовый сервер вашего домена, направляет отправителей к вам, и каждое последующее решение остается за вами: что хранить, как долго, как индексировать и кому разрешить поиск. Хранение данных стоит недорого, а архив, который принадлежит вам, не может быть удален из-за автоматизированных правил сторонних сервисов. Работа реальна и ограничена: обновляйте спам-фильтр, следите за продлением TLS (transport layer security) сертификатов, делайте резервные копии и следите за тем, чтобы диск не переполнился.

Отправка — это та часть, где вы платите за решение сложной проблемы. Настройте свой сервер так, чтобы он передавал каждое исходящее сообщение на аутентифицированный релей через порт 587, вместо того чтобы взаимодействовать с внешним миром через порт 25. В файле main.cf для Postfix:

relayhost = [smtp.relay.example]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = encrypt

Запишите учетные данные в /etc/postfix/sasl_passwd с помощью текстового редактора, чтобы пароль не попал в историю командной оболочки. Это одна строка, и имя хоста слева должно быть записано в точности так, как оно указано в relayhost:

[smtp.relay.example]:587 username:password

sudo chmod 600 /etc/postfix/sasl_passwd
sudo postmap /etc/postfix/sasl_passwd
sudo chmod 600 /etc/postfix/sasl_passwd.db
sudo systemctl reload postfix

Сообщение, отправленное после перезагрузки, запишет в лог relay=smtp.relay.example[...]:587 и status=sent. Строка лога с текстом SASL authentication failed означает, что учетные данные не были приняты. Чаще всего это происходит из-за того, что имя хоста в sasl_passwd записано иначе, чем в relayhost, так как поиск выполняется по точному совпадению строк.

Такое разделение работает, потому что релей владеет IP-адресами с многолетней историей успешной доставки, и поддержание этой репутации — его основной бизнес. Вы сохраняете домен, почтовые ящики, архив и возможность сменить провайдера, так как смена релея — это одна строка конфигурации и одна DNS-запись. Вы жертвуете конфиденциальностью исходящей почты по отношению к оператору релея. Это честная цена за данную схему, и лучше принять это решение осознанно.

В первый же день стоит сделать еще одно разделение. Любая массовая рассылка должна уходить с отдельного поддомена со своим собственным DKIM-ключом: news.example.com для новостной рассылки и mail.example.com для личной почты. Репутация привязывается к домену отправителя, поэтому жалобы на самостоятельно хостящуюся рассылку Listmonk не смогут негативно повлиять на вашу личную почту.

Когда полный self-hosting остается верным решением?

Объем. Тарифы с оплатой за каждое сообщение удобны при отправке сотен писем в месяц, но становятся невыгодными при миллионных объемах. При таких масштабах вы можете позволить себе выделенные адреса и график прогрева, который обеспечивает их работоспособность.

Юрисдикция. Если нормативные акты или договор требуют, чтобы почта не хранилась на дисках третьих лиц, качество доставки перестает быть решающим фактором. Использование реле в таком случае просто недопустимо.

Контроль, который нельзя купить. Правила хранения данных, соответствующие вашей политике, а не тарифному плану; отдельный адрес для каждого сервиса, чтобы отслеживать утечки; фильтрация, выполняющая ваш собственный код; отсутствие риска блокировки аккаунта системой без возможности апелляции.

Почта, которая не покидает вашу сеть. Уведомления и другие сообщения между машинами не имеют проблем с доставляемостью, так как обе стороны принадлежат вам. Локальный SMTP-сервер, доставляющий почту в ваши собственные ящики — это исчерпывающее решение. Тот же принцип лежит в основе предоставления ассистенту собственного self-hosted почтового ящика через MCP (model context protocol).

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

Во сколько обходится первый год эксплуатации почтового сервера?

Первая неделя уходит на сборку: установка пакетов, настройка DNS-записей, TLS-сертификатов, отправка первых тестовых сообщений и настройка DMARC на p=none.

Со второй по шестую неделю наступает этап, который никто не планирует. Вы изучаете сводные отчеты DMARC, обнаруживаете проблемы с выравниванием, о которых не подозревали, находите пересыльщик, нарушающий SPF, а затем переводите политику на p=quarantine, а позже на p=reject. Этот период определяет, станет ли самостоятельный хостинг для вас рутиной или чем-то, что вызывает раздражение.

После этого нагрузка стабилизируется примерно на одном часе в месяц: обновление пакетов, проверка продления сертификата вместо слепого доверия, тест восстановления из бэкапа, контроль роста дискового пространства и одна проверка в черных списках.

Затем наступает неделя, которую невозможно запланировать. Ваш адрес попадает в список из-за действий, которые вы не совершали. Крупный получатель меняет правила, и ваша почта снова начинает попадать в спам. Поставленная в очередь почта — это не потерянная почта: Postfix по умолчанию повторяет попытку доставки отложенного сообщения в течение пяти дней, что задается параметром maximal_queue_lifetime = 5d, поэтому простой длительностью в несколько часов грозит лишь задержкой доставки. Простой длительностью в неделю грозит потерей почты.

Резервная MX-запись — более слабое решение, чем кажется. Отправляющие серверы и так повторяют попытки доставки в течение нескольких дней, поэтому вторичный сервер, который только ставит почту в очередь, дает мало преимуществ. Хуже того, вторичный сервер, принимающий почту для вашего домена, не зная, какие адреса существуют, будет принимать письма для несуществующих адресов, а затем отправлять уведомления о недоставке (bounce) поддельным отправителям, что превратит ваш резервный сервер в источник backscatter. Потратьте усилия на мониторинг и на восстановление, которое вы реально протестировали.

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

FAQ

Можно ли разместить почтовый сервер самостоятельно, если провайдер VPS блокирует исходящий порт 25?

Да, для получения почты и для отправки через релей. Входящая почта поступает на порт 25 вашего сервера, и блокировка исходящих соединений на это не влияет. Исходящая почта отправляется через аутентифицированный релей на порту 587, который провайдеры не блокируют. Вы не сможете доставлять почту напрямую на другие почтовые серверы, так как доставка между серверами по определению происходит через порт 25. Проверьте это с помощью nc -vz gmail-smtp-in.l.google.com 25. Зависание с последующим таймаутом означает, что порт заблокирован.

Почему мои письма попадают в спам, хотя SPF, DKIM и DMARC проходят проверку?

Аутентификация подтверждает, кто отправил сообщение. Она не доказывает, что сообщение ожидаемо. Прохождение всех трех проверок переводит вас из категории «неопознанный» в «опознанный», после чего получатель оценивает репутацию вашего IP-адреса и домена, которой у нового отправителя еще нет. Нарабатывайте репутацию, отправляя небольшие объемы ожидаемой почты в течение нескольких недель. Затем убедитесь, что PTR-запись совпадает с именем вашего почтового хоста в обоих направлениях, и проверьте, не содержит ли контент факторов, снижающих рейтинг, например, сокращателей ссылок или незнакомых доменов для отслеживания.

Нужен ли выделенный IP-адрес для собственного почтового сервера?

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

Безопасно ли переносить основной адрес на собственный сервер?

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

Какая минимальная конфигурация позволяет сохранить контроль над почтой?

Ваш собственный сервер для хранения почтовых ящиков и архива, при этом исходящая почта передается на аутентифицированный релей через порт 587. Вы владеете данными и доменом, полностью избегая проблем с репутацией. Стоимость смены решения остается низкой, так как релей — это одна строка конфигурации и одна SPF-запись, поэтому замена релея в будущем займет не более пары часов работы.