Корпоративная почта на Postfix: SPF, DKIM, DMARC и борьба со спамом для бизнеса

Привет! Меня зовут Семёнов Евгений Сергеевич, и я руковожу компанией АйТи Фреш. Знаете, из всех инфраструктурных задач, которые проходят через нашу команду, корпоративная почта часто остаётся в тени, её недооценивают. Вот представьте: бухгалтер не получил счёт от поставщика — первая мысль: «Да это, наверное, провайдер тормозит». Или менеджер отправил важное коммерческое предложение, а клиент его не видит — «Может, ему просто не интересно?». Но на самом деле, в 80 % случаев виноват не кто иной, как криво настроенный почтовый сервер. За свои 15 лет в IT я разобрал десятки, если не сотни, таких историй. И вот в этой статье я поделюсь пошаговой инструкцией, как построить корпоративную почту, которая точно не потеряет ни одного письма и при этом надёжно защитит вашу компанию от злоумышленников.

Почему «у нас всё работает» — это самый опасный диагноз

Помню, как в декабре 2024 года к нам обратился клиент — крупное производство строительной химии, у них 80 человек работают в офисе и на двух заводах. Жалоба была, на первый взгляд, очень простой: «Наши контрагенты просто не получают счета». Бухгалтерия целую неделю, представляете, выясняла отношения с тремя разными компаниями — они проверяли спам, обновляли контакты, пересылали документы повторно. И только когда эта неприятная история повторилась с пятым контрагентом подряд, ИТ-руководитель, наконец, догадался позвонить нам.

Когда мы провели аудит, я увидел ту самую картину, которую уже десятки раз встречал. SPF-записи в DNS просто не существовало, DKIM был не настроен. А самое обидное — IP сервера ещё в 2022 году, после серьёзного взлома, угодил в Spamhaus PBL, и, что самое поразительное, компания даже не подозревала об этом! В итоге Gmail и Mail.ru тихонько отправляли 60 % их писем прямиком в спам, а часть вообще безжалостно резали reject'ом. Давайте прикинем: 80 человек × 30 деловых писем в день × 60 % потерь — это же 1440 писем ежедневно уходило в никуда! Сколько же денег это стоило за два года, никто так и не посчитал. Но я точно могу сказать, что руководитель после нашего отчёта схватился за голову.

Свой сервер или облако: честный разбор

Прежде чем мы с вами глубоко погрузимся в технические детали, давайте честно ответим на ключевой вопрос: а действительно ли вам необходим собственный Postfix? За 15 лет работы у меня сформировалась простая и чёткая матрица:

Если вы нашли себя в первой или второй строке, то, пожалуйста, закройте эту статью и смело идите на сайт Яндекса. Серьёзно, без шуток. Поднимать свой Postfix ради всего 25 ящиков — это как пытаться пилить дрова бензопилой, когда обычного топора будет вполне достаточно. Всё, что я расскажу дальше, предназначено для тех, кто по-настоящему решил держать свою почту под полным контролем, у себя.

Анатомия корпоративного почтового сервера

Поймите, полноценный сервер для серьёзного бизнеса — это не просто один Postfix, это целая связка из шести важнейших компонентов:

• Postfix — MTA, принимает и отправляет SMTP-трафик.
• Dovecot — IMAP/POP3 для клиентов (Outlook, Thunderbird, мобильные).
• Rspamd — антиспам и DKIM-подпись исходящих.
• OpenDMARC или встроенные механизмы Rspamd — проверка DMARC.
• ClamAV — антивирусная проверка вложений.
• Postfwd / Postscreen — защита от ботов и rate limiting.

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

SPF: разрешите своему серверу отправлять от вашего имени

SPF (Sender Policy Framework) — это такая специальная DNS-запись типа TXT. В ней вы чётко перечисляете, каким именно IP-адресам разрешено отправлять почту от имени вашего домена. Если письмо приходит с IP, которого нет в вашем SPF, получатель сразу же, без лишних вопросов, начинает считать его подозрительным.

# DNS TXT-запись для company.ru
company.ru. IN TXT "v=spf1 ip4:185.45.67.89 ip4:185.45.67.90 include:_spf.mail.ru ~all"

# Что значит каждая часть:
# v=spf1                — версия SPF (других нет)
# ip4:185.45.67.89      — IPv4 нашего основного почтового сервера
# ip4:185.45.67.90      — IPv4 резервного MX
# include:_spf.mail.ru  — доверяем серверам Mail.ru (если часть ящиков там)
# ~all                  — все остальные источники под подозрением (soft fail)

