📧 Почта на VPS: SMTP, SPF, DKIM, DMARC и PTR

Почта на VPS работает не только за счёт почтового ящика и SMTP-сервера. Чтобы письма доходили во входящие, домен, DNS-записи, IP-адрес и серверная настройка должны выглядеть доверенно для принимающей стороны.

Упрощённая схема доставки письма выглядит так: сайт или почтовый клиент → SMTP → DNS-записи → принимающий сервер → проверка SPF/DKIM/DMARC/PTR → inbox или spam

Если сайт отправляет письмо с адреса info@example.com, принимающий сервер проверяет не только само письмо. Он смотрит, имеет ли этот сервер право отправлять почту от имени домена, подписано ли письмо DKIM, есть ли DMARC-политика и совпадает ли IP с обратной DNS-записью.

Минимальный набор для доменной почты обычно включает:

MX-запись — куда принимать входящие письма (обязательно);
A-запись — на какой IP указывает почтовый хост (желательно);
SPF — какие серверы имеют право отправлять письма от имени домена (крайне желательно);
DKIM — криптографическая подпись исходящих писем (желательно);
DMARC — политика обработки писем, которые не прошли SPF или DKIM (желательно);
PTR — обратная DNS-запись для IP-адреса VPS (желательно).

Главная сложность почты на VPS — не “запустить SMTP”. SMTP можно поднять быстро, но это не гарантирует доставку во входящие. Новый IP может не иметь репутации, порт 25 может быть заблокирован провайдером, PTR может отсутствовать, а SPF, DKIM и DMARC могут быть настроены с ошибками.

Для обычных сайтов, интернет-магазинов, заявок, уведомлений, восстановления пароля и транзакционных писем часто проще использовать внешний SMTP-сервис. Он берёт на себя доставляемость, репутацию IP, логи отправки, bounce-обработку и часть антиспам-задач.

Собственный почтовый сервер на VPS имеет смысл, если нужен полный контроль над доменной почтой, есть опыт администрирования и понятно, кто будет следить за DNS, прогревом адресов, очередью писем, логами, blacklist, безопасностью и обновлениями.

Самые частые ошибки — не настроить PTR (это не обязательно, но желательно), разрешить в SPF не тот сервер, включить DMARC слишком жёстко без тестов, не подписывать письма DKIM при настроенном DMARC, игнорировать blacklist и не проверить, открыт ли исходящий SMTP-порт.

Нужно сначала решить, нужен ли собственный почтовый сервер вообще, затем настроить домен и DNS-записи, проверить отправку, убедиться в подписи DKIM, протестировать DMARC в мягком режиме и только после этого считать почту готовой к работе.

Как работает доставка письма с VPS

Почта на VPS кажется простой только на первом шаге: сайт или почтовый клиент отправляет письмо через SMTP, а получатель его принимает. На практике между отправкой и попаданием во входящие есть несколько проверок.

Принимающий сервер оценивает не только текст письма. Он смотрит на домен, IP-адрес, DNS-записи, подпись DKIM, SPF, DMARC, PTR и репутацию отправителя.

Чтобы понять, почему письма с VPS иногда уходят, но не доходят во входящие клиентам, сначала нужно разобрать сам маршрут доставки.

Схема: сайт или почтовый клиент → SMTP → DNS → принимающий сервер

Например, сайт на VPS отправляет письмо с адреса: no-reply@example.com

Сначала сайт передаёт письмо SMTP-серверу. Это может быть собственный SMTP на VPS или внешний SMTP-сервис.

Затем письмо уходит на сервер получателя исходя из MX-записи домена получателя: Gmail, Outlook, корпоративную почту или любой другой почтовый сервер. На этом этапе получатель смотрит, от какого домена пришло письмо, с какого IP оно отправлено и какие DNS-записи есть у домена.

Если всё выглядит корректно, письмо может попасть во входящие. Если есть проблемы с DNS, подписью, репутацией IP или содержанием письма, оно может оказаться в спаме или даже быть отклонено.

То есть SMTP отвечает только за передачу письма. А решение “доверять или не доверять” принимает уже принимающая сторона. Поэтому следующий важный вопрос — что именно она проверяет.

Что проверяет принимающая сторона

Когда письмо приходит на принимающий сервер, он пытается понять, действительно ли этот сервер имеет право отправлять почту от имени домена.

Для этого используются несколько проверок.

SPF показывает, какие серверы имеют право отправлять письма от имени домена. Если письмо пришло с IP, которого нет в SPF-записи, принимающий сервер может посчитать его подозрительным.

DKIM добавляет к письму криптографическую подпись. Получатель проверяет её через публичный ключ в DNS. Если подпись есть и она корректна, это подтверждает, что письмо связано с доменом и не было изменено по пути.

DMARC задаёт политику для писем, которые не прошли SPF или DKIM. Например, домен может попросить принимающие серверы только наблюдать за ошибками, отправлять такие письма в spam или отклонять их.

