Резервный MX, архив и вторая площадка: как устроить резервирование корпоративной почты

Одна площадка — это не надёжность, это ставка всего бизнеса на одно здание, один провод и одного дежурного инженера, которого вы никогда не видели. Когда почта живёт у одного облачного провайдера, у неё одна точка отказа — его дата-центр, и октябрь 2026 года показал, как это выглядит на практике. Резервный MX (backup MX) — первый кирпич в защите от такой зависимости: второй почтовый сервер, который принимает письма, пока основной недоступен. Разбираем, что резервный MX умеет, чего не умеет, как его настроить на Postfix и зачем к нему нужны архив и вторая площадка.

Одна площадка — одна точка отказа

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

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

Одна корзина для всех яиц

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

Резервный MX и вторая площадка — это вторая корзина в другом месте, которую не уронит тот же пожар. Это не роскошь для корпораций, а базовая гигиена для любой компании, у которой почта приносит деньги. Стоит дешевле, чем один день, когда вы объясняете клиентам, почему их письма вернулись.

Что такое резервный MX

В DNS у домена может быть несколько MX-записей с разными приоритетами. Отправляющий сервер сначала пробует запись с наименьшим числом — основной сервер. Если тот не отвечает, письмо уходит на следующую запись — резервный MX. Резервный сервер принимает письмо, ставит в свою очередь и периодически пытается передать его на основной. Как только основной оживает, очередь доставляется.

company.ru.  MX  10 mail.company.ru.
company.ru.  MX  20 mx2.company.ru.

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

А разве отправитель сам не подождёт?

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

Но на практике это работает хуже, чем в стандарте. Часть отправителей — сервисы рассылок, уведомления банков и маркетплейсов, системы госорганов — повторяет попытки недолго или не повторяет вовсе. Через несколько часов отправитель получает предупреждение о задержке и начинает звонить или писать в мессенджер. Резервный MX убирает эту неопределённость: письмо принято, отправитель спокоен.

Главная ошибка: резервный MX без проверки получателей

Самая частая настройка резервного MX — «принимать всё для домена и пересылать на основной». Спамеры знают, что резервные серверы часто фильтруют хуже, и специально шлют на запись с низким приоритетом. Резервный MX, не знающий список адресов, принимает письма на несуществующие ящики, потом пытается доставить их на основной, получает отказ и отправляет уведомление о недоставке — на поддельный адрес отправителя. Это называется backscatter, и за него IP резервного сервера быстро попадает в чёрные списки.

Правило: резервный MX должен знать всех получателей домена и отклонять письма на несуществующие адреса сразу, на этапе SMTP-диалога. В Postfix это делает relay_recipient_maps. Подробный разбор с примерами — в статье «relay_recipient_maps для резервного MX».

Настройка резервного MX на Postfix

Минимальная конфигурация резервного MX на Postfix: домен в relay_domains, список получателей в relay_recipient_maps, увеличенный срок хранения очереди.

# /etc/postfix/main.cf на резервном MX
relay_domains = company.ru
relay_recipient_maps = hash:/etc/postfix/relay_recipients
maximal_queue_lifetime = 7d
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination

Список получателей синхронизируйте с основным сервером автоматически — скриптом по расписанию или выгрузкой из базы учётных записей. Ручной список устаревает при первом же новом сотруднике, и его письма начинают отклоняться резервным сервером. maximal_queue_lifetime 7d даёт неделю на восстановление основного; по умолчанию у Postfix пять дней.

• список получателей обновляется автоматически, не реже раза в час
• антиспам на резервном MX не слабее, чем на основном
• TLS с действующим сертификатом на имя резервного сервера
• PTR-запись резервного сервера на его имя
• мониторинг очереди: письма в очереди резервного — сигнал, что основной лежит

Резервный MX и проверки SPF на основном сервере

Есть техническая тонкость, которую часто упускают. Когда письмо пришло через резервный MX, основной сервер получает его не от исходного отправителя, а от вашего же резервного сервера. Если основной сервер проверяет SPF на входе, он сравнит IP резервного MX с SPF-записью домена отправителя — и проверка не пройдёт. Письмо уйдёт в спам или будет отклонено.

Решение — доверять резервному MX на основном сервере: добавить его IP в список доверенных сетей антиспама, чтобы проверки SPF и репутации выполнялись по первому внешнему узлу в заголовках, а не по последнему. Антиспам резервного сервера при этом должен проверять SPF сам, на входе. Rspamd и SpamAssassin умеют работать с доверенными ретрансляторами — это настраивается один раз при запуске резерва.

Архив: копия каждого письма отдельно от ящиков

