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

Это, разумеется, не первая публикация на Хабре на эту тему. Тем не менее, я хочу поднять ее снова и поделиться личным опытом: рассказать, как я настраивала собственную почту, показать этот процесс от начала и до конца. Одна из моих целей — максимальная прозрачность, чтобы любой человек, следуя шаг за шагом, смог повторить всё описанное здесь и получить рабочий результат.

Перед тем как мы начнём, стоит ответить на вопрос: «А зачем вообще нужна своя почта?» Ведь у нас уже есть крупные почтовые сервисы вроде Gmail, Yandex, Mail.ru — они бесплатные, привычные, надёжные. Более того, в 2025 году почта многим вообще кажется анахронизмом. Кто ей пользуется? Кто читает письма?

И вот тут становится интересно. Если честно, у меня не так уж много аргументов, чтобы вас убедить. Когда‑то e‑mail был основным каналом связи, и люди ждали прихода нового письма. Сегодня же почти всё общение переместилось в мессенджеры — Telegram, WhatsApp, соцсети. Электронную почту массово захлестнул спам и маркетинговые рассылки. Казалось бы — всё, пора прощаться. Но... нет.

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

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

Третья причина — самопрезентация. В адресе vasya@pupkin.space уже звучит индивидуальность. Это не просто красивая обёртка, а сигнал: «Я знаю, как всё это устроено». Отличный способ выделиться, особенно если вы специалист в сфере IT.

И наконец — любопытство. Мне лично было чертовски интересно. Разобраться, настроить, увидеть, как летит первое письмо — от меня самой, на мой домен. Это настоящее инженерное удовольствие.

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

Приступим!

Подготовка

Что нужно, чтобы сделать свою электронную почту?

Для начала посмотрим, как вообще устроена обычная электронная почта. Вот, например, адрес: vasya_pupkin@mail.ru. Вначале идёт никнейм (выбранное имя), затем символ @, а после — домен mail.ru.

mail.ru — это домен, за которым стоит чужой почтовый сервер. Нам же хочется уйти от зависимости от чужих сервисов (Mail.ru, Gmail, Yandex и др.) и настроить всё под себя. Для этого нужно зарегистрировать собственный домен в глобальной системе доменных имён.

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

Допустим, вы зарегистрировали домен. Теперь у вас есть, скажем, pupkin.space, и в перспективе ваша электронная почта будет выглядеть, например, так: vasya@pupkin.space.

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

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

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

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

После того как вы арендовали домен и VPS, у вас на руках должно быть две основные вещи:

  • Доменное имя — например, pupkin.space, только ваше и в той зоне, которую вы выбрали (.com, .org, .ru и т.д.).

  • Виртуальный сервер — машина с установленной Linux-системой (например, Ubuntu 20.04) и статическим белым IP-адресом. В этой статье мы будем использовать для примера IP 123.123.123.123.

Далее следует полная инструкция с пояснениями по настройке DNS и SMTP серверов. В ней pupkin.space нужно заменить на ваш домен, а IP-адрес 123.123.123.123 — на ваш белый IP от хостера.

Bind9 (DNS-сервер)

Перед тем как приступить к настройке, разберёмся, зачем вообще нужен DNS‑сервер и как он связан с доменом.

В интернете существует иерархия доменных имён. На самом верху — корневой домен (обозначается как .), от него идут домены верхнего уровня (TLD): .com, .net, .ru и т. д. Ниже располагаются домены второго уровня, например google.com. или mail.ru., затем — третьего уровня и так далее.

Каждый уровень иерархии обслуживается DNS‑серверами — это распределённая система, в которую входят:

  • авторитетные (primary/secondary) DNS‑серверы, которые хранят полную информацию о конкретной зоне

  • кэширующие (резолверы) — они запоминают ответы, чтобы ускорить последующие запросы