PTR — это обратная DNS-запись для IP-адреса. Она показывает, какое доменное имя связано с IP отправителя. Для почтовых серверов PTR особенно важен: отсутствие обратной записи часто ухудшает доверие к отправке. PTR-запись не является необходимой, но является желательной, многие устаревшие антиспам-системы активно используют её проверку. Также она должна совпадать с тем, что передаёт почтовый сервер отправителя в запросе на отправку (HELO/EHLO).

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

Из-за этого возникает важный нюанс: письмо может успешно уйти с VPS, но всё равно не попасть во входящие. Рабочий SMTP ещё не означает хорошую доставляемость.

Почему письмо может попасть в spam даже при рабочем SMTP

Рабочий SMTP означает только то, что сервер может принять письмо на отправку и попытаться передать его дальше. Это ещё не гарантия доставки во входящие.

Письмо может попасть в spam, если у домена или сервера не хватает доверия.

Частые причины:

Нет PTR-записи для IP;
SPF не разрешает отправку с текущего сервера;
DKIM не подписывает исходящие письма;
DMARC настроен неправильно или слишком жёстко;
IP-адрес VPS уже был в blacklist;
Почтовый сервер новый и не имеет репутации;
Исходящий порт заблокирован или письма уходят нестабильно;
Письмо похоже на спам по содержанию;
В письме много ссылок, подозрительных вложений или сокращателей URL.

Например, сайт может успешно отправить письмо восстановления пароля. В логах SMTP всё будет выглядеть нормально. Но Gmail или Outlook всё равно могут поместить письмо в spam, если отправитель не подписывает письма DKIM или SPF указывает не на тот сервер.

Поэтому после настройки почты нужно проверять не только сам факт отправки. Важно смотреть, куда попало письмо, прошли ли SPF, DKIM и DMARC, какой IP видит получатель и нет ли сервера в blacklist.

Если почта нужна для важных уведомлений, заказов, заявок и восстановления пароля, иногда надёжнее использовать внешний SMTP-сервис. Собственный сервер на VPS даёт контроль, но требует постоянного внимания к DNS, репутации, логам и безопасности. Поэтому дальше стоит отдельно разобрать, что именно нужно подготовить для доменной почты на VPS.

Что нужно для доменной почты на VPS

Домен и MX-запись

Для доменной почты сначала нужен домен, от имени которого будут отправляться и приниматься письма. Например, если почта должна выглядеть как info@example.com, то все ключевые записи настраиваются в DNS-зоне example.com.

Для входящей почты используется MX-запись. Она показывает, на какой почтовый сервер нужно доставлять письма для домена.

Пример:

example.com. MX 10 mail.example.com.

mail.example.com. A 203.0.113.10

В этой схеме письма для @example.com должны приходить на сервер mail.example.com, а сам mail.example.com указывает на IP-адрес VPS.

Важно не путать MX и SMTP для отправки. MX отвечает за входящую почту: куда другие серверы будут доставлять письма. Для отправки нужен уже SMTP-сервер и корректные DNS-записи, которые подтверждают право отправлять письма от имени домена.

Существуют антиспам-системы которые проверяют наличие MX-записи, но они довольно редки, поэтому если почту принимать не планируется, создание MX-записи можно пропустить.

Когда домен и MX-запись готовы, следующий вопрос — чем именно отправлять письма: собственным SMTP на VPS или внешним SMTP-сервисом.

SMTP-сервер для отправки писем

SMTP-сервер отвечает за отправку писем. Через него могут уходить сообщения с сайта, из CRM, из почтового клиента или из приложения на VPS.

Вариантов два.

Первый — поднять собственный почтовый сервер на VPS. В таком случае администратор сам настраивает SMTP, очереди писем, TLS, DKIM-подпись, пользователей, логи, защиту от спама и лимиты отправки.

Второй — использовать внешний SMTP-сервис. Тогда сайт или приложение отправляет письмо через стороннего провайдера, а тот уже занимается доставкой, репутацией IP, bounce-обработкой и частью антиспам-задач.

Собственный SMTP даёт больше контроля, но требует больше обслуживания. Нужно следить за очередью писем, логами, обновлениями, открытыми портами, репутацией IP и попаданием в blacklist.

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

Но какой бы вариант ни был выбран, домен должен объяснить принимающим серверам, кто имеет право отправлять письма от его имени. Для этого нужны SPF, DKIM и DMARC.

SPF, DKIM и DMARC

SPF, DKIM и DMARC — это три базовые проверки, которые помогают принимающим серверам понять, можно ли доверять письму.

SPF указывает, какие серверы имеют право отправлять почту от имени домена. Если письмо отправляется с VPS, SPF должен разрешать IP или имя этого VPS. Если используется внешний SMTP-сервис, в SPF нужно добавить его имена с адресами или include-запись.

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

DMARC связывает SPF и DKIM в общую политику. Он говорит принимающему серверу, что делать, если письмо не прошло проверку: ничего не делать, отправить в spam или отклонить.

На старте DMARC обычно не ставят сразу в жёсткий режим. Лучше сначала использовать наблюдение, посмотреть отчёты и убедиться, что легитимные письма проходят SPF и DKIM.

Пример мягкой политики: v=DMARC1; p=none; rua=mailto:dmarc@example.com