Резервный MX спасает письма, пока основной недоступен. Но если основной сервер потерян совсем — пожар, шифровальщик, ошибка администратора, — письма в ящиках нужно восстанавливать из копии. Самый надёжный способ сделать так, чтобы ни одно письмо не пропало между копиями, — журналирование: сервер отправляет копию каждого входящего и исходящего письма в отдельный архивный ящик на другой площадке.

# /etc/postfix/main.cf на основном сервере: копия каждого письма в архив
always_bcc = archive@archive.company.ru

В Postfix это одна строка always_bcc; в mailcow, iRedMail и Carbonio есть свои способы сделать то же самое. Архивный ящик доступен только руководителю или службе безопасности, письма в нём не удаляются, а сам архив регулярно копируется на третью площадку. Кроме защиты от потерь архив закрывает и юридические вопросы: спорное письмо всегда можно найти, даже если сотрудник его удалил.

Копия ящиков на другой площадке

Архив хранит письма, но не структуру ящиков: папки, флаги, черновики. Для полного восстановления нужна копия ящиков. Мы делаем её imapsync по расписанию на резервный сервер у другого провайдера. Важно не использовать опцию удаления: тогда письмо, удалённое в основном ящике по ошибке или злоумышленником, остаётся в копии. На нашем стенде после удаления трёх писем в источнике копия по-прежнему хранила все 305, а повторный проход занимал 2–4 секунды.

Подробно о такой копии — в статье «Резервная копия почты». Для mailcow удобна схема холодного резерва с внешним томом — её мы описали в статье о холодном резерве mailcow.

Вторая площадка: от резерва к переключению

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

Как прожить переходный период с доставкой в два сервера одновременно, описано в статье «Перенос почты без простоя: двойная доставка». Время переключения определяется TTL записей DNS и готовностью резервного сервера. При TTL 300 секунд и заранее подготовленной машине переключение занимает от нескольких минут до часа. Главное — порядок действий записан, и его уже кто-то проходил на учениях.

Четыре уровня резервирования

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

• уровень 1 — копия ящиков на другой площадке: письма не теряются, восстановление за часы
• уровень 2 — резервный MX с проверкой получателей: входящие не возвращаются отправителям
• уровень 3 — архив каждого письма: ничего не пропадает между копиями
• уровень 4 — рабочий резервный сервер: переключение за минуты, сотрудники продолжают работать

Можно ли сделать резервный MX при почте в облаке

Формально — да: второй MX с более низким приоритетом может стоять у вас, даже если основная почта у облачного провайдера. Но есть нюансы. Резервный сервер не знает актуального списка ящиков облака, если его не синхронизировать через API провайдера. Облачный сервис может считать письма, пришедшие через чужой сервер, подозрительными — у них не тот путь, не та подпись. И главное — когда облако лежит, ваш резервный MX копит очередь, но сотрудникам от этого не легче.

Поэтому резервный MX при облачной почте — полумера. Полноценная защита начинается, когда основной сервер ваш, а резерв — на другой площадке. С чего начать переезд, разобрано в руководстве по переносу почты с Яндекс 360.

Сколько ресурсов нужно резервному MX

Резервный MX — лёгкий сервер. Он не хранит ящики и не обслуживает веб-почту, ему нужны только Postfix, антиспам и место под очередь. Виртуальной машины с 2 ГБ памяти и диском на несколько десятков гигабайт хватает для компании на сотни ящиков. Если на нём работает полноценный антивирус ClamAV, памяти нужно больше — ориентируйтесь на требования основного сервера.

Место под очередь считайте от худшего случая: суточный объём входящей почты, умноженный на срок хранения очереди. Если компания получает 2 ГБ писем в день, а очередь живёт семь дней, на диске резервного MX должно быть не меньше 14 ГБ свободного места с запасом.

Где держать вторую площадку

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

Отдельно продумайте DNS. Если зона домена обслуживается там же, где основной сервер, авария на этой площадке забирает и возможность сменить MX. Зону держите у регистратора или у независимого DNS-провайдера, а доступ к ней — у двух человек в компании, с записанным порядком входа.

Порядок действий при аварии

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

• определить: основной сервер недоступен дольше 15 минут, это не проблема канала офиса
• сообщить сотрудникам через мессенджер: почта временно недоступна, письма не теряются
• проверить, что очередь резервного MX растёт — входящие принимаются
• если восстановление основного дольше часа — переключить сотрудников на резервный сервер
• после восстановления основного — дождаться доставки очереди, проверить ящики
• записать в журнал время, причину, действия и что улучшить

Учения: проверяйте резерв до аварии

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

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

Мониторинг резерва

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

• доступность портов 25 и 993 на резервном сервере
• срок действия сертификатов
• дата последнего успешного обновления списка получателей
• дата и результат последней копии ящиков
• размер очереди резервного MX
• IP обоих серверов в чёрных списках

Частые вопросы