Ответы на комментарии к статье «Как мы с внуком подняли свой сервер вместо Gmail в деревне»
Своя почта против Gmail: ответы на вопросы из комментариев
Во второй части разбираю практические вопросы к «деревенскому» почтовому серверу: от «SMTP нонейма» и спама до 25‑го порта, динамических IP и смысла собственного сервера для обычного пользователя.
В первой статье я описал, как для семьи завёл почту на своём домене и VPS‑сервере вместо привычного Gmail, используя образ «деда из деревни» и его внука для объяснения базовых вещей простым языком. В комментариях закономерно появилась масса уточнений и возражений — от «гугл вообще не примет письмо с SMTP нонейма» до споров о том, где сегодня живёт «адекватный» бизнес: на своих серверах или у крупных почтовых провайдеров.
В этом тексте я отвечаю на самые частые вопросы из той ветки и сознательно убираю художественную часть: ниже в основном практика, с опорой на конфигурацию моего небольшого сервера и типовые сценарии. Цель — не доказать, что «свой сервер лучше Gmail», а честно показать, что происходит с письмами от маленького домена, какие ограничения есть у «самодельной» почты и в каких случаях такой подход вообще имеет смысл.
1. Что происходит с письмом от «SMTP нонейма»
Принимают ли его вообще и почему оно часто оказывается в спаме
В комментариях прозвучали полярные оценки поведения крупных почтовых сервисов: одни уверены, что «они просто не примут письмо с нонейм‑SMTP», другие приводят примеры, когда письма принимаются даже без PTR‑записи, но стабильно попадают в спам. На практике возможны оба сценария: часть провайдеров режет соединение ещё на уровне SMTP, другие письмо принимают, но сразу помечают как подозрительное и отправляют в папку «Спам».
На то, будет ли письмо вообще принято и где оно окажется, влияет несколько факторов:
MX‑ и A‑записи домена;
наличие и корректность SPF, DKIM, DMARC;
обратная PTR‑запись (reverse DNS);
репутация IP‑адреса и домена;
поведение отправителя (объёмы, содержимое, жалобы пользователей).
В моём случае стартовая конфигурация с базовым набором DNS‑записей приводила к тому, что тестовые письма до крупных сервисов доходили, но нередко оказывались в спаме. После включения DKIM, добавления DMARC и аккуратной отправки небольших, «не спам» писем они начали чаще попадать во «Входящие», что типично для малых доменов без массовых рассылок.
2. Свой сервер против крупного провайдера: где это вообще оправдано
В обсуждении столкнулись две крайности:
«Почти весь бизнес уже у крупных почтовых провайдеров».
«Весь адекватный бизнес уходит на свои сервера, чтобы не ловить утечки».
В реальности компании живут по обе стороны этой границы: одни полностью сидят на корпоративной почтовой платформе большого вендора, другие держат почту на собственных серверах или в гибридных схемах из‑за требований по конфиденциальности и плотной интеграции с внутренними системами.
Крупные сервисы дают:
готовую инфраструктуру и SLA;
фильтрацию спама и антивирус;
регулярные обновления и мониторинг.
Но взамен требуют:
доверить им хранение и обработку переписки;
работать по их правилам (политика спама, лимиты, формальные требования к отправителю).
Собственный сервер, наоборот, даёт максимум контроля, но:
ответственность за отказоустойчивость, бэкапы и безопасность ложится на администратора;
нужно заниматься репутацией IP‑адреса;
важны своевременные обновления и закрытие уязвимостей (почта — популярная цель атак).
В моём проекте мотивация была не «увести корпоративную почту из облака», а отработать реальный сценарий небольшой семейной почты и получить живой стенд: посмотреть, как маленький доменный сервер ведёт себя в мире крупных провайдеров, какие проверки проходит и где начинаются ограничения. Для большинства малых компаний и частных пользователей задача «просто рабочий почтовый ящик» действительно дешевле и спокойнее решается через готовый почтовый хостинг или облачный сервис. Свой сервер имеет смысл там, где есть повышенные требования к контролю за данными или ресурсы и интерес поддерживать эту инфраструктуру собственными силами.
3. Домашний сервер, 25‑й порт и динамический IP: что реально мешает
Отдельная линия обсуждения касалась вопроса: почему я не повесил почтовый сервер прямо дома и почему считаю это рискованным с точки зрения доставки. Классические проблемы домашнего сервера:
исходящий трафик на порт 25 часто блокируется провайдерами;
выдаются динамические IP‑адреса, которые по умолчанию считаются недоверенными;
часть принимающих серверов отклоняет письма из известных динамических диапазонов или без PTR‑записи.
При этом справедливо напоминают, что нормальный MTA не теряет письмо при первом сбое: он кладёт сообщения в очередь и повторяет попытки доставки в течение заданного времени, с увеличением интервалов между попытками.
На примере Postfix логика примерно такая:
queue_run_delay — как часто обрабатывается отложенная очередь;
minimal_backoff_time — минимальная пауза перед повторной попыткой;
maximal_backoff_time — максимальная пауза между попытками;
maximal_queue_lifetime — сколько письмо живёт в очереди, прежде чем вернуться отправителю.
То есть кратковременное отключение интернета или света — не гарантированная потеря писем. Но чем менее предсказуемы электричество и связь, тем больше риск того, что в какой‑то момент окно повторных попыток не совпадёт с «живым» состоянием сервера.
Разница между домашним сервером и VPS в моём случае в том, что для VPS стабильность питания, канала и статического IP — норма, а для деревенского дома с периодическими отключениями электричества и мобильного интернета это уже не гарантируется. Поэтому выбранная схема:
основной сервер на VPS — туда приходит и оттуда отправляется внешняя почта;
домашняя машина — лаборатория, бэкапы и эксперименты, которые не ломают внешний контур.
4. Почему облака блокируют 25‑й порт и что с этим делать
В комментариях был пример: «пойдите расскажите про “платим за открытый порт” крупным облачным провайдерам — там 25‑й закрыт без разговоров». Такая политика действительно типична: исходящий трафик на 25‑й порт по умолчанию блокируется для виртуальных машин и похожих сервисов, чтобы:
не допустить массовый спам из облака;
не портить репутацию их IP‑пулов в глазах других почтовых систем.
Типовые сценарии работы с почтой в таком облаке выглядят так:
использование внешних почтовых провайдеров — сервер в облаке подключается к ним по 587/2525, а не по 25;
использование собственного сервера только как клиента (SMTP‑relay наружу, а не полноценный MTA для всего мира);
подача заявки в поддержку на снятие ограничения с 25‑го порта с описанием сценария и готовностью выполнять их требования.
Для небольшого «самостоятельного» отправителя, который хочет полный контроль над SMTP с нуля, эта модель бывает неудобна: проще взять VPS‑хостинг, где 25‑й порт открывается по договорённости, а не по исключению.
5. Почему не почтовый хостинг с доменом
Логичный вопрос: если основная почта всё равно живёт на VPS в дата‑центре, почему не взять готовый почтовый хостинг, привязать к нему домен и не заниматься тонкой настройкой сервера вообще.
Почтовый хостинг обычно даёт:
готовый веб‑интерфейс и IMAP/SMTP;
антиспам и антивирус «из коробки»;
регулярные обновления, мониторинг и бэкапы;
работу с репутацией IP на своей стороне.
И оставляет администратору только:
управление доменом (A/MX/…);
создание ящиков и общие политики.
В рамках этого проекта задача другая: использовать живой домен и сервер как учебную площадку, на которой можно руками пройти все шаги — от A/MX‑записей до DKIM/DMARC, посмотреть, как меняется отношение крупных провайдеров к письмам от домена по мере улучшения конфигурации, и показать этот путь читателям. Почтовый хостинг отлично решает задачу «просто работать и не думать», но почти полностью прячет технические детали; здесь же важно было именно столкнуться с ними — от первых писем в спаме до более‑менее предсказуемых «Входящих» — и понимать, за счёт чего происходят эти изменения.
6. Мини‑FAQ по репликам из комментариев
«MX не обязателен, если есть A‑запись»
Стандарт допускает сценарий, когда у домена нет MX‑записей, и тогда отправляющий сервер может попытаться доставить почту на A‑запись домена, рассматривая её как почтовый хост. Но на практике корректно настроенный MX считают базовым элементом почтовой инфраструктуры:
MX явно указывает серверы, отвечающие за приём почты;
через MX можно задать приоритеты и резервные хосты;
корректный MX снижает риск странных маршрутов и неоднозначной трактовки.
Для небольшого домена с одним сервером прописать MX несложно, и логично считать это нормой, а не опцией «по желанию».
«Платит за DKIM» и откуда берётся такой образ
Ремарка про «предприятие платит за DKIM» отражает реальность старых стеков, где поддержка современных технологий могла требовать платных модулей или обновлений (как у некоторых устаревших версий корпоративных серверов). Если разложить по слоям:
DKIM как стандарт — открытый протокол, спецификация доступна всем;
современный open‑source‑стек (Postfix, Dovecot и т.п.) реализует DKIM через свободные компоненты и TXT‑записи в DNS;
«платим за DKIM» в реальности означает: платим за обновление/поддержку устаревшей платформы, а не за право использовать сам протокол.
То есть проблема не в DKIM как таковом, а в том, что кто‑то до сих пор живёт на очень старом ПО, где любая новая возможность стоит денег.
Exchange 2003 в 2026 году
Вопрос «кто в здравом уме в 2026 использует Exchange 2003» возникает не на пустом месте: официальная поддержка таких версий давно завершена, а эксплуатация их как фронтовых почтовых серверов создаёт повышенные риски из‑за накопленных уязвимостей. Почтовые серверы — лакомая цель для атак, поэтому старые, не обновляемые системы оказываются особенно уязвимыми.
Если подобные системы всё ещё используются, разумные пути:
плановая миграция на более современные решения;
вынос внешнего контура (приём/отправка из интернета) на отдельные, актуальные узлы, чтобы старый сервер не торчал напрямую в сеть.
«Онлайн‑сервисы проверки почтового сервера» и DNSBL: насколько они реально помогают
Онлайн‑сервисы проверки почтового сервера полезны как быстрый диагностический инструмент. Они показывают:
есть ли ошибки в SPF/DKIM/DMARC;
корректны ли MX‑записи;
нет ли проблем с TLS/сертификатами;
числится ли IP в популярных DNSBL‑списках.
Но важно понимать их границы:
сервис только указывает на проблему;
администратор решает её, меняя конфигурацию и поведение сервера;
«выписка» из чёрных списков — отдельный процесс, который может занимать время и не всегда успешен.
Для небольшого семейного сервера такие сервисы — полезный индикатор, но основу репутации всё равно составляют:
отсутствие спама и сомнительных рассылок;
умеренные объёмы отправки;
корректные DNS‑записи и аккуратная конфигурация сервера.
7. Технический блок: конфигурация в разрезе
VPS и базовое ПО
Платформа: VPS.
Ресурсы:
1–2 vCPU;
2–4 ГБ RAM;
40–60 ГБ SSD.
ОС: Linux на базе Debian.
Почтовое ПО: готовый «комбайн», который включает:
MTA (на базе Postfix или аналогичного);
IMAP/POP3‑сервер (типичный вариант — Dovecot);
веб‑интерфейс для пользователя и администрирования;
антиспам/антивирусные модули.
Упрощённо поток выглядит так:
textИнтернет → MX-сервер на VPS → почтовые ящики домена
→ IMAP/SMTP → почтовые клиенты и веб-интерфейсИнтернет → MX-сервер на VPS → почтовые ящики домена → IMAP/SMTP → почтовые клиенты и веб-интерфейс
DNS‑записи домена
Минимальный набор настроек:
A — указывает на IP‑адрес VPS;
MX — говорит, на какой хост доставлять почту для домена;
SPF (TXT) — перечисляет источники, с которых разрешено отправлять почту от имени домена;
DKIM (TXT) — публикует открытый ключ для проверки подписи исходящих писем;
DMARC (TXT) — задаёт политику обработки «подозрительных» писем и адрес для отчётов.
Логика прохождения письма:
textОтправка письма →
принимающий сервер смотрит MX →
проверяет SPF / DKIM →
применяет политику DMARC →
принимает / помечает / отклоняет.Отправка письма → принимающий сервер смотрит MX → проверяет SPF / DKIM → применяет политику DMARC → принимает / помечает / отклоняет.
Пример минимального набора (схематично, без реальных имён):
textexample.ru. IN A 203.0.113.10
example.ru. IN MX 10 mail.example.ru.
example.ru. IN TXT "v=spf1 mx -all"
default._domainkey.example.ru. IN TXT "v=DKIM1; k=rsa; p=ПУБЛИЧНЫЙ_КЛЮЧ"
_dmarc.example.ru. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.ru"example.ru. IN A 203.0.113.10 example.ru. IN MX 10 mail.example.ru. example.ru. IN TXT "v=spf1 mx -all" default._domainkey.example.ru. IN TXT "v=DKIM1; k=rsa; p=ПУБЛИЧНЫЙ_КЛЮЧ" _dmarc.example.ru. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.ru"
Очереди доставки и устойчивость
На стороне MTA (например, Postfix) важны параметры, влияющие на устойчивость к сбоям:
queue_run_delay — период обработки отложенной очереди писем;
minimal_backoff_time — минимальная пауза до следующей попытки доставки;
maximal_backoff_time — максимальная пауза между повторными попытками;
maximal_queue_lifetime — максимальное время жизни письма в очереди до возврата отправителю.
Именно это позволяет серверу не «ронять» письма при кратковременных сбоях связи, а аккуратно пытаться доставить их позднее.