Такой подход помогает не сломать доставку писем с сайта, CRM, внешнего SMTP или других сервисов, которые тоже отправляют письма от имени домена.

Когда SPF, DKIM и DMARC настроены, остаётся ещё одна важная проверка, которую часто забывают: обратная DNS-запись для IP-адреса.

PTR-запись для IP-адреса

PTR-запись — это обратная DNS-запись. Она связывает IP-адрес сервера с доменным именем.

Если обычная A-запись отвечает на вопрос “на какой IP указывает домен”, то PTR отвечает наоборот: “какое имя соответствует этому IP”.

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

Пример логики:

mail.example.com → 203.0.113.10

203.0.113.10 → mail.example.com

Особенность PTR-записи в том, что она настраивается не владельцем домена, а владельцем IP-адреса, в случае VPS - обычно в панели провайдера или через обращение в поддержку. Владелец домена обычно не может сам изменить обратную запись для IP.

Если PTR нет, письма могут чаще попадать в spam или отклоняться. Особенно если сервер отправляет почту напрямую на крупные почтовые системы.

Но даже правильный PTR не спасёт доставку, если IP-адрес уже имеет плохую репутацию или почтовые порты заблокированы.

Открытые порты и репутация IP

Для почты важны не только DNS-записи, но и сетевые ограничения. Некоторые VPS-провайдеры блокируют исходящий порт 25, чтобы предотвратить спам с новых серверов.

Порт 25 обычно используется для доставки почты между SMTP-серверами. Если он заблокирован, собственный почтовый сервер может не отправлять письма напрямую другим почтовым системам.

Для отправки через внешний SMTP-сервис чаще используют порты 587 или 465. Они предназначены для авторизованной отправки и обычно подходят для сайтов, приложений и почтовых клиентов.

Перед настройкой собственного SMTP нужно проверить:

Разрешает ли провайдер исходящий порт 25;
Можно ли настроить PTR для IP;
Не находится ли IP в blacklist;
Не использовался ли IP раньше для спама;
Есть ли лимиты на отправку;
Открыты ли нужные порты в firewall.

Репутация IP особенно важна для нового VPS. Даже если SMTP, SPF, DKIM, DMARC и PTR настроены правильно, новый или подозрительный IP может вызывать недоверие у крупных почтовых сервисов и антиспам-систем.

Поэтому для важных писем — регистраций, заказов, заявок, платежей и восстановления пароля — часто разумнее использовать внешний SMTP-сервис. А если всё-таки нужен собственный почтовый сервер, начинать стоит с минимального набора DNS-записей и аккуратной проверки доставки.

Минимальный набор DNS-записей для почты

MX: куда принимать письма

MX-запись отвечает за входящую почту. Она говорит другим почтовым серверам, куда доставлять письма для домена.

Если почта должна работать для адресов вида info@example.com, в DNS-зоне домена example.com должна быть MX-запись.

Пример: example.com. MX 10 mail.example.com.

В принципе одной MX-записи достаточно, но во избежание проблем при диагностике и при сомнительной работе ряда систем желательно настроить, чтобы имя mail.example.com тоже указывало на IP-адрес почтового сервера. Для этого пригодится запись типа А: mail.example.com. A 203.0.113.10

Число 10 — это приоритет MX-записи. Чем меньше число, тем выше приоритет. Если почтовых серверов несколько, принимающая сторона сначала попробует сервер с меньшим приоритетом.

Для одного VPS обычно достаточно одной MX-записи. Но важно, чтобы она указывала на реальный почтовый хост, а не просто на основной домен сайта без настроенного mail-сервера.

Когда входящая почта знает, куда идти, нужно отдельно объяснить принимающим серверам, кто имеет право отправлять письма от имени домена. Для этого используется SPF.

SPF: кто имеет право отправлять письма

SPF-запись показывает, какие серверы могут отправлять письма от имени домена. Это TXT-запись в DNS.

Если письма отправляются с VPS, SPF должен разрешать IP-адрес этого VPS: example.com. TXT "v=spf1 ip4:203.0.113.10 -all"

В такой записи домен говорит: письма от example.com разрешено отправлять с IP 203.0.113.10, а остальные источники не должны считаться разрешёнными.

Если используется внешний SMTP-сервис, SPF обычно выглядит иначе. Часто сервис даёт готовую include-запись, которую нужно добавить в DNS.

Пример условной записи: example.com. TXT "v=spf1 include:spf.smtp-provider.example -all"

Если письма отправляются и с VPS, и через внешний SMTP-сервис, оба источника нужно учесть в одной SPF-записи: example.com. TXT "v=spf1 ip4:203.0.113.10 include:spf.smtp-provider.example -all"

Помимо IP, можно использовать и имена, или даже просто модификаторы, например а будет означать адреса А-записей домена, MX - соответственно MX, и так далее. Также можно использовать знаки для того, чтоб сервер получателя понимал что делать с письмами. "-" это отклонять, "~" - принимать, но помечать (softfail), "?" - отсутствие политики и "+" - пропускать (можно не указывать).