Когда, например, вы отправляете письмо на адрес в чужом домене, например, с mail.ru на gmail.com, ваша система должна определить IP‑адрес почтового сервера получателя. Для этого она формирует DNS‑запрос, который проходит через всю цепочку DNS‑серверов — от локального резолвера и выше по иерархии, пока не найдёт нужную зону, где указано, какой сервер отвечает за приём почты для этого домена.

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

Наша задача — встроиться в эту систему. Мы уже арендовали домен, теперь хотим, чтобы его обслуживал наш собственный DNS‑сервер, а не DNS‑сервер регистратора.

Для этого мы:

  1. Настроим DNS-сервер (Bind9)

  2. Опишем DNS-зону для нашего домена

  3. Пропишем в ней, где находится наш почтовый сервер и какой у него IP-адрес

  4. Передадим DNS-серверу управление нашим доменом

Приступим!

1. Установка DNS-сервера

Устанавливаем Bind9 на VPS:

sudo apt update
sudo apt install bind9 bind9utils bind9-doc

2. Конфигурация сервера

Редактируем основной конфигурационный файл:

sudo nano /etc/bind/named.conf.local

Добавляем:

zone "pupkin.space" {
	type master;
	file "/etc/bind/zones/db.pupkin.space";
};

Помимо основного, стоит добавить несколько записей в файл опций:

sudo nano /etc/bind/named.conf.options

Пример содержимого:

options {
	directory "/var/cache/bind";

	dnssec-validation auto;

	allow-query { any; };

	listen-on port 53 { any; };
	listen-on-v6 { any; };

	allow-recursion { none;};
	recursion no;
};

Это хорошие минимальные и безопасные настройки.

3. Файл зоны

Следующим шагом идет создание DNS-зоны.

DNS-зона — это часть пространства доменных имён, за которую отвечает конкретный DNS-сервер. В ней хранятся все записи, связанные с этим доменом и его поддоменами. Для нашего почтового сервера выберем поддомен dev.

Создаём директорию зон, если её нет:

sudo mkdir /etc/bind/zones

Создаём файл зоны:

sudo nano /etc/bind/zones/db.pupkin.space

Пример содержимого:

$TTL 604800 ;
@	IN	SOA	dev.pupkin.space. admin.pupkin.space. (
			      3		; Serial
			  604800	; Refresh
			  86400		; Retry
			 2419200	; Expire
			  604800)	; Negative Cache TTL
;
		IN	NS		dev
		IN	NS		ns2
		IN	TXT		"v=spf1 ip4:123.123.123.123 -all"
		IN	MX 5	dev

dev     IN  A       123.123.123.123
ns2     IN  A       123.123.123.123
www		IN	CNAME	dev

Пояснение к записям:

  • $TTL (Time to Live) — время жизни записей в кэше других DNS-серверов. Показывает, как долго кэширующие серверы могут хранить данные зоны без повторного запроса. Значение применяется ко всем записям в файле. В данном случае записи будут храниться 7 дней (604800 секунд).

  • SOA (Start of Authority) — обязательная и единственная запись, с которой начинается каждая зона. Указывает:

    • основной DNS-сервер зоны — dev.pupkin.space.

    • email администратора зоны — admin.pupkin.space. (точка вместо @)

    • а также включает следующие параметры:

      • Serial — номер версии зоны. Его обязательно нужно увеличивать при каждом изменении зоны, иначе другие серверы не узнают, что произошли обновления.

      • Refresh, Retry, Expire, Negative Cache TTL — интервалы, которые определяют поведение secondary-серверов и кэширование ошибок.

  • NS (Name Server) — указывает, какие DNS-серверы обслуживают зону:

    • dev — наш основной (primary) сервер

    • ns2 — резервный (secondary) сервер (если нет альтернатив, то это тоже наш сервер)

  • TXT — универсальный тип записи. Здесь мы используем его для SPF (Sender Policy Framework) — механизма защиты от подделки отправителя. В записи "v=spf1 ip4:123.123.123.123 -all" говорится: письма от имени домена pupkin.space могут отправляться только с IP-адреса 123.123.123.123. Всё остальное — спам.

  • MX (Mail Exchanger) — указывает, какой хост обрабатывает почту для домена. Мы пишем dev, что значит: именно этот сервер будет принимать входящую почту.

  • A (Address) — связывает доменное имя с IP-адресом. Например, dev.pupkin.space. указывает на 123.123.123.123.

  • CNAME (Canonical Name) — задаёт псевдоним: www.pupkin.space. будет перенаправлен на dev.pupkin.space.. Это удобно, чтобы не дублировать A-записи.