# После 2 недель тестов меняем на:
# -all                  — жёсткий fail для всех неперечисленных IP

Ключевая ошибка: ставить сразу -all. Потом обнаруживается, что у вас была настроена отправка из 1С через CRM-сервер, который вы забыли в SPF упомянуть, и все уведомления из CRM перестают приходить. Начинайте с ~all, через две недели мониторинга — переходите на -all.

DKIM: цифровая подпись каждого письма

DKIM (DomainKeys Identified Mail) — это, по сути, криптографическая подпись, которая ставится на заголовки вашего письма с помощью приватного ключа. Представьте: получатель проверяет эту подпись публичным ключом, который он берёт из DNS, и благодаря этому убеждается, что письмо действительно пришло от вас и что по пути его никто не успел подделать или изменить.

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

# Установка Rspamd на Debian 12 / Ubuntu 22.04
apt install -y rspamd redis-server
systemctl enable --now rspamd

# Создание DKIM-ключа
mkdir -p /var/lib/rspamd/dkim
rspamadm dkim_keygen -s 2026 -d company.ru -b 2048 \
  -k /var/lib/rspamd/dkim/company.ru.2026.key

# Команда выводит готовую DNS-запись:
# 2026._domainkey.company.ru. IN TXT (
#   "v=DKIM1; k=rsa; p=MIIBIjANBgkqhki..."
# )

chown _rspamd:_rspamd /var/lib/rspamd/dkim/company.ru.2026.key
chmod 600 /var/lib/rspamd/dkim/company.ru.2026.key

Конфигурация подписи в Rspamd:

# /etc/rspamd/local.d/dkim_signing.conf
enabled = true;
path = "/var/lib/rspamd/dkim/$domain.$selector.key";
selector = "2026";
try_fallback = true;
use_domain = "header";
sign_authenticated = true;
sign_local = true;
allow_hdrfrom_mismatch = false;

Интеграция Rspamd с Postfix через milter:

# /etc/postfix/main.cf — добавляем
smtpd_milters = inet:127.0.0.1:11332
non_smtpd_milters = inet:127.0.0.1:11332
milter_protocol = 6
milter_mail_macros = i {mail_addr} {client_addr} {client_name} {auth_authen}
milter_default_action = accept

systemctl restart postfix rspamd

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

DMARC: связываем SPF и DKIM в политику

DMARC — это такой своеобразный «командный центр», который прямо говорит получателю: «Если SPF и DKIM не сошлись, поступай с этим письмом вот так». Без DMARC антивирусные шлюзы ваших контрагентов сами решают, доверять вашему письму или нет. И, к сожалению, решают они частенько совсем не в вашу пользу.

# DNS TXT-запись DMARC
_dmarc.company.ru. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@company.ru; ruf=mailto:dmarc-forensic@company.ru; fo=1; adkim=r; aspf=r; pct=100"

# Расшифровка:
# p=none      — на старте только наблюдаем, никого не блокируем
# rua=        — куда слать ежедневные агрегированные отчёты
# ruf=        — куда слать отчёты по каждому подозрительному письму
# fo=1        — генерировать forensic при любом fail
# adkim=r     — DKIM-домен может быть relaxed-подмножеством
# aspf=r      — то же для SPF
# pct=100     — политика касается 100 % писем

План внедрения DMARC такой: первые 14 дней p=none и читаем агрегированные отчёты. Видим, какие IP отправляют от вашего имени — часть законных (вы про них могли забыть), часть мошеннических. Дополняем SPF законными источниками, после чего переходим к p=quarantine на месяц. И только потом — p=reject.

PTR-запись: обратный DNS

PTR — это обратная DNS-запись. Её задача — по IP вашего сервера вернуть его hostname. Если PTR отсутствует, то Gmail, Outlook и Mail.ru тут же снижают вашу оценку доверия, и очень сильно. Важно помнить, что настраивается она не у регистратора домена, а у вашего хостинг-провайдера — именно там, где физически расположен сервер.

# Проверка PTR из консоли
dig -x 185.45.67.89 +short
# Должно вернуть: mail.company.ru.

# Прямая запись должна вести обратно на тот же IP
dig mail.company.ru A +short
# Должно вернуть: 185.45.67.89