То есть запись в примере выше говорит о том, что мы разрешаем получение писем с IP-адреса, добавляем записи сервиса отправки, и запрещаем всё остальное (-all).

Частая ошибка — создать несколько SPF-записей для одного домена. Так делать не нужно. SPF должен быть одной TXT-записью, внутри которой перечислены все разрешённые источники.

Но SPF проверяет только право сервера отправлять письмо. Он не защищает содержимое письма от изменений по пути. Для этого нужен DKIM.

DKIM: как подписывать исходящие письма

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

Обычно DKIM-запись выглядит как TXT-запись для специального поддомена. Имя зависит от селектора. Например, если селектор называется default, запись может быть такой: default._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=PUBLIC_KEY"

Где PUBLIC_KEY — это длинный публичный ключ, который выдаёт почтовый сервер, панель управления или внешний SMTP-сервис.

Если DKIM настроен правильно, исходящие письма получают заголовок DKIM-Signature. Принимающий сервер проверяет подпись и понимает, что письмо действительно связано с доменом и не было изменено после отправки.

Частая ошибка — добавить DKIM-запись в DNS, но не включить подпись на самом SMTP-сервере. В таком случае публичный ключ есть, но письма не подписываются.

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

SPF и DKIM помогают подтвердить отправителя. Но домену ещё нужно указать, что делать с письмами, которые эти проверки не проходят. Для этого используется DMARC.

DMARC: что делать с письмами, которые не прошли проверку

DMARC — это TXT-запись, которая задаёт политику для писем, не прошедших SPF или DKIM.

На старте лучше использовать мягкий режим наблюдения: _dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Политика p=none не просит отклонять письма. Она нужна, чтобы посмотреть отчёты и понять, какие сервисы реально отправляют почту от имени домена.

После проверки можно перейти к более строгой политике: _dmarc.example.com. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

И только после тестов — к отклонению подозрительных писем: _dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

Слишком жёсткий DMARC без подготовки может сломать легитимную отправку. Например, сайт, CRM, helpdesk или внешний SMTP-сервис отправляют письма от имени домена, но SPF или DKIM для них не настроены. При p=reject такие письма могут начать отклоняться.

Поэтому DMARC лучше вводить постепенно: сначала none, затем анализ отчётов, исправление SPF и DKIM, потом quarantine или reject.

Но даже SPF, DKIM и DMARC не закрывают ещё один важный вопрос — как выглядит сам IP-адрес почтового сервера для внешнего мира.

PTR: обратная DNS-запись для IP

PTR-запись связывает IP-адрес с доменным именем. Для почтового сервера это важный сигнал доверия.

Если A-запись работает так: mail.example.com → 203.0.113.10

То PTR должен возвращать обратное соответствие: 203.0.113.10 → mail.example.com

Проверить PTR можно так: dig -x 203.0.113.10 +short

Или через host: host 203.0.113.10

PTR обычно настраивается не в DNS-зоне домена, а у владельца IP-адреса. Для VPS это чаще всего панель провайдера или обращение в поддержку.

Важно, чтобы PTR выглядел осмысленно. Для почтового сервера лучше использовать имя вроде mail.example.com, а не случайный технический hostname провайдера.

Также желательно, чтобы была согласованность:

mail.example.com → IP VPS

IP VPS → mail.example.com

При этом важно не столько соответствие IP VPS и имени, важно соответствие приветствия сервера отправителя. Когда сервер отправляет письмо и подключается к SMTP получателя, он передаёт ему приветствие (HELO\EHLO), содержащее его имя. И вот именно соответствие IP, с которого происходит соединение и этого имени наиболее важно.

Если PTR отсутствует или указывает на случайное имя, крупные почтовые системы могут хуже доверять письмам с такого сервера. В некоторых случаях письма будут чаще попадать в spam или отклоняться.

Минимальная DNS-настройка почты — это не одна запись, а связка: MX для входящей почты, SPF для разрешённых отправителей, DKIM для подписи, DMARC для политики и PTR для доверия к IP. После этого уже можно решать, стоит ли обслуживать почту на своём VPS или проще передать отправку внешнему SMTP-сервису.

Когда лучше использовать внешний SMTP-сервис

Транзакционные письма сайта

Если письма нужны сайту для регистрации, восстановления пароля, заявок, чеков, заказов и уведомлений, внешний SMTP-сервис часто удобнее собственного почтового сервера на VPS.

Транзакционные письма должны доходить быстро и стабильно. Пользователь ждёт код подтверждения, ссылку для сброса пароля или письмо о заказе, поэтому попадание в spam здесь особенно критично.

Внешний SMTP-сервис берёт на себя часть задач, которые сложно поддерживать вручную:

Репутацию отправляющих IP;
Логи доставки;
bounce-обработку;
Лимиты отправки;
Статистику открытий и ошибок;
Защиту от резких всплесков;
Рекомендации по SPF, DKIM и DMARC.

Сайт в этом случае не отправляет письма напрямую с VPS. Он подключается к SMTP-сервису по авторизованному соединению, обычно через порт 587 или 465, и передаёт письма ему.