Примечание: в файле зоны имя dev мы можем указывать без полного доменного имени (dev.pupkin.space.), потому что внутри файла зоны все неполные имена интерпретируются относительно текущей зоны (pupkin.space.). То есть запись MX 5 dev автоматически понимается как MX 5 dev.pupkin.space. и тд.

DNS-зону, как правило, обслуживают два сервера: основной (primary) и резервный (secondary). Primary-сервер отвечает за зону и содержит основной файл зоны, а secondary-сервер поддерживает его копию и обрабатывает запросы, если основной недоступен.

Идеально иметь два отдельных сервера, но у нас только один. Есть несколько вариантов, как выйти из этой ситуации:

  1. Попросить знакомого предоставить свой DNS-сервер в качестве secondary.

  2. Указать оба — и primary, и secondary — на один и тот же сервер. Это не лучший вариант с точки зрения отказоустойчивости, но он работает и не требует второго сервера.

  3. Использовать один сервер свой, а в качестве второго — сервер регистратора. Этот вариант я не рекомендую: регистраторы неохотно работают с внешними серверами, что может привести к дополнительным трудностям.

В нашем случае мы используем второй вариант, когда и primary, и secondary находятся на одной машине.

4. Проверка зоны и применение конфигурации:

После редактирования нужно убедиться, что файл зоны написан корректно:

sudo named-checkzone pupkin.space /etc/bind/zones/db.pupkin.space
sudo named-checkconf

Если всё в порядке — перезапускаем сервер:

sudo systemctl restart bind9

Проверка статуса:

sudo systemctl status bind9

(выйти из просмотра - :q)

Если все хорошо, Bind9 покажет статус Active: active (running), если же сервер упадет, то надо еще раз проверить, нет ли ошибок конфигурации, после чего идти в логи:

sudo journalctl -u named.service -n 50

или

sudo journalctl -u named.service -f

(выйти из просмотра - Ctrl+C)

В качестве последнего штриха убедимся, что Bind9 слушает 53 порт и доступен извне.

sudo ss -lnptu | grep :53

Вывод должен быть примерно следующим (только больше):

udp   UNCONN  0      0       0.0.0.0:53       0.0.0.0:*    users:(("named",pid,fd))
tcp   LISTEN  0      10      0.0.0.0:53       0.0.0.0:*    users:(("named",pid,fd))

Проверим также настройки UFW (фаервол):

sudo ufw status verbose

Если вы не видите среди них разрешения на 53 порт, то его нужно добавить:

sudo ufw allow 53/udp
sudo ufw reload

У вас может быть другой фаервол, если это так, подбирайте настройки соответственно.

5. Делегирование зоны у регистратора

Сейчас наш домен обслуживается DNS‑серверами регистратора. После того как мы настроили свой DNS‑сервер, мы должны делегировать зону ему. Для этого мы идем туда, где регистрировали домен, находим в личном кабинете меню с управлением DNS‑серверами и прописываем вместо первого из них наш свеженастроенный dev.pupkin.space, а вместо второго ns2.pupkin.space. Для первого и второго также прописываем IP 123.123.123.123 — такая опция должна быть в интерфейсе. Если ее нет, то обратитесь в поддержку и попросите прописать glue‑record. Это специальная запись, которая нужна, потому что dev.pupkin.space — это поддомен в той же зоне pupkin.space, которую он должен обслуживать, и без явного указания IP его невозможно разрешить (возникает замкнутый круг). С ns2 ситуация аналогична.

