По IMAP в почтовый ящик ходит не только Thunderbird. Тем же протоколом забирают письма сервисные интеграции - в том числе инструменты резервного копирования, если почту они берут именно так. И упирается всё это в одну опцию в личных настройках сотрудника.
Я основатель и руководитель компании +Альянс. Мне понадобилось понять, можно ли включить эту опцию централизованно, на всю организацию сразу. Способа не нашёл. Нашёл обратный - параметр, которым доступ по IMAP ограничивают; до тех, кто уже включил доступ себе, он не достаёт.
Ниже цитаты, по которым я это выяснил, каждая со ссылкой. Дат правки у справки Яндекса нет, поэтому называю свою дату сверки: 12 августа 2026 года.
Где живёт эта галочка
Страница “Другие программы” в справке Почты для бизнеса описывает четыре шага, и все четыре адресованы владельцу ящика, на “вы”. Первый: открыть “раздел Почтовые программы в настройках Яндекс Почты”; ссылка из справки ведёт прямо в настройки почтовых программ. Дальше нужно включить опцию “С сервера imap.yandex.ru по протоколу IMAP”, проверить, что включена опция “Пароли приложений и OAuth-токены”, и сохранить изменения.
Рядом справка отправляет за паролем приложения на страницу Яндекс ID и предупреждает: “Созданный пароль можно увидеть только один раз”. Мелочь ценой в потерянный вечер, если человек закрыл окно не глядя.
Потребительская версия той же страницы повторяет инструкцию слово в слово. Ни на одной из двух страниц нет упоминания, что администратор организации может включить IMAP за сотрудника или сразу для всех. Отсутствие упоминания само по себе ничего не доказывает, так что я полез в документацию API.
Когда IMAP выключен, почтовая программа не молчит
Справка Яндекса “Решение проблем с почтовой программой” называет основным симптомом отсутствия доступа по IMAP ошибку “Нет соединения с сервером”. Первым делом она советует проверить, включён ли в настройках Яндекс Почты доступ к ящику для почтовых клиентов и та самая опция “С сервера imap.yandex.ru по протоколу IMAP”. Дальше по списку: адрес сервера imap.yandex.ru, порт 993, SSL и попытка войти на сайте Яндекс Почты с теми же учётными данными.
Запомните этот симптом. Живой человек с Thunderbird или Outlook узнаёт о выключенном IMAP в ту же секунду: клиент не подключился и сказал об этом вслух.
Со стороны организации рычаг ровно один, и он запрещающий
Документация Яндекс 360 API, раздел “Настройки почты в организации”, формулирует прямо: “Работу с почтовыми ящиками организации через почтовые программы можно ограничить, если задать параметрам enable_imap и enable_pop значение false”.
Дальше начинается любопытное. Для новых сотрудников, чьи аккаунты будут созданы на домене организации, результат описан как “Нет доступа” по IMAP или POP3. А для тех, кто в организации уже работает, всё зависит от них самих: “доступ был настроен самим пользователем - доступ останется”, “доступ не был настроен на стороне пользователя - доступа не будет”.
И следом строка, которую я перечитал дважды: “Механизма, который устанавливал бы для уже существующих сотрудников централизованный запрет на работу по IMAP или POP3, пока нет”.
Складываю прочитанное. Параметр организации задаёт умолчание для будущих аккаунтов и бессилен против тех, кто уже включил себе IMAP; обратной операции - включить протокол всем - в разделе нет. Это мой вывод из процитированного, а не формулировка Яндекса.
Сведу пять возможных действий в таблицу:
Что нужно сделать | Кто это может | Откуда я это взял |
|---|---|---|
Включить IMAP в конкретном ящике | владелец ящика, у себя в разделе “Почтовые программы” | четыре шага справки, все на “вы” |
Включить IMAP сразу всем сотрудникам | способа в документации я не нашёл | в разделе “Настройки почты в организации” такой операции нет |
Закрыть IMAP для аккаунтов, которые будут созданы на домене | организация, параметром | документация обещает им “Нет доступа” |
Закрыть IMAP давнему сотруднику, который себе ничего не включал | тот же параметр, он справляется | “доступ не был настроен на стороне пользователя - доступа не будет” |
Закрыть IMAP тому, кто уже включил его себе | механизма нет | “Механизма… пока нет” - дословная цитата |
У фоновой задачи нет человека за экраном
Дальше рассуждение, без цитат.
У почтовой программы есть человек за экраном. Ошибка “Нет соединения с сервером” адресована ему, он её видит и идёт разбираться. У сервисной интеграции, которая ходит за письмами по расписанию, зрителя нет. Есть статус задачи, и наполняют его сами инструменты, каждый по-своему.
Плюс неприятное свойство картинки: ящик, в который не пустили, и пустой ящик снаружи неотличимы. И там, и там ноль писем.
У меня этот отказ выглядел так: задача копирования завершилась со статусом “успешно”, писем в копии не оказалось ни одного. Верить мне на слово тут не нужно: инструменты разные, ваш вполне может честно ругаться в лог. Выяснить это можно за вечер.
Как проверить это у себя
Нужна учётная запись, которой никто не пользуется и от которой у вас есть пароль. Тестовая, служебная, старая - любая.
Раздел “Почтовые программы” в ней не открывайте вообще. IMAP должен остаться выключенным.
Положите в ящик несколько писем с любого другого адреса. На пустом ящике опыт бессмыслен: копия и должна получиться пустой.
Запустите резервное копирование почты этой учётки тем инструментом, который у вас стоит.
На статус задачи не смотрите. Откройте само хранилище копий и проверьте, появилась ли структура папок и лежат ли в них письма.
Теперь включите IMAP по четырём шагам из справки и повторите пункты 3 и 4.
Сравните два прогона. Если статус в обоих одинаковый, вы узнали про свой инструмент главное: он не отличает “скопировал ноль писем” от “не смог подключиться”.
Что с этим делать в онбординге
Раз включение IMAP - действие сотрудника, у администратора остаются инструкция и проверка.
Инструкция - это ссылка на раздел настроек и четыре шага в письме первого дня, рядом с “поставь себе двухфакторку”. Проверка - выборочный просмотр содержимого копий, а не отчётов о выполненных задачах.
Отдельно держите в голове параметр организации. Если когда-то enable_imap у вас выставили в false, новые сотрудники получат по IMAP “Нет доступа” - так это описано в документации Яндекс 360 API. Сможет ли сотрудник в этом случае включить опцию у себя, документация не говорит. Я не проверял и выдумывать не стану; если запрет у вас стоит, прогоните это на той же тестовой учётной записи.
С чужими ящиками всё наоборот
Общие и делегированные ящики устроены иначе. Справка “Совместный доступ к ящикам в почтовых программах”: “Доступ к таким ящикам предоставляет администратор организации” и “От того, какие права он вам назначит, зависят конкретные действия, которые вы сможете выполнять в этих ящиках”. Пароли при этом не требуются: “Чтобы пользоваться общими и делегированными ящиками, знать пароли от чужих аккаунтов не требуется”. Настройку справка показывает для Mozilla Thunderbird, Microsoft Outlook и Apple Mail, то есть по тому же IMAP.
Инверсия занятная. Доступ к чужому ящику администратор выдаёт сам, а протокол в своём собственном - нет.
Ещё одна строка оттуда, полезная всем, кто планирует что-нибудь автоматизировать поверх делегированного доступа: “Письма, которые прочитает сотрудник с доступом к делегированному ящику, отметятся прочитанными и в почтовой программе владельца ящика”. Любой читатель делегированного ящика оставляет след у владельца.
Покрывает ли ваш инструмент резервного копирования общие ящики - вопрос к его разработчику. Справка Яндекса на него не отвечает: она про доступ.
Место, где я не разобрался
На той же странице “Другие программы”, в разделе “Настроить программу по протоколу IMAP”, в конце шага 3 “Настройте программу” стоит фраза: “Поддержка протокола IMAP включится автоматически при первой авторизации в почтовой программе”. Она есть и в бизнес-версии страницы, и в потребительской.
Свести эту фразу с четырьмя шагами, где ту же опцию просят включить руками, у меня не получилось. Утверждать “включится само” я не буду: тогда непонятно, зачем справка просит включать опцию. Утверждать обратное тоже не буду - фраза в справке есть, ссылка на неё дана. При каких условиях автоматическое включение срабатывает и относится ли оно к подключению по OAuth-токену, я не знаю; проверять на живой организации не стал. Если кто-то воспроизводил - буду благодарен за детали.
Про глубину моей проверки скажу честно. Управление IMAP со стороны организации я искал в справке Почты и в документации Яндекс 360 API. До оглавления документации администратора не добрался: страница yandex.ru/support/yandex-360/business/admin/ru/mail/ и корень yandex.ru/support/yandex-360/business/admin/ru/ 12 августа 2026 года отдавали мне 404 по прямому обращению. Отдельные страницы внутри раздела при этом открываются нормально, так что дело, похоже, в способе обращения.
Скажу против себя
Устройство платформы, при котором внешний доступ к чужому почтовому ящику не включается распоряжением сверху, я считаю правильным. Резервное копирование - далеко не единственное, что подключают к ящику этим протоколом. Будь эта опция управляемой сверху, я бы первым написал текст о том, чем это опасно.
Дыра от моей правоты никуда не девается. Я не отличаю сотрудника, который сознательно оставил IMAP выключенным, от сотрудника, который просто не дочитал письмо от админа. Снаружи оба выглядят одинаково: копия снята, писем внутри нет.
Что делаю. Включение IMAP переехало у меня из категории “предполагается, что человек это сделал” в инструкцию первого дня, а копии я выборочно открываю руками и смотрю, есть ли в них папки. Костыль, конечно. Пока лучше не придумал.
