Коротко и по делу: последовательность такова — домен и система доменных имён (DNS), корректные записи MX/A/PTR, установка транспортного агента почты (MTA) с безопасным протоколом транспортного уровня (TLS), сервис доступа к почтовым ящикам IMAP, а затем аутентификация отправителя через SPF, идентификация ключей домена (DKIM), политика доменной аутентификации (DMARC), фильтры спама и мониторинг. Если соблюдать этот порядок, почта доходит в «Входящие», а репутация домена остаётся чистой.
Подготовка домена и DNS: MX, A, PTR — что обязательно
Нужно три вещи: запись MX указывает на полное доменное имя (FQDN) сервера, запись A сопоставляет это имя с публичным IP, а обратная запись PTR возвращает то же имя. Несовпадение A и PTR почти гарантирует серые списки и попадание в «Спам».
Почему так строго? Почтовые провайдеры сверяют «картинку»: кто вы по обратной системе доменных имён (DNS), как представляете сервер в приветствии HELO/EHLO (HELO/EHLO), и на кого смотрит MX. Когда все точки связаны, доверие растёт. Ещё один нюанс — отдельный поддомен для почты вроде «mail.домен.ru» упрощает управление. И да, срок жизни записей (TTL) лучше ставить умеренный: не чрезмерно длинный, чтобы изменения применялись без многочасовых ожиданий, и не смешной, иначе кэш у резолверов будет пустовать, а нагрузка — прыгать. Отдельно проверьте, что IP сервера не числится в публичных чёрных списках — иногда достаётся «уставший» адрес, и лучше сменить его до запуска.
| Что настроить | Тип записи | Пример значения | Комментарий |
|---|---|---|---|
| MX для домена | MX | 10 mail.example.ru. | Указывает на FQDN почтового сервера |
| Адрес сервера | A/AAAA | mail.example.ru → 203.0.113.10 | IPv4/IPv6 по возможности оба |
| Обратная зона | PTR | 203.0.113.10 → mail.example.ru. | Должно совпадать с HELO/EHLO |
| SPF (подготовка) | TXT | v=spf1 mx -all | Позже дополним при необходимости |
Выбор и установка MTA: Postfix, доступ к ящикам и шифрование
Надёжная связка выглядит так: транспортный агент почты (MTA) Postfix принимает и отправляет письма, а сервер доступа к ящикам Dovecot обслуживает протокол доступа к почтовым ящикам (IMAP) и протокол почтового отделения (POP3). Шифрование через протокол защиты транспортного уровня (TLS) обязательно, сертификаты — от доверенного центра.
С Postfix удобно начинать: гибкая конфигурация, мощные фильтры, понятная логика очередей. Dovecot — быстрый и бережно относится к почтовым ящикам, что важно на активных ящиках и при большом количестве одновременных подключений. Сертификаты можно получить у бесплатного центра сертификации Let’s Encrypt (Let’s Encrypt), автоматизировав продление. Слабые шифры и устаревший уровень защищённых сокетов (SSL) лучше отключить — меньше поводов для отказов со стороны крупных провайдеров. В приветствии сервера используйте то самое FQDN, которое возвращает PTR, — мелочь, а снимает подозрения. И не забывайте про отдельный порт отправки с аутентификацией для пользователей.
| Порт | Протокол | Служба | Примечание |
|---|---|---|---|
| 25 | SMTP (SMTP) | Приём/межсерверная передача | Требуется для внешней почты |
| 587 | SMTP | Отправка пользователями | С аутентификацией и TLS по умолчанию |
| 465 | SMTP | Отправка по TLS | Популярен у клиентов, оставьте включённым |
| 143 | IMAP (IMAP) | Доступ к ящикам | STARTTLS обязателен |
| 993 | IMAP | IMAP по TLS | Предпочтительно для клиентов |
| 110 | POP3 (POP3) | Загрузка писем | Лучше предлагать IMAP |
| 995 | POP3 | POP3 по TLS | Для консервативных сценариев |
Короткий практический список полезных настроек, которые экономят часы отладки:
- Ограничение размера письма и очереди — чтобы не зависали гигабайты вложений.
- Корректный баннер приветствия с FQDN — проверьте через telnet или openssl s_client.
- Раздельные логи для MTA и IMAP — разбор инцидентов становится быстрее.
- Своевременная ротация и компрессия логов — диски не резиновые.
Аутентификация отправителя: SPF, DKIM и DMARC
Три записи в системе доменных имён (DNS) укрепляют репутацию: SPF объявляет разрешённые источники отправки, DKIM подписывает письма ключом домена, DMARC задаёт политику проверки и отчётности. Без них письма чаще теряются по дороге или тонут в спаме.
Начинаем со SPF. Простой и строгий вариант — «v=spf1 mx -all»: отправлять можно только с серверов, указанных в MX. Если есть внешние сервисы (рассылки, хелпдеск), добавляем «include:» или «ip4:/ip6:». Далее подключаем OpenDKIM (OpenDKIM): генерируем ключ, публикуем публичную часть в TXT под селектором, включаем подпись исходящих доменов. После — DMARC: настраиваем доменную политику и адреса для отчётов, постепенно ужесточаем режимы от «none» к «quarantine» и «reject». И да, отчёты нужны не для галочки: они показывают неожиданную пересылку через чужие сервера и помогают ловить ошибки в SPF/DKIM.
| Технология | Где включать | Тип записи | Минимальный пример | Зачем это нужно |
|---|---|---|---|---|
| SPF | DNS домена | TXT | v=spf1 mx -all | Определяет разрешённые источники отправки |
| DKIM | OpenDKIM и DNS | TXT | selector._domainkey → публичный ключ | Криптографическая подпись писем доменным ключом |
| DMARC | DNS домена | TXT | _dmarc → v=DMARC1; p=quarantine; rua=mailto:dmarc@… | Политика проверки и адрес для отчётов |
Есть несколько тонких мест, о которых легко забыть. Не складывайте в SPF больше 10 DNS‑запросов — стандарт ограничивает «механизмы» и «include», и превышение ломает проверку. Следите за синхронизацией времени на сервере: неверные часы портят DKIM‑подписи, а дальше всё по цепочке. И, конечно, не создавайте разные селекторы, указывающие на один и тот же приватный ключ — лучше ротация ключей раз в год с аккуратным переключением записи.
Защита от спама, мониторинг и обслуживание
Базовый минимум: фильтр спама, антивирус по вложениям и сдержанная серая проверка, плюс мониторинг отказов и очередей. Сильная защита начинается с аккуратных политик, а не с грубой «дубины», которая режет легитимную почту.
Про фильтры. Анализатор спама SpamAssassin (SpamAssassin) всё ещё надёжен, особенно с обучением на собственной выборке «спам/не спам». Антивирус ClamAV (ClamAV) ловит очевидные вредоносы, но чудес не ждите — это последний фильтр, не первый. Серый список полезен в умеренных дозах и с автодобавлением в белый после успешной доставки. Блок‑листы? Да, но только проверенные и не в режиме «жёсткой плахи». Важнее другое: репутация исходящего IP и домена; берегите их, не допускайте массовых отскоков и спам‑жалоб.
Надёжность держится на наблюдении. Статусы очередей, доля временных отказов, скорость доставки к крупным провайдерам — всё это стоит собрать в панели. Логи ошибок TLS помогают поймать несовместимость шифров, а отчёты DMARC — увидеть, кто «от вашего имени» шлёт письма со стороны. И, кстати, резервные копии почтовых ящиков — скучная, но спасительная рутина: тестируйте восстановление, а не только делайте бэкап.
- Проверка доступности портов 25/587/993 снаружи и изнутри сети — простые регулярные прогоны.
- Еженедельная ревизия очереди исходящей почты: застрявшие письма — индикатор проблем.
- Контроль объёма логов и места на дисках: переполненные разделы ломают доставку.
- Ежеквартальное обновление и перегенерация слабых ключей TLS и DKIM.
- Просмотр агрегированных отчётов DMARC и корректировка SPF при изменении инфраструктуры.
Нужен краткий конспект в одном клике? Сформулированный порядок шагов — это «Настройка почтового сервера на Linux», где важно не перепрыгивать этапы: сначала домен и DNS, потом сервисы и шифрование, и лишь затем — аутентификация, фильтры и наблюдение.
И ещё одна практическая деталь. Пользовательские клиенты часто цепляются за старые настройки: SSL вместо современного TLS, нестандартные порты, устаревшие шифры. Подготовьте короткую памятку для команды с правильными параметрами: адрес сервера, порты 587/993, шифрование «обязательно», аутентификация «по паролю», и ссылку на страницу автоконфигурации — экономит нервы и время поддержки.
На финише полезно пробежать чек‑лист развёртывания. Он бесхитростный, зато полностью закрывает базу:
- MX/A/PTR согласованы, приветствие совпадает с FQDN.
- Сертификаты действуют, слабые шифры отключены.
- SPF/DKIM/DMARC опубликованы, отчёты собираются.
- Фильтрация спама и антивирус включены, логи разнесены.
- Резервные копии работают, восстановление проверено.
Итоговый вывод простой. Почтовый сервер на Linux стабилен и предсказуем, когда архитектура устроена без «костылей»: домен и DNS выверены, Postfix и Dovecot настроены с учётом шифрования, аутентификация отправителя закреплена в записях, а фильтры и мониторинг не прикручены в последний момент, а продуманы заранее. Такой подход снижает число загадочных отказов и выводит доставляемость на ровный, спокойный уровень.
А затем остаётся дисциплина. Раз в месяц просматривать отчёты, раз в квартал обновлять ключи и пакеты, при изменении инфраструктуры вовремя поправлять SPF и DMARC. Почтовая система любит порядок; стоит однажды его навести — и она отвечает взаимностью, доставляя письма тихо и вовремя.