6. Проверка делегирования и работы DNS-сервера

Теперь нужно убедиться, что делегирование прошло успешно и наш DNS-сервер обслуживает домен. Для этого можно воспользоваться онлайн-сервисами:

Второй вариант - использовать локальную утилиту dig. 

Ее можно установить следующим образом:

sudo apt install dnsutils

При помощи нее осуществляем проверки:

Проверка NS-записей:

dig pupkin.space NS +short

Ожидаемый результат:

dev.pupkin.space.
ns2.pupkin.space.

Здесь мы видим оба наших DNS-сервера.

Проверка MX-записей

dig pupkin.space MX +noall +answer

Ожидаемый результат:

pupkin.space.	IN	MX	5 dev.pupkin.space.

Это означает, что почта для домена будет приходить на dev.pupkin.space..

Проверка SPF-записи

dig pupkin.space TXT +short

Ожидаемый результат:

"v=spf1 ip4:123.123.123.123 -all"

Если вы добавляли SPF-запись — она должна отобразиться здесь.

Проверка полной трассировки DNS-запроса

dig pupkin.space any +trace

Показывает полную цепочку разрешения — от корневых серверов до нашего DNS-сервера. Если трассировка не срабатывает локально, попробуйте сделать трассировку запроса через онлайн-сервисы.

Если вы по dig-командам или онлайн-сервисам получили соответствующие записи - это хорошо, значит зона отдалась :-)

7. PTR-запись

В завершение стоит настроить PTR‑запись, также называемую reverse DNS (rDNS). Эта запись не обязательна для работы DNS‑сервера, но критически важна для почтового сервера — без неё почта с вашего IP‑адреса может массово блокироваться другими серверами.

Если A‑запись сопоставляет доменное имя с IP‑адресом, то PTR‑запись наоборот сопоставляет IP‑адрес с доменом. Благодаря этому получатель письма может проверить, что IP‑адрес, с которого пришло письмо, действительно соответствует доменному имени отправителя. Если такая проверка не проходит на стороне получателя, то ваше письмо может быть помечено как спам или отклонено.

PTR‑запись нельзя создать самостоятельно — её можно добавить только через провайдера VPS. Обычно это делается через поддержку: вы пишете письмо, указываете ваш IP‑адрес и доменное имя, которое хотите назначить, и просите настроить PTR‑запись. У разных хостеров процедура может отличаться, но обычно это делается в течение нескольких дней.

Примечание: в некоторых случаях все же создание PTR‑записи есть в UI у хостера, попробуйте поискать.

После того как провайдер подтвердил добавление, можно проверить запись двумя способами:

Способ 1: с помощью команды dig

dig -x 123.123.123.123 +short

Ожидаемый результат:

dev.pupkin.space.

Способ 2: с помощью команды host

host 123.123.123.123

Ожидаемый результат:

123.123.123.123.in-addr.arpa domain name pointer dev.pupkin.space.

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

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

Postfix (SMTP-сервер)

SMTP‑сервер — это почтовый сервер, который использует протокол SMTP (Simple Mail Transfer Protocol) для отправки и получения электронной почты между почтовыми клиентами и другими серверами. Он отвечает за корректную доставку сообщений, маршрутизацию почты и взаимодействие с другими почтовыми системами в интернете.

В нашей почтовой архитектуре SMTP‑сервер будет обслуживать только локальных пользователей операционной системы Linux, то есть принимает почту исключительно для учётных записей, созданных непосредственно на сервере. У каждого такого пользователя есть собственный почтовый ящик — это либо файл /var/mail/vasya, либо, как в нашем случае, директория ~/Maildir/, если используется формат Maildir. Мы будем использовать именно его: каждое входящее письмо будет храниться в отдельном файле, что удобнее для чтения, фильтрации и резервного копирования.

