Гибридная корпоративная почта: часть ящиков в облаке, часть на своём сервере — как устроить и зачем

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

Зачем гибрид, если цель — своё

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

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

Мост, а не дом

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

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

Как это устроено

У домена может быть только один набор MX-записей, поэтому вся входящая почта сначала приходит в одно место — на «главный» сервер. Он знает, какие ящики живут у него, а какие — у второго участника, и пересылает письма для чужих ящиков туда. Главным может быть облако или свой сервер; мы рекомендуем свой: тогда входящая почта под вашим контролем с первого дня, и в момент сбоя облака письма для облачных ящиков не теряются, а ждут в очереди вашего сервера.

• MX указывает на ваш сервер
• ваш сервер доставляет в свои ящики и пересылает письма для облачных ящиков в облако
• облачные ящики отправляют наружу через облако, ваши — через ваш сервер
• SPF разрешает оба источника, DKIM подписывает оба
• внутренняя почта между ящиками идёт через те же маршруты

Маршрутизация на своём сервере

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

# /etc/postfix/transport — ящики, которые пока остаются в облаке
ivan@company.ru     smtp:[mx.cloud-provider.example]:25
olga@company.ru     smtp:[mx.cloud-provider.example]:25

# /etc/postfix/main.cf
transport_maps = hash:/etc/postfix/transport

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

SPF и DKIM в гибриде

Почта от одного домена уходит из двух мест, и оба должны быть разрешены. SPF включает и ваш сервер, и облако.

company.ru.  TXT  "v=spf1 mx include:_spf.cloud-provider.example -all"

DKIM работает с двумя ключами одновременно: у облака свой селектор, у вашего сервера — свой, обе записи живут в DNS рядом. DMARC проверяет, что письмо прошло SPF или DKIM в связке с доменом, — в гибриде оба пути проходят. Отчёты DMARC в этот период особенно полезны: по ним видно, что вся почта домена идёт из ожидаемых мест. Подробности — в статье о MX, SPF, DKIM и DMARC при смене провайдера.

Адресная книга и календари

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

Это неудобство — главный аргумент не затягивать гибрид. Несколько недель сотрудники его терпят, несколько месяцев — нет.

Кого переводить первыми

Логика выбора — цена простоя и цена ошибки. Первыми идут те, для кого день без почты дороже всего, но при этом не самые сложные ящики по объёму.

• руководство — но после пробной волны, чтобы не обкатывать процесс на них
• бухгалтерия — до начала отчётного периода, а не в его середине
• отдел продаж — с общими ящиками для заявок
• ИТ-отдел — первым, чтобы найти проблемы на себе
• остальные — волнами по отделам

Где гибрид ломается

Почти все проблемы гибрида связаны с маршрутизацией и забытыми адресами.

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

Внутренняя почта между половинами

Письмо от сотрудника на своём сервере коллеге в облаке уходит не внутри одной системы, а через интернет — как письмо внешнему адресату. Отсюда три следствия. Задержки: обычно секунды, но при проблемах у любой из сторон письма встают в очередь. Лимиты: размер письма ограничен меньшим из двух лимитов, и большое вложение, которое раньше «ходило», может не пройти. Антиспам: облако может проверять письма от вашего сервера как внешние, поэтому ваш сервер нужно явно разрешить как доверенный источник для домена.

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

Что происходит, когда облако падает во время гибрида

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

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

Две системы — две зоны ответственности

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

Мониторинг гибрида

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

План гибрида по неделям

Типичная последовательность для компании на сотню-две сотрудников.

• неделя 1: свой сервер, домен, маршрутизация облачных ящиков, MX на свой сервер
• неделя 2: перенос ИТ-отдела и первой волны, проверка внутренней почты в обе стороны
• недели 3–4: руководство, бухгалтерия, продажи
• недели 5–8: остальные отделы волнами
• после последней волны: SPF и DKIM без облака, отключение тарифа

Почтовые программы и телефоны в гибриде

Для сотрудника гибрид означает простое правило: подключаться нужно к той системе, где живёт его ящик. Переведённые получают новые параметры сервера и перенастраивают телефоны и программы; оставшиеся в облаке ничего не меняют. Путаница начинается, когда сотрудник с ящиком на своём сервере по привычке открывает облачную веб-почту и видит пустой или старый ящик. Поэтому в день перевода каждой волны старый облачный ящик сотрудника переводится в режим, когда вход в него невозможен или в нём висит заметное сообщение «ваша почта теперь здесь».

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

Сколько стоит гибрид

На время гибрида компания платит за обе системы: облачные ящики, которые ещё не переехали, и свой сервер. Поэтому затягивать гибрид невыгодно и с этой стороны. Ориентиры по нашим ценам: почта на нашей инфраструктуре — от 150 ₽ в месяц за ящик, перенос до 50 ящиков — от 12 000 ₽ разово, обслуживание своего сервера — от 7 000 ₽ в месяц. Чем быстрее последняя волна, тем раньше уходит облачный тариф.

Гибрид как постоянная схема: почему нет

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

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

Как выйти из гибрида

Выход — это обычный переезд оставшихся ящиков волнами: перенос писем imapsync, удаление адресов из таблицы пересылки, перенастройка устройств. Когда в облаке не осталось ящиков, из SPF убирается облачный источник, удаляется его DKIM-ключ, и через пару недель отключается тариф. MX менять не нужно — он уже указывает на ваш сервер.

Порядок переноса писем — в статье «Перенос почты через imapsync», массовый перенос волнами — в статье о переносе сотен ящиков без простоя.

Обратная схема: облако как резерв

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

Что нужно для гибрида

Короткий список подготовки.

• свой почтовый сервер с тем же доменом
• список ящиков: какие на своём, какие в облаке
• маршрут пересылки для облачных ящиков на своём сервере
• входящий маршрут в облаке для писем от вашего сервера
• SPF с обоими источниками, два DKIM-ключа
• DMARC с отчётами
• общая адресная книга
• план и сроки выхода из гибрида

Итог

Гибрид — способ быстро защитить самое важное и уходить из облака поэтапно, без аврала. Правильная схема — MX на вашем сервере, пересылка облачных ящиков в облако, оба источника в SPF и DKIM. Неправильная цель — оставить гибрид навсегда. Через несколько недель или месяцев вся почта должна быть у вас: только тогда чужая авария перестаёт быть вашей проблемой. Как спланировать полный переезд — в руководстве по переносу почты с Яндекс 360.

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