# Если PTR пустой — идём в личный кабинет хостинга
# (Hetzner Robot, Selectel, FirstByte и т.п.) → IP → rDNS

Rspamd для входящего антиспама

Та же связка Postfix + Rspamd, что подписывает исходящие, заодно фильтрует входящие. Конфигурация по умолчанию уже неплохая, но мы всегда добавляем три вещи: greylisting, расширенный список RBL и обучение байесом.

# /etc/rspamd/local.d/greylist.conf
enabled = true;
timeout = 300;        # 5 минут задержка для новых отправителей
expire = 86400;       # помним отправителя сутки
whitelist_symbols = ["WHITELIST_DKIM", "WHITELIST_SPF_DKIM"];
# Белые списки крупных провайдеров (чтобы не задерживать Yandex/Gmail)
whitelist_domains_url = ["https://maps.rspamd.com/freemail/free.txt.zst"];

# /etc/rspamd/local.d/rbl.conf — расширяем список RBL
rbls {
  spamhaus_zen {
    symbol = "RBL_SPAMHAUS_ZEN";
    rbl = "zen.spamhaus.org";
  }
  barracuda {
    symbol = "RBL_BARRACUDA";
    rbl = "b.barracudacentral.org";
  }
  sorbs {
    symbol = "RBL_SORBS";
    rbl = "dnsbl.sorbs.net";
  }
}

Greylisting убивает 70–80 % спама от ботнетов с нулевой настройкой, потому что бот не повторяет отправку через 5 минут. А вот легитимные SMTP-серверы (включая Gmail) — повторяют, и письмо проходит.

Postfix: правильные настройки для бизнеса

Минимальный конфиг Postfix, который мы кладём клиентам:

# /etc/postfix/main.cf — ключевые параметры

myhostname = mail.company.ru
mydomain = company.ru
myorigin = $mydomain
inet_interfaces = all
inet_protocols = ipv4
mydestination = $myhostname, localhost.$mydomain, localhost

# Виртуальные домены и ящики через MySQL/PostgreSQL
virtual_mailbox_domains = mysql:/etc/postfix/mysql-domains.cf
virtual_mailbox_maps = mysql:/etc/postfix/mysql-mailboxes.cf
virtual_alias_maps = mysql:/etc/postfix/mysql-aliases.cf

# TLS — обязательно, минимум 1.2
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.company.ru/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.company.ru/privkey.pem
smtpd_tls_security_level = may
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_security_level = may
smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1

# Защита от open relay
smtpd_relay_restrictions =
    permit_mynetworks
    permit_sasl_authenticated
    reject_unauth_destination

# Постскрин для отсева ботов до основного SMTP
postscreen_dnsbl_threshold = 3
postscreen_dnsbl_sites =
    zen.spamhaus.org*3
    b.barracudacentral.org*2
    bl.spamcop.net*2

# Rate limiting — не более 100 писем/мин с одного клиента
smtpd_client_message_rate_limit = 100

# Размеры
message_size_limit = 26214400        # 25 МБ
mailbox_size_limit = 0                # без лимита (Dovecot управляет)

Защита от подделок и фишинга «от директора»

Самая распространённая атака на бизнес — письмо «от директора» с просьбой срочно перевести деньги контрагенту. Без правильной настройки SPF/DKIM/DMARC такое письмо проходит насквозь и попадает к бухгалтеру. По нашему опыту, две из трёх компаний без жёсткого DMARC хотя бы раз получали такое письмо, и в одном из десяти случаев — деньги уходили.

После настройки p=reject в DMARC такая атака превращается в техническую невозможность: письмо отклоняется на стороне сервера получателя. У одного нашего клиента (логистическая компания, 90 человек) после внедрения DMARC за год было два зафиксированных случая, когда мошенники пытались отправить письмо «от генерального» на ящик главбуха. Оба отклонены автоматически, бухгалтер их даже не видела.

Мониторинг доставляемости: что замерять

Настроить — это полдела. Дальше надо регулярно проверять, что всё работает. Минимальный набор инструментов:

• mail-tester.com — отправляете тестовое письмо, получаете оценку 0–10. Норма для бизнеса — 9+. Меньше 7 — катастрофа, что-то срочно ломаем.
• Google Postmaster Tools — единственный способ увидеть реальную статистику доставки в Gmail. Регистрация бесплатна, подтверждение домена — TXT-запись в DNS.
• Mail.ru Postmaster — то же для Mail.ru. У них собственный набор требований и метрик.
• Yandex Postmaster — для Yandex.Mail. Менее информативный, но обязательно.
• Microsoft SNDS / JMRP — для Outlook.com и Hotmail.
• Анализатор DMARC-отчётов — DMARCian, Postmark, или собственный скрипт. Сырой XML читать тяжело.