Когда SMTP‑сервер принимает почту для конкретного пользователя, он помещает сообщение во внутреннюю очередь, выполняет базовую фильтрацию и доставляет его в соответствующий почтовый ящик. Адрес пользователя строится по схеме vasya@pupkin.space, где vasya — имя локальной учётной записи, а pupkin.space — домен, которым управляет наш сервер. Таким образом, почта обслуживается только для своих локальных пользователей внутри заданного домена.

О "своих" и "чужих"

Для нашего SMTP-сервера:

  • "Своими" считаются локальные пользователи системы

  • "Чужими" — все внешние адресаты и отправители из других доменов

SMTP-сервер может доставлять письма по принципу:

  • "свои" → "свои"

  • "чужие" → "свои"

  • "свои" → "чужие"

но никогда!!! "чужие" → "чужие".

Разрешение пересылки "чужим от чужих" превращает сервер в открытый релей (open relay), за что он моментально попадает в черные списки, и восстановить его репутацию будет уже невозможно. Настройки, которые мы разберём ниже, надёжно защищают от этого, но настраивать Postfix следует очень внимательно.

1. Установка Postfix

Устанавливаем Postfix на VPS:

sudo apt update
sudo apt install postfix

Во время установки система задаст несколько вопросов. Выберите тип конфигурации "Internet Site", а в качестве системного почтового домена укажите ваш домен pupkin.space.. Если в меню у вас не будет получаться выбрать Ok, попробуйте стрелочки влево-вправо.

2. Конфигурация Postfix

Редактируем основной конфигурационный файл:

sudo nano /etc/postfix/main.cf

Пример содержимого:

# See /usr/share/postfix/main.cf.dist for a commented, more complete version

выйти из просмотра
# Debian specific:  Specifying a file name will cause the first
# line of that file to be used as the name.  The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

readme_directory = no

# See http://www.postfix.org/COMPATIBILITY_README.html -- default to 2 on
# fresh installs.
compatibility_level = 2

# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_security_level=none

smtp_tls_CApath=/etc/ssl/certs
smtp_tls_security_level=none
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_generic_maps = hash:/etc/postfix/generic

smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination

myhostname = dev.pupkin.space
mydomain = pupkin.space
myorigin = $mydomain
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases

mydestination = $myhostname, $mydomain, localhost

relayhost = 
relay_domains =

mynetworks = host 

mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
inet_protocols = all

Комментарии к важным настройкам

  • myhostname, mydomain, myorigin — задают имя хоста и домен, с которыми будет работать сервер.

  • mydestination — список доменов, для которых этот сервер принимает входящую почту. Например, для пользователя vasya будут приниматься письма, отправленные на:

    • vasya@pupkin.space

    • vasya@dev.pupkin.space

    • vasya@localhost

  • mynetworks = host — важнейшая настройка, определяющая, откуда можно отправлять письма. В данном случае разрешена отправка только с самого сервера. Это безопасно на первом этапе, когда мы будем использовать локальные утилиты вроде mutt для отправки.

  • smtpd_relay_restrictions — строго определяет, кто имеет право на пересылку.

    • permit_mynetworks — разрешает отправку с локальной машины

    • permit_sasl_authenticated — авторизованные пользователи (например, при работе с IMAP/SMTP-клиентами в будущем)

    • reject_unauth_destination — всё остальное запрещается. Это основной щит от превращения сервера в open relay

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

Сначала проверим, слушает ли Postfix нужный порт:

sudo ss -tnlp | grep :25

Ожидаемый вывод — строка, где видно, что процесс master (Postfix) слушает порт 0.0.0.0:25 или [::]:25. Это означает, что сервер готов принимать подключения на всех сетевых интерфейсах.

Теперь проверим доступ к порту извне (с вашей локальной машины вне VPS):

telnet dev.pupkin.space 25

(из telnet выход QUIT)

или