Это особенно удобно для WordPress, интернет-магазинов, CRM, SaaS-проектов и личных кабинетов. VPS отвечает за сайт, а специализированный SMTP-сервис — за доставку писем.

Если транзакционные письма уже вынесены во внешний SMTP, следующий вопрос — что делать с массовыми уведомлениями и рассылками. Там требования ещё строже.

Рассылки и уведомления

Для массовых рассылок собственный SMTP на VPS обычно плохой вариант. Даже если технически сервер может отправить тысячу писем, это не значит, что почтовые системы примут такую активность нормально.

Массовая отправка быстро влияет на репутацию IP и домена. Если пользователи жалуются, письма часто удаляют без чтения или рассылка выглядит подозрительно, почта с такого домена и IP-адресов может начать хуже доставляться даже в обычных транзакционных письмах.

Для рассылок важны:

Управление подписками;
Отписка в один клик;
Контроль жалоб;
Обработка bounce;
Лимиты отправки;
Сегментация аудитории;
Статистика доставки;
Прогрев домена и IP;
Соблюдение антиспам-требований.

Внешние сервисы рассылок и SMTP-провайдеры лучше подходят для таких задач. Они дают инструменты, которых обычно нет на самодельном почтовом сервере и настройка которых требует специфических компетенций.

Также не стоит смешивать всё в одном потоке. Транзакционные письма и маркетинговые рассылки лучше разделять: разными поддоменами, разными потоками отправки или разными сервисами. Тогда проблемы с рассылкой не будут сразу вредить письмам восстановления пароля или заказам.

Даже если объём отправки небольшой, внешний SMTP часто снижает риски. Особенно когда VPS новый и у его IP ещё нет нормальной почтовой репутации.

Новый VPS без почтовой репутации

У нового VPS обычно нет истории отправки писем. Для сайта это может быть нормально, но для почтовых систем такой IP выглядит неизвестным.

Крупные почтовые сервисы оценивают не только SPF, DKIM и DMARC. Они смотрят на репутацию IP, домена, частоту отправки, жалобы пользователей, историю bounce и признаки спама.

Если новый VPS сразу начинает отправлять много писем, это может выглядеть подозрительно. Даже корректные DNS-записи не гарантируют попадание во входящие.

Проблема усиливается, если IP раньше уже использовался другим клиентом провайдера и успел попасть в blacklist. Новый владелец VPS может получить адрес с плохой историей и столкнуться с проблемами ещё до первой нормальной отправки.

Поэтому для нового проекта часто безопаснее начать с внешнего SMTP-сервиса. Он уже имеет инфраструктуру для отправки, мониторинг доставляемости и понятные требования к DNS-записям.

Собственный почтовый сервер на VPS лучше запускать тогда, когда есть время на прогрев, мониторинг, проверку blacklist, настройку PTR и разбор логов. Если таких ресурсов нет, внешний SMTP будет практичнее.

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

Когда провайдер блокирует исходящий SMTP

Некоторые VPS-провайдеры блокируют исходящий порт 25. Это делают для защиты от спама: новые серверы часто используют для массовой нежелательной рассылки, поэтому провайдеры ограничивают прямую отправку почты.

Если порт 25 заблокирован, собственный SMTP-сервер может принимать письма от сайта, но не сможет нормально доставлять их на внешние почтовые серверы.

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

Внешний SMTP-сервис в таком случае решает проблему. Сайт или приложение подключается к нему через порт 587 или 465, проходит авторизацию и отправляет письма через инфраструктуру провайдера SMTP.

Такой вариант особенно удобен, если VPS нужен прежде всего для сайта или приложения, а не для полноценного почтового сервера. Сервер остаётся проще, меньше рисков с blacklist и не нужно самостоятельно поддерживать всю почтовую инфраструктуру.

В итоге внешний SMTP стоит выбирать, когда важнее стабильная доставка, понятные логи и меньше ручного администрирования. Собственный почтовый сервер на VPS имеет смысл только тогда, когда действительно нужен контроль над почтой и есть готовность обслуживать DNS, PTR, DKIM, DMARC, очереди, репутацию IP и ошибки доставки.

Типовые ошибки при настройке почты на VPS

Нет PTR-записи

PTR-запись часто забывают, потому что она настраивается не там же, где обычные DNS-записи домена. A, MX, SPF, DKIM и DMARC обычно добавляют в DNS-зоне домена, а PTR настраивается у владельца IP-адреса — то есть у VPS-провайдера.

Для почтового сервера это критично. Принимающие серверы хотят видеть, что IP отправителя связан с нормальным доменным именем, а не выглядит как случайный адрес из пула хостинга.

Проверить PTR можно так: dig -x 203.0.113.10 +short

В нормальной ситуации IP должен возвращать понятное имя, например: mail.example.com.

И желательно, чтобы была обратная согласованность:

mail.example.com → 203.0.113.10

203.0.113.10 → mail.example.com

Также почтовый сервер должен быть настроен так, чтобы это же имя - в нашем случае mail.example.com - выставлять в приветствие SMTP-сессии.

