- Что означает «Эта настройка недоступна для вашего аккаунта»
- Почему IMAP/SMTP вдруг «отвалились» после старой работы
- Быстрый чек-лист: что сделать прямо сейчас
- Если пароли приложений доступны: как настроить IMAP/SMTP
- Если пароли приложений недоступны: что делать вместо этого
- Частая путаница: «какой пароль нужен клиенту»
- Про “ненадежные приложения” и why это не лечит
- Где чаще всего ломается настройка (и как не тратить дни)
- Официальные источники, к которым стоит вернуться
- Итог: что делать в вашей ситуации
Если вы видите в Google ошибку вроде [AUTHENTICATIONFAILED] Invalid credentials, 535 5.7.8 BadCredentials, либо просто в аккаунте стоит сообщение «Эта настройка недоступна для вашего аккаунта» для пункта пароли приложений, вы не один. С большой вероятностью проблема в том, что Google ограничил доступ к устаревшей схеме логин+пароль и требует использовать другой способ авторизации (обычно это пароли приложений или OAuth-совместимый доступ).
Ниже разложу по полочкам, что именно проверять и что делать, чтобы IMAP/SMTP снова заработали.
Что означает «Эта настройка недоступна для вашего аккаунта»
Google показывает это сообщение, когда для вашего аккаунта включены ограничения, из-за которых пункт пароли приложений не доступен.
Чаще всего на практике это происходит в двух сценариях:
- Уже включены современные требования к входу (включая сценарии с повышенной защитой), и Google перестал выдавать пароли приложений.
- Вы настраиваете доступ не к тем протоколам/не тем способом, и клиент (почтовая программа, скрипт,
ssmtp, C#-отправка, и т.д.) продолжает пытаться входить «старым» способом.
Важно: даже если вы видите, что двухэтапная аутентификация отключена, это не всегда означает, что пароли приложений обязательно будут доступны. Политики Google зависят от состояния аккаунта и логики безопасности.
Почему IMAP/SMTP вдруг «отвалились» после старой работы
По ощущениям многих людей это происходит после обновлений политики безопасности Google. Симптомы обычно такие:
- почтовый клиент пишет
Invalid credentialsилиBadCredentials - автоматизация (скрипты,
curl,ssmtp, отправка из кода) начинает получать535 5.7.8 - настройки «ненадежных приложений» недоступны (и это нормально для текущей модели безопасности)
Типичный путь, который люди находят в обсуждениях: использовать пароли приложений для конкретного клиента/устройства, а затем в клиенте заменить пароль на этот сгенерированный. Если же пункт недоступен, значит нужен альтернативный путь (чаще OAuth).
Быстрый чек-лист: что сделать прямо сейчас
Проверьте, какой именно способ авторизации использует ваш клиент
Сопоставьте вашу ситуацию с типом доступа:
| Сценарий | Признак | Что почти всегда помогает |
|---|---|---|
| Почтовый клиент (Thunderbird, The Bat!, и т.п.) по IMAP | AUTHENTICATIONFAILED Invalid credentials |
логин + пароль приложений, если он доступен; иначе - OAuth |
SMTP отправка (сервер/скрипт/ssmtp) |
535 5.7.8 BadCredentials |
SMTP с авторизацией по схеме, которую поддерживает клиент (пароль приложения или OAuth) |
| Автоматизация через код (C#, сервис) | ошибка про пароль/токен | OAuth или то, что требует провайдер, а не «учётка и пароль как раньше» |
| Автоматизация через API/эндпоинты | внезапно 0 писем/ошибки | проверьте, не изменилась ли модель доступа и токены |
Убедитесь, что в настройках IMAP включён доступ IMAP
Даже когда логин/пароль правильные, IMAP должен быть включён в настройках Gmail.
Если пароли приложений доступны: как настроить IMAP/SMTP
Обычно схема такая (пользователи описывали её шаг за шагом):
- Войдите в аккаунт Google через браузер.
- Откройте Безопасность.
- Найдите блок Вход в аккаунт Google.
- Перейдите в Пароли приложений.
- Создайте пароль:
- выберите приложение (например, Почта)
- выберите устройство (например, Windows-компьютер)
- Скопируйте сгенерированный пароль.
- В почтовом клиенте замените старый пароль на этот пароль приложений.
- Проверьте, что включён IMAP.
Смысл простой: Google выдаёт отдельный пароль под конкретный сценарий, и старые попытки “логин+пароль аккаунта” перестают работать.
Если пароли приложений недоступны: что делать вместо этого
Когда вы видите именно «Эта настройка недоступна для вашего аккаунта», у вас два практичных варианта:
Вариант 1: Перейти на OAuth-авторизацию в клиенте/библиотеке
Если ваша почтовая программа поддерживает OAuth (часто это есть у современных клиентов и интеграций), это самый чистый путь.
Идея такая: клиент получает токен на авторизованный доступ, а не пытается использовать пароль приложения/аккаунта.
Вариант 2: Использовать другой поддерживаемый механизм, который ваш клиент поддерживает для Gmail
Если ваш инструмент не умеет OAuth, иногда помогает:
- сменить способ подключения
- перейти на другой почтовый клиент/провайдера отправки
- использовать официальные API/библиотеки, которые корректно работают с Gmail по текущей модели безопасности
Ключевой момент: настройка «ненадежные приложения» и старые подходы на стороне Google часто отключены и не дают решения.
Частая путаница: «какой пароль нужен клиенту»
Когда люди настраивают SMTP/IMAP из кода или почтового клиента, они нередко берут пароль от аккаунта и получают BadCredentials.
Обычно нужно:
- если доступна настройка пароли приложений - используйте пароль приложения
- если пароли приложений недоступны - значит нужен OAuth/другой современный способ, который поддерживает ваш клиент
На Stack Overflow эту путаницу описывали прямо: Google требует пароль приложения, когда вы идёте через схему, которая рассчитывает на него; если настройка недоступна, значит идёт другой режим безопасности и нужен соответствующий механизм.
Про “ненадежные приложения” и why это не лечит
Есть старые ссылки на “ненадежные приложения”, но в актуальной модели Google это часто выглядит так:
- страница настройки есть в документации
- но в вашем аккаунте она заблокирована
- и вы упираетесь в сценарии, где «просто включить галочку» нельзя
Если цель - IMAP/SMTP, то попытка чинить “ненадежные приложения” обычно превращается в тупик. Смотрите на доступность пароли приложений и/или переходите на OAuth-совместимый доступ.
Где чаще всего ломается настройка (и как не тратить дни)
| Что вы сделали | Что могло пойти не так |
|---|---|
| Включили двухэтапную аутентификацию, но пароли приложений всё равно недоступны | возможно, аккаунт подпадает под другое правило доступа или требует иной механизм |
| В почтовом клиенте оставили пароль аккаунта | нужен пароль приложения (если он доступен) |
| Ожидали, что “смена пароля” в аккаунте вернёт IMAP | не всегда: проблема не в пароле аккаунта, а в схеме авторизации |
| Настроили IMAP, но клиент всё равно ругается на credentials | проверьте, какой пароль именно подставили и не нужен ли OAuth |
| Пытались через старые endpoint’ы/скрипты | модель доступа могла измениться, а токены/протоколы - устареть |
Официальные источники, к которым стоит вернуться
- Google Help: пароли приложений и доступ через них (страница настройки доступна в аккаунте)
- Google Help: политика доступа к аккаунту и причины отказа в старых схемах (в т.ч. про отказ от “ненадежных приложений”)
- Базовый ориентир по протоколам IMAP/SMTP и включению IMAP в настройках Gmail
Надёжные ссылки, которые упоминаются в обсуждениях:
- https://myaccount.google.com/apppasswords
- https://myaccount.google.com/signinoptions/twosv
- https://support.google.com/accounts/answer/6010255?hl=ru
Итог: что делать в вашей ситуации
- Если пароли приложений доступны - создайте пароль приложения и подставьте его в почтовый клиент для IMAP/SMTP. После этого доступ обычно возвращается.
- Если пароли приложений недоступны и вы видите ровно «Эта настройка недоступна для вашего аккаунта» - починить “галочками” почти всегда не получится. Переходите на OAuth или на способ авторизации, который поддерживает ваш клиент/инструмент для Gmail.
Сухая правда: как только Google меняет схему входа, старые настройки “логин+пароль в клиент” перестают быть совместимыми. Поэтому сначала определяется, доступен ли ответ в виде паролей приложений (и тогда всё просто), или вы идёте в msk реальность OAuth (и тогда нужна настройка токенов, а не угадывание пароля).