nc -vz dev.pupkin.space 25

Если соединение устанавливается — отлично, порт открыт, всё работает.

Если же команда «висит» или завершается ошибкой вроде Connection timed out или Connection refused, есть два варианта: либо мешает фаервол, либо ваш хостинг-провайдер блокирует порт.

  • В первом случае можно попробовать временно отключить или перенастроить UFW (или другой фаервол).

  • Во втором случае — придётся писать в поддержку и подавать заявку на разблокировку 25 порта.

Некоторые провайдеры не разблокируют его вовсе — поэтому при выборе VPS об этом лучше уточнять заранее (!). К счастью, большинство адекватных хостеров этот порт открывают без проблем, особенно по запросу.

Далее проверим настройки UFW (если он используется):

sudo ufw status verbose

Если Status: active, и вы не видите разрешения на порт 25, надо добавить:

sudo ufw allow 25/tcp
sudo ufw reload

Поделюсь опытом, у меня после настройки SMTP-сервера почта не ходила именно из-за UFW. Только после  добавления правилаsudo ufw allow 25/tcp я смогла отправлять и принимать почту.

3. Применение конфигурации

После внесения изменений:

sudo postfix check
sudo systemctl restart postfix

Проверка статуса:

sudo systemctl status postfix

(выйти из просмотра - :q)

Если все хорошо, Postfix покажет статус Active: active, иначе идем в логи:

sudo tail -n 50 /var/log/mail.log

или

sudo tail -f /var/log/mail.log

(выйти из просмотра - Ctrl+C)

4. Создание пользователя

Наша работа по конфигурации почтового сервера подошла к следующему этапу — созданию пользователя. Если до этого момента мы настраивали только системные конфиги от имени root (как и положено в цивилизованном мире), то теперь пора перейти к реальному взаимодействию с почтовой системой, а для этого нам нужен пользователь, например, vasya.

Создаём пользователя в Linux:

sudo adduser vasya

Особое внимание стоит уделить паролю. Очень часто пользователи ставят что‑то вроде Vpupkin87, и кажется, что всё в порядке. Но если вы сидите на VPS с публичным статическим IP, такой пароль могут подобрать за несколько часов. Я, например, по наивности сделала слабый пароль и уже на второй день получила троян‑майнер, а вместе с ним — гневное письмо от хостера с требованием немедленно прекратить слать миллионы запросов, иначе мой сервер будет уничтожен.

Вывод: придумывайте пароль не короче 12–15 символов, состоящий из строчных и заглавных латинских букв, цифр и спецсимволов — и обязательно вперемешку!

Пример: UwFP7=5iC5TA.

Это не паранойя — это здравый смысл!

Примечание: на этом этапе вход по паролю можно пока оставить включённым. Но после того, как вы всё настроите и проверите, стоит настроить вход по SSH‑ключу — это безопаснее и удобнее. Здесь я не буду описывать эту настройку подробно, вы легко найдёте инструкцию сами. Просто помните: если отключить вход по паролю слишком рано, то некоторые утилиты, требующие ручного ввода пароля, станут недоступны.

5. Маппинг email-адресов

Если вы хотите, чтобы письма от root или vasya@localhost выглядели как vasya@pupkin.space, создайте файл /etc/postfix/generic:

root@pupkin.space         vasya@pupkin.space
vasya@localhost           vasya@pupkin.space

Затем:

sudo postmap /etc/postfix/generic
sudo postfix check
sudo systemctl restart postfix
sudo systemctl status postfix

6. Переход на Maildir

По умолчанию Postfix использует формат mbox, при котором все письма одного пользователя хранятся в одном большом файле /var/mail/vasya. Это неудобно. Лучше использовать формат Maildir, где каждое письмо — отдельный файл в директории ~/Maildir.

Чтобы переключиться:

В /etc/postfix/main.cf в любое место необходимо добавить строку:

home_mailbox = Maildir/

После этого перезапустите Postfix:

sudo postfix check
sudo systemctl restart postfix
sudo systemctl status postfix

Установите maildrop, чтобы создать директорию Maildir:

sudo apt install maildrop

Создайте структуру Maildir для нужного пользователя (например, vasya):

sudo -u vasya bash
maildirmake ~/Maildir
maildirmake ~/Maildir/.Sent
maildirmake ~/Maildir/.Drafts
chmod -R 700 ~/Maildir
exit

Теперь, когда вы отправите себе письмо, оно появится в ~/Maildir/new/.

На этом этапе базовая настройка SMTP‑сервера завершена. Остался последний штрих — подключение локального почтового клиента (mutt), чтобы можно было отправлять и читать письма прямо на сервере.

Mutt E-mail Client

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

Почему именно Mutt:

  • Подходит для системной почты и повседневной работы на сервере

  • Прост в установке и конфигурации

  • Позволяет лучше понять внутреннюю механику email

  • Поддерживает работу с Maildir и mbox, внешними MTA (Postfix, Sendmail и др.)

  • Гибко настраивается через .muttrc

1. Установка mutt

Устанавливаем mutt под рутом:

sudo apt install mutt

2. Конфигурация mutt

Создаем файл конфигурации .muttrc для пользователя vasya: 

sudo nano /home/vasya/.muttrc

В файл прописываем следующие настройки:

# Disable sorting
set sort=mailbox-order

# Set the desired default "from" address for both header From and envelope-from
set from="vasya@pupkin.space"
set envelope_from=yes
set use_domain=no

# Maildir
set mbox_type=Maildir
set folder="/home/vasya/Maildir"
set spoolfile="/home/vasya/Maildir"
set record="+.Sent"
set postponed="+.Drafts"

# Recognize these as own addresses for displaying +/T/C marks on messages, as
# well as for the reverse_name setting
alternates "vasya@pupkin.space"

# When replying to or forwarding a message sent to a recognized own address
# (see above), reuse the same full name and address that the message was
# addressed to as the new "from" address
set reverse_name=yes

# Maybe use ~/tmp instead of /tmp - useful when /tmp is on tmpfs, to not lose
# edits on power failure
set tmpdir="/home/vasya/tmp"

# Decode and/or decrypt messages when searching (much slower and prompts for
# passphrase on first encrypted message encountered)
set thorough_search="yes"

# Use this when "ispell" is actually the "aspell" wrapper (press "i" to invoke)
set ispell="ispell --mode=email"

# By default, Mutt adds the original sender's address to Subject on forwards,
# which we usually don't want
set forward_format="Fwd: %s"

# Don't display these headers by default (press "h" to display full headers)
ignore Delivered-To X-Delivery-ID X-Priority X-MSMail-Priority X-MimeOLE X-Spam-Checker-Version X-Spam-Level X-Spam-Status Precedence X-No-Archive List- DomainKey-Signature In-Reply-To User-Agent DKIM-Signature X-Google-Sender-Auth

# Highlight the obfuscated e-mail addresses in our RPM %changelogs, etc.
color body brightcyan default "<[-a-z_0-9.+]+[- ]at[- ][-a-z_0-9.]+>"

# If you're using a local SpamAssassin bayes database, you might want to bind a
# key, such as Shift-S on the index, to invoke sa-learn and mark messages as
# deleted.
#macro index S "| sa-learn --spam --no-sync --single\n<delete-message>" "spam learn"

# ...append /usr/share/doc/mutt-1.4*/gpg.rc to here
#source ~/.mutt/gpg

bind pager <up> previous-line
bind pager <down> next-line
bind index F flag-message
bind pager F flag-message
bind index x sync-mailbox

После редактирования достаточно сохранить и выйти.

Не забудьте под vasya создать директорию /tmp, иначе вы не сможете в mutt открывать письма.

sudo mkdir /home/vasya/tmp
sudo chown vasya:vasya /home/vasya/tmp
sudo chmod 700 /home/vasya/tmp

