Как я настраиваю Outlook после переезда с Яндекса

После переезда с Яндекса я проверяю в Outlook адреса серверов, способ входа и шифрование. Если настройки профиля мешают подключению, создаю новый рядом со старым и проверяю почту. Удалять старый до сохранения локальных данных нельзя. Ниже — порядок для классического и нового Outlook, проверка отправки и разбор ошибки 401.

Почему Outlook просит пароль после переезда

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

Яндекс поддерживает стандартные IMAP и SMTP. mailcow тоже использует эти протоколы: особой несовместимости на уровне кэша между ними нет. Отличаться могут параметры серверов, разрешённые способы входа и сами учётные данные. В экспертной базе есть важная деталь из справки Яндекса: для описанной там настройки Outlook создают пароль приложения и разрешают доступ почтовым программам. Это относится к исходному ящику. На целевом сервере я использую его собственные учётные данные; пароль приложения Яндекса не становится паролем нового ящика после смены MX.

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

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

• Сверить тип учётной записи и оба сервера.
• Уточнить логин и способ входа у администратора.
• Записать ошибку, время и узел подключения.
• Проверять приём и отправку отдельно.

Какие серверы, порты и TLS проверить

MX определяет, куда другие почтовые серверы доставляют письма домена. Эта запись не переписывает вручную заданный IMAP-сервер в Outlook. Для чтения и отправки клиенту нужны свои имена узлов; в условном примере это mail.example.com. Я сверяю их с целевой системой, затем проверяю, как эти имена разрешаются из сети сотрудника. Autodiscover отвечает за автоматическое получение настроек там, где его поддерживают сервер и клиент. Исправная MX-запись, открытый веб-интерфейс и работающая автоконфигурация — разные проверки. Одну за другую в акте приёмки не засчитываю.

Для стандартных привязок mailcow документация указывает IMAP с непосредственным TLS на порту 993, SMTP с STARTTLS на 587 и SMTP с непосредственным TLS на 465. Я выбираю опубликованный администратором вариант отправки, а не открываю всё подряд. Порт и режим шифрования — пара: на 587 соединение повышается до TLS командой протокола STARTTLS, на 465 защищённое соединение начинается сразу. Надпись SSL/TLS в клиенте может обозначать именно этот непосредственный TLS. Перебирать переключатели без понимания режима — способ получить новую ошибку вместо ответа.

Доступность порта ещё не означает готовность почты. Я проверяю, что нужная служба принимает соединение, предъявляет подходящий сертификат и разрешает вход конкретному пользователю. Сертификат должен соответствовать имени сервера и проходить проверку доверия; также проверяю срок действия и корректность времени на компьютере. Если имя не совпадает, исправляю имя подключения либо сертификат и его установку. Если не доверена цепочка, разбираюсь с цепочкой и доверенными центрами. Отключение проверки сертификата оставляет причину на месте, просто убирает сообщение о ней.

После изменения DNS я сравниваю ответ авторитетного сервера с ответом резолвера, которым пользуется рабочее место. Время хранения прежнего ответа связано с TTL записи; универсального правила подождать сутки здесь нет. Очистка локального кэша не очищает кэш чужого резолвера и не меняет строку сервера в Outlook. Если имя уже разрешается правильно, бессмысленно ждать обновления DNS вместо проверки входа. Автоконфигурацию mailcow я рассматриваю отдельно: её ограничения для Outlook разобраны в статье про Autodiscover в mailcow.

• IMAP: 993 и SSL/TLS при стандартной конфигурации.
• SMTP: 587 и STARTTLS либо 465 и SSL/TLS.
• Проверить имя, доверие и срок сертификата.
• Сопоставить DNS-ответы и TTL нужной записи.

Как настроить классический Outlook без потери данных

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

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

В новом профиле добавляю учётную запись. Когда требуется ручной ввод, в классическом Outlook использую «Файл → Добавить учётную запись», дополнительные параметры и ручную настройку, затем IMAP. Названия могут немного отличаться в локализации. Ввожу целевые серверы и согласованные пары порта и шифрования. Логин беру из карточки системы: для рассматриваемой настройки mailcow это полный адрес ящика. Требование полного адреса нельзя переносить на любого поставщика без проверки. Отдельно задаю SMTP-авторизацию; при стандартной настройке mailcow для неё используются учётные данные того же ящика.