Метрики, на которые мы еженедельно смотрим у клиентов:

Что делать, если IP уже попал в чёрный список

Если IP попал в RBL — паниковать рано. Делистинг возможен, но требует терпения:

1. Найти все RBL, в которых IP числится. Удобно проверять через mxtoolbox.com/blacklists.aspx.
2. Для каждого RBL найти процедуру делистинга. У Spamhaus — check.spamhaus.org, у Barracuda — www.barracudacentral.org/lookups, у SORBS — www.sorbs.net.
3. Перед запросом на делистинг убедиться, что причина включения устранена: сервер не открытый relay, нет вирусов на машинах в сети, есть SPF/DKIM/DMARC.
4. Запросить делистинг. Spamhaus обычно отвечает за 4–24 часа, остальные — от 1 до 7 дней.
5. Если попадание было серьёзным — лучше сменить IP. У хостингов это стоит 200–500 ₽ единовременно, и сразу решает все проблемы.

Кейс: как мы вытащили почту корпоративного клиента из спама

Январь 2026 года. Клиент — торговая компания, 110 человек, своя CRM с автоматическими уведомлениями клиентам. Жалоба: «Из 1500 уведомлений в день клиенты получают примерно треть, остальное в спаме». Аудит показал классику: SPF был, но без CRM-сервера; DKIM не подписывал письма из CRM; PTR-запись указывала на хостинг-провайдера, а не на mail.company.ru; в DMARC стояло p=none уже три года.

За 8 рабочих часов мы переписали SPF (добавили IP CRM-сервера), настроили DKIM-подпись для CRM-писем через выделенный селектор, поправили PTR через хостинг, начали мигрировать DMARC на p=quarantine. Параллельно зарегистрировали клиента в Google Postmaster и Mail.ru Postmaster, выгрузили IP из двух RBL, в которых он застрял после старого взлома.

Результаты не заставили себя ждать: уже через две недели spam rate в Gmail упал с 4.2 % до впечатляющих 0.08 %, а доставляемость в Mail.ru взлетела с 35 % до отличных 96 %. А теперь о бизнес-эффекте: наш клиент подсчитал, что плохая доставляемость обходилась ему в 18–22 потерянных заказа в месяц при среднем чеке 80 000 ₽. Все наши работы, к слову, обошлись всего в 65 000 ₽ и окупились всего за пять рабочих дней! Вот это я понимаю, инвестиция.

FAQ — частые вопросы по корпоративной почте

Свой сервер Postfix или Яндекс 360 для бизнеса?

Для офиса до 50 человек и без жёстких требований к контролю — Яндекс 360 или Mail.ru для Бизнеса. Для 50+ человек, юр. отдела, требований к локальному хранению — свой Postfix. Гибридный вариант: Postfix только как relay для рассылок, основные ящики в облаке.

Зачем нужны SPF, DKIM и DMARC, если письма и так уходят?

Без них любой может отправить письмо «от имени» вашего директора и обмануть бухгалтерию. SPF/DKIM/DMARC защищают репутацию домена и блокируют подделки. Gmail и Mail.ru с 2024 года требуют все три записи для массовых рассылок.

Сколько стоит развернуть свой почтовый сервер для офиса?

Развёртывание — от 35 000 ₽ для базовой конфигурации (Postfix + Dovecot + Rspamd + SPF/DKIM/DMARC), от 75 000 ₽ для серверов с массовыми рассылками (warm-up, FBL, мониторинг доставляемости).

Как проверить, попадают ли мои письма в спам?

Используйте mail-tester.com — отправьте тестовое письмо, получите оценку 0-10. Подключите Google Postmaster Tools и Mail.ru Postmaster — там видно реальную статистику доставляемости. Норма для бизнеса — оценка от 8/10 и spam rate ниже 0.1 %.

Делает ли АйТи Фреш почтовый аудит?

Да. За 1 рабочий день мы проверяем DNS-записи, репутацию IP, реальную доставляемость в основные провайдеры (Gmail, Mail.ru, Yandex, Outlook), даём письменный отчёт. Стоимость аудита — 12 000 ₽, при заключении договора на сопровождение засчитывается в счёт.