Если PTR нет или он указывает на техническое имя провайдера, письма могут чаще попадать в spam или отклоняться. Исправлять это нужно через панель VPS-провайдера или обращение в поддержку.

Когда PTR настроен, следующая частая зона ошибок — SPF. Там проблема обычно не в отсутствии записи, а в том, что она разрешает не тот источник отправки.

SPF разрешает не тот сервер

SPF должен перечислять все серверы, которые имеют право отправлять письма от имени домена. Если письмо уходит с VPS, но SPF разрешает только внешний SMTP-сервис, проверка может не пройти.

И наоборот: если сайт отправляет письма через внешний SMTP, но SPF разрешает только IP VPS, принимающая сторона увидит несоответствие.

Пример SPF для отправки с VPS: v=spf1 ip4:203.0.113.10 -all

Пример SPF для внешнего SMTP-сервиса: v=spf1 include:spf.smtp-provider.example -all

Если используются оба источника, их нужно объединить в одну SPF-запись: v=spf1 ip4:203.0.113.10 include:spf.smtp-provider.example -all

Частая ошибка — добавить две разные SPF-записи для одного домена. Так делать нельзя: SPF должен быть одной TXT-записью, где перечислены все разрешённые источники.

Проверить SPF можно через DNS: dig TXT example.com +short

Если SPF настроен неправильно, письма могут уходить с сервера, но приниматься с пометкой SPF fail или попадать в spam.

Но даже правильный SPF не гарантирует доверие к письму. Для нормальной доменной почты важно, чтобы исходящие сообщения ещё и подписывались DKIM.

DKIM не подписывает письма

DKIM часто настраивают формально: добавляют TXT-запись в DNS и считают задачу закрытой. Но наличие DNS-записи ещё не значит, что письма действительно подписываются.

Чтобы DKIM работал, должны совпасть две части:

SMTP-сервер подписывает исходящие письма приватным ключом;
в DNS опубликован публичный ключ для нужного селектора.

Проверить DKIM-запись можно так: dig TXT default._domainkey.example.com +short

Где default — это селектор. В реальной настройке он может называться иначе: mail, dkim, selector1, s1 или как указал почтовый сервис.

Если запись есть, но письма не получают заголовок DKIM-Signature, значит подпись не включена на стороне SMTP-сервера или приложения.

Если заголовок есть, но проверка DKIM не проходит, возможны другие причины:

В DNS опубликован не тот ключ;
Используется другой селектор;
Письмо изменяется после подписи;
Внешний SMTP подписывает другим доменом;
Запись DKIM добавлена с ошибкой или обрезана.

Проверять результат удобно по заголовкам полученного письма. В Gmail, например, можно открыть “Показать оригинал” и посмотреть, прошли ли SPF, DKIM и DMARC.

Когда SPF и DKIM работают, можно переходить к DMARC. Но здесь важно не включать жёсткую политику слишком рано.

DMARC стоит слишком жёстко без тестов

DMARC помогает защитить домен от подделки писем, но при неправильном включении может сломать легитимную отправку.

Самая рискованная ситуация — сразу поставить строгую политику: v=DMARC1; p=reject; rua=mailto:dmarc@example.com

Если к этому моменту не проверены все источники отправки, часть нормальных писем может начать отклоняться. Например, письма с сайта, CRM, helpdesk, внешнего SMTP или сервиса рассылок могут не проходить SPF или DKIM.

На старте безопаснее использовать режим наблюдения: v=DMARC1; p=none; rua=mailto:dmarc@example.com

Так домен получает отчёты, но не просит принимающие серверы отклонять письма.

После анализа отчётов и исправления SPF/DKIM можно перейти к более строгой политике: v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com

И только после тестов — к p=reject.

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

Но даже идеальные DNS-записи не спасают, если у IP уже плохая репутация. Поэтому следующий слой проверки — blacklist.

Сервер попал в blacklist

Blacklist — это список IP-адресов или доменов, которые подозреваются в спаме, вредоносной активности или массовой нежелательной рассылке.

Если IP VPS попал в такой список, письма могут хуже доставляться даже при правильных SPF, DKIM, DMARC и PTR.

Причины могут быть разные:

IP раньше использовался для спама другим клиентом;
Сервер взломали и с него отправляли письма;
Приложение рассылает слишком много уведомлений;
Нет лимитов отправки;
Пользователи жалуются на письма;
Рассылки отправляются без согласия и отписки.

Проверять blacklist лучше через несколько публичных сервисов проверки репутации IP. Также полезно смотреть логи почтового сервера: там могут быть ответы принимающих серверов с кодами ошибок и ссылками на конкретный blacklist.

Если сервер попал в blacklist, недостаточно просто подать заявку на удаление. Сначала нужно устранить причину: закрыть открытую отправку, проверить учётные записи, поменять пароли, ограничить relay, остановить подозрительную рассылку и убедиться, что сервер не взломан.

После этого можно разбираться с delisting. Но для важных писем в такой ситуации часто быстрее временно перейти на внешний SMTP-сервис, чтобы не терять регистрации, заказы и заявки.