3. Использование mutt

После всего этого можно спокойно использовать mutt для просмотра и отправки писем. Чтобы в него войти, используйте команду:

mutt

Навигация и действия отображаются в верхнем меню. Почта будет храниться в ~/Maildir, а отправленные — в ~/Maildir/.Sent.

4. Тестирование

Финальным шагом будет полноценное тестирование работы вашей почты — как входящей, так и исходящей. Если у вас есть друг, готовый помочь — отлично. Если нет, используйте личные почтовые ящики, например, Gmail, Mail.ru или Yandex. Чем больше комбинаций вы проверите, тем выше вероятность, что конфигурация действительно работает корректно.

От vasya:

  1. Заходим в mutt.

  2. Нажимаем m (новое письмо), указываем получателя и тему.

  3. Печатаем текст, затем ^X (если используете nano) и y, видим Mail Sent.

  4. Идем в директорию ~/Maildir/.Sent/cur и убеждаемся, что там появилось наше письмо.

  5. Убеждаемся, что письмо появилось у получателя на внешней почте.

Если что-то не сработало, идем в логи и ищем, по какой причине письмо не удалось доставить.

sudo tail -n 100 /var/log/mail.log

Для vasya:

  1. Заходим на какую-нибудь имеющуюся почту на Mail.ru, Gmail или Yandex.

  2. Отправляем письмо на vasya@pupkin.space.

  3. Заходим в mutt и видим письмо, можем его прочитать.

  4. Проверяем, что это письмо появилось в ~/Maildir/new.

Если письмо не пришло -> идем в логи.

Если оба направления работают — поздравляю, у вас функционирующий SMTP‑сервер, который способен как принимать, так и отправлять почту!!! Ура‑ура!!!

Заключение

В ходе этой инструкции мы развернули DNS‑сервер, полноценный SMTP‑сервер на собственном домене, создали локального пользователя, подключили почтовый клиент и протестировали приём и отправку писем. По сути, мы получили простую, но полностью рабочую альтернативу почтовым сервисам вроде Gmail, Yandex или Mail.ru — только теперь вся система под нашим полным контролем.

Этот результат — уже само по себе достижение. Даже в минимальной конфигурации почтовый сервер:

  • функционирует в реальном домене

  • обрабатывает письма локальных пользователей

  • удовлетворяет базовым требованиям безопасности (в частности, не является open relay)

  • прост в эксплуатации и открыт к дальнейшему развитию

И самое важное — теперь у вас есть собственный почтовый сервер. Вы не ��росто скопировали мои настройки, вы поняли, как всё устроено — от маршрутизации до хранения писем в формате Maildir.

Выбранная почтовая архитектура очень хорошо подходит для личного пользования, но она отнюдь неидеальна.

Что в перспективе можно улучшить:

  1. DKIM/DMARC. Для повышения доверия к вашей почте и защиты от подделки отправителей стоит настроить цифровую подпись DKIM и политику DMARC через конфигурацию DNS‑записей.

  2. TLS. SMTP‑сервер на данном этапе не использует шифрование при передаче писем. Рекомендуется подключить поддержку TLS через Let's Encrypt и certbot, чтобы обеспечить безопасность вашей почтовой переписки.

  3. IMAP-сервер. Сейчас вы читаете почту через mutt прямо на сервере. Чтобы подключать внешние почтовые клиенты и приложения, потребуется IMAP‑сервер (например, Dovecot), обеспечивающий синхронизацию писем.

  4. Спам-фильтры. Можно настроить спам‑фильтры, которые блокируют входящий трафик, исходя из ваших предпочтений.

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

Надеюсь, статья была вам полезна. Спасибо, что дочитали до конца!

Удачи вам в самостоятельной работе с почтовой инфраструктурой и дальнейшем изучении сетевых технологий!

До новых встреч!

Подготовлено в соавторстве с ByteRider