Затем я переключаюсь на новый профиль. В экспертной базе есть точная последовательность из справки: «Файл → Настройка учётных записей → Изменить профиль», закрытие Outlook и повторный запуск вручную, после которого появляется выбор профиля. Выбираю новый, проверяю получение, отправку и нужные папки. Только после успешной проверки назначаю его основным. Остальные ящики добавляю по рабочей необходимости, а не ради обязательного объединения всего в один профиль. Старый удаляю после сверки и сохранения нужных данных; до этого он помогает вернуться к прежним локальным элементам.

• Сохранить и проверить локальные данные.
• Создать профиль рядом со старым.
• Настроить целевой IMAP и исходящий SMTP.
• Перезапустить Outlook и выбрать профиль.
• Проверить обмен письмами, затем назначить профиль основным.

Что меняется в новом Outlook

В новом Outlook я настраиваю учётную запись внутри приложения. По текущей справке её добавляют в параметрах через раздел учётных записей; названия вкладок зависят от выпуска и языка. Инструкция mailcow описывает выбор IMAP и явный ввод входящего и исходящего серверов, паролей, портов и шифрования. Классические профили из Панели управления здесь не являются тем же механизмом настройки. Если старое подключение нужно удалить и добавить заново, сначала проверяю синхронизацию и сохранность нужных данных. Автоматически переносить процедуру классического клиента в новый нельзя.

Исправный Autodiscover не гарантирует автоматическую настройку современного Outlook с mailcow. Разработчики прямо предупреждают об ограничении и рекомендуют ручную конфигурацию. Поэтому я не обещаю, что достаточно дождаться DNS и мастер сам найдёт нужный сервер. Если он определяет поставщика неверно, выбираю предусмотренный приложением путь добавления IMAP и сверяю поля с инструкцией. Добавление стороннего ящика на сайте Outlook.com не является универсальным способом настроить настольное приложение. Веб-почту целевого сервера проверяю отдельно; чужой веб-сервис не заменяет этот тест.

Ещё один факт из экспертной базы: миграция через IMAP переносит почту, а не контакты и календарь. Само IMAP-подключение тоже не синхронизирует эти данные. Если письма появились, а встречи нет, я проверяю отдельный план переноса и поддержки календарей, а не меняю пароль почты. В документации mailcow отдельно указано, что новый Outlook не поддерживает её CalDAV/CardDAV-сценарий, включая надстройку CalDav Synchronizer. Это ограничение нужно учитывать до смены клиента. Для таких задач есть отдельный разбор переноса контактов и календарей.

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

Условный кейс: «ЛюменДом», 14 рабочих мест

Возьму заданный условный пример: московский магазин света «ЛюменДом», 14 рабочих мест, переезд с Яндекса на mailcow. Это учебный сценарий, а не отчёт о реальном заказчике. Исходный симптом — повторный запрос пароля после смены почтовой площадки. В рабочем плане я фиксирую сборку Outlook на каждом компьютере, используемый тип учётной записи и наличие локальных архивов. Номер версии не придумываю: от него зависит маршрут настройки. До пилота нельзя честно утверждать ни причину сбоя, ни срок исправления всего офиса.

Для пилота выбираю одно рабочее место с обычными для магазина задачами. Проверяю фактический сервер в Outlook, DNS и TLS; для стандартной схемы использую IMAP 993 с SSL/TLS и SMTP 587 с STARTTLS. Если выясняется, что IMAP настроен на прежний узел, исправляю подключение или создаю проверочный профиль. Если клиент уже идёт на новый узел, ищу отказ в журнале соответствующей службы. Объяснение про застрявший OAuth-токен допускаю только при подтверждении выбранного способа входа. Фраза «сервер идеален» журнал подключения не заменяет.

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

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

• Пилот на одном рабочем месте.
• После пилота — оценка окна работ.
• Приёмка подключения на всех 14 местах.
• Отдельная проверка архива и переходной доставки.

Как читать 401 и принимать работу

Код 401 относится к HTTP и означает запрос или отказ авторизации на соответствующем веб-узле, например при Autodiscover. Это не универсальный ответ IMAP на неверный логин и не диагноз просроченного сертификата. В документации отдельно отмечено: одиночный 401 в процессе перебора адресов Autodiscover ещё не доказывает неправильный пароль — следующий узел может принять учётные данные. Я смотрю полный ход запросов, конечный адрес и итог подключения. Если код повторяется без успешного продолжения, проверяю адрес службы и поддерживаемый способ входа. Сертификат разбираю по сообщению TLS, а не по совпадению с запросом пароля.

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

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

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

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