Иногда же проблема даже не в репутации, а в том, что письма вообще не могут уйти с VPS из-за блокировки исходящего SMTP.

Исходящий порт заблокирован

Некоторые VPS-провайдеры блокируют исходящий порт 25. Это распространённая мера против спама, особенно на новых серверах и дешёвых тарифах.

Порт 25 нужен для доставки писем между почтовыми серверами. Если он заблокирован, собственный SMTP может принимать письмо от сайта, но не сможет отправить его дальше на Gmail, Outlook или другой внешний почтовый сервер.

Симптомы могут выглядеть так:

Письма зависают в очереди;
В логах видны таймауты подключения;
Отправка на внешние домены не проходит;
Локальная отправка работает, а внешняя — нет;
Почтовый сервер повторяет попытки доставки.

Проверять нужно логи почтового сервера и сетевую доступность внешних SMTP-серверов. Если провайдер блокирует порт 25, иногда его можно открыть по запросу в поддержку. Но не все провайдеры это разрешают.

Для сайтов и приложений часто проще использовать внешний SMTP через порт 587 или 465. В этом случае VPS не доставляет письма напрямую между почтовыми серверами, а авторизуется у SMTP-провайдера и передаёт письма через него.

Если исходящий порт заблокирован, не стоит бесконечно править SPF, DKIM или DMARC. Эти записи важны, но они не откроют сетевую отправку. Сначала нужно понять, может ли VPS вообще отправлять почту наружу, а уже потом настраивать доставляемость.

В итоге большинство проблем с почтой на VPS сводится к одному: отправка должна быть не только технически возможной, но и доверенной. Для этого нужны правильные DNS-записи, PTR, рабочая DKIM-подпись, аккуратный DMARC, чистая репутация IP и открытый путь для исходящей почты.

Что проверить после настройки почты

После настройки почты на VPS нужно проверить не только создание ящика или успешную отправку тестового письма. Письмо может уйти с сервера, но попасть в spam, не пройти DKIM, отправиться с неправильного IP или зависнуть в очереди.

Сначала проверьте DNS-записи домена:

dig MX example.com +short

dig TXT example.com +short

dig TXT _dmarc.example.com +short

Если используется DKIM, проверьте запись с нужным селектором: dig TXT default._domainkey.example.com +short

Селектор может отличаться. Его нужно смотреть в настройках почтового сервера, панели управления или внешнего SMTP-сервиса.

Затем проверьте PTR для IP-адреса VPS: dig -x 203.0.113.10 +short

Желательно, чтобы PTR возвращал понятное имя почтового сервера, например mail.example.com, а это имя указывало обратно на IP VPS.

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

Хорошей идеей будет воспользоваться специальными сервисами, куда можно отправить тестовое письмо и получить оценку с комментариями и всеми проверками.

В полученном письме проверьте заголовки. Нужно убедиться, что SPF, DKIM и DMARC проходят проверку. В Gmail это можно посмотреть через пункт “Показать оригинал”.

Также стоит проверить:

Попало ли письмо во входящие или в spam;
Какой IP указан как отправитель;
Совпадает ли домен отправителя с SPF/DKIM/DMARC;
Подписывается ли письмо DKIM;
Не ломается ли отправка с сайта, CMS, CRM или приложения;
Не зависают ли письма в очереди;
Нет ли ошибок в логах почтового сервера;
Не находится ли IP в blacklist;
Открыт ли исходящий SMTP, если используется собственный сервер.

Если почта используется для сайта, отдельно проверьте все важные сценарии: регистрацию, восстановление пароля, формы заявок, уведомления о заказах, оплату, системные письма и ответы клиентам.

Для внешнего SMTP-сервиса нужно убедиться, что сайт или приложение отправляет письма именно через него, а не через локальный sendmail или встроенную функцию PHP mail() без нормальной аутентификации и подписей.

После проверки полезно зафиксировать рабочую схему: какие DNS-записи используются, какой SMTP отвечает за отправку, где настроен DKIM, какая политика DMARC включена, кто управляет PTR и как смотреть логи доставки.

Заключение

Почта на VPS — это не только SMTP-сервер и почтовый ящик. Для нормальной доставки нужна связка домена, DNS-записей, IP-адреса, PTR, SPF, DKIM, DMARC, открытых портов и репутации отправителя.

Если хотя бы один элемент настроен неправильно, письма могут уходить с сервера, но попадать в spam, отклоняться принимающей стороной или вообще не доставляться из-за сетевых ограничений.

Минимальная настройка доменной почты включает MX для входящих писем, SPF для разрешённых отправителей, DKIM для подписи сообщений, DMARC для политики проверки и PTR для обратной DNS-записи IP-адреса.

Но собственный почтовый сервер на VPS нужен не всегда. Для транзакционных писем сайта, уведомлений, заявок, чеков, восстановления пароля и рассылок часто практичнее использовать внешний SMTP-сервис. Он снижает нагрузку на администратора и помогает с доставляемостью, логами и репутацией отправляющих IP.

Собственная почта на VPS имеет смысл, если нужен полный контроль и есть готовность обслуживать сервер: следить за логами, очередью, blacklist, безопасностью, обновлениями, DNS и политиками домена.

Правильный подход — сначала выбрать модель отправки: собственный SMTP или внешний сервис. Затем настроить DNS, проверить SPF/DKIM/DMARC/PTR, отправить тестовые письма, посмотреть заголовки и убедиться, что важные сообщения доходят не просто “куда-то”, а именно во входящие.

FAQ

Можно ли настроить почту на VPS самостоятельно?

Да, можно. На VPS можно поднять собственный почтовый сервер, настроить домен, MX, SMTP, SPF, DKIM, DMARC, PTR, TLS, почтовые ящики и отправку писем.

Но почта на VPS требует постоянного обслуживания. Нужно следить за логами, очередью писем, обновлениями, безопасностью, репутацией IP, blacklist и корректностью DNS-записей.

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

Что важнее для доставки: SPF, DKIM, DMARC или PTR?

Лучше воспринимать их не как конкурентов, а как связку.

SPF показывает, какие серверы имеют право отправлять письма от имени домена. DKIM подписывает письмо и помогает подтвердить, что оно не было изменено. DMARC задаёт политику для писем, которые не прошли SPF или DKIM. PTR связывает IP-адрес отправителя с доменным именем и помогает принимающей стороне оценить сервер.

Cloudflare описывает SPF, DKIM и DMARC как три метода email-аутентификации, которые вместе помогают защищать домен от подделки отправителя.

Для VPS особенно важен ещё и PTR, потому что многие почтовые системы хуже доверяют серверам без нормальной обратной DNS-записи.

Почему письма с VPS попадают в spam?

Причин может быть много. Самые частые — нет PTR-записи, неправильно настроен SPF, письма не подписываются DKIM, DMARC настроен некорректно, IP уже был в blacklist или у нового сервера нет почтовой репутации.

Также влияет содержание письма: подозрительные ссылки, вложения, сокращатели URL, слишком частая отправка, жалобы пользователей и отсутствие нормальной отписки для рассылок.

Gmail в рекомендациях для отправителей указывает, что домен должен проходить SPF или DKIM, а для прохождения DMARC письмо должно быть аутентифицировано SPF или DKIM с совпадением домена в заголовке From.

Поэтому проверять нужно не только факт отправки, но и заголовки полученного письма: прошли ли SPF, DKIM и DMARC, какой IP использовался и куда попало письмо.

Можно ли отправлять почту без PTR-записи?

Технически можно, но для собственного почтового сервера на VPS это плохая идея. Без PTR письма чаще вызывают недоверие у принимающих серверов, особенно если отправка идёт напрямую с IP VPS. Как минимум, при отсутствии PTR, стоит корректно настроить SPF, DKIM и DMARC.

PTR настраивается у владельца IP-адреса, то есть обычно в панели VPS-провайдера или через поддержку. Для почтового сервера лучше, чтобы IP возвращал понятное имя вроде mail.example.com, а это имя указывало обратно на IP.

Если провайдер не даёт настроить PTR, для важных писем лучше использовать внешний SMTP-сервис.

Чем SMTP-сервер отличается от внешнего SMTP-сервиса?

SMTP-сервер — это сервер, через который отправляются письма. Его можно поднять на своём VPS и обслуживать самостоятельно.

Внешний SMTP-сервис — это готовая инфраструктура для отправки писем. Сайт или приложение подключается к нему по логину и паролю или API, передаёт письмо, а сервис занимается доставкой, логами, репутацией IP, bounce-обработкой и лимитами.

Собственный SMTP даёт больше контроля, но требует администрирования. Внешний SMTP обычно удобнее для транзакционных писем: регистрации, восстановления пароля, заявок, чеков, уведомлений и заказов.

Какой DMARC поставить на старте?

На старте лучше использовать мягкую политику наблюдения: v=DMARC1; p=none; rua=mailto:dmarc@example.com

Такая запись не просит принимающие серверы отклонять письма, но позволяет собирать отчёты и понять, какие сервисы отправляют почту от имени домена.

Google Workspace Help также описывает DMARC как механизм, который говорит принимающим серверам, что делать с письмами, не прошедшими SPF или DKIM.

После проверки SPF, DKIM, сайта, CRM, внешнего SMTP и рассылок можно постепенно переходить к p=quarantine, а затем к p=reject.

Нужно ли настраивать DKIM для писем с сайта?

Да, если сайт отправляет письма от имени домена. DKIM помогает принимающим серверам понять, что письмо связано с доменом и не было изменено после отправки.

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

Если сайт отправляет письма через собственный сервер на VPS, DKIM нужно настроить на стороне почтового сервера. Просто добавить DNS-запись недостаточно: письма должны реально получать заголовок DKIM-Signature.

Без DKIM письма могут доставляться хуже, а DMARC будет сложнее настроить безопасно.

Список источников

1. Cloudflare — What are DMARC, DKIM, and SPF?

2. Gmail Help — Email sender guidelines

3. Google Workspace Help — Set up DMARC

4. DMARC.org — Specifications: SPF, DKIM, DMARC