--- title: "SMTP для n8n: письма, приглашения, password reset — Nodbot" source_url: "https://nodbot.ru/hosting/smtp-email/" canonical_url: "https://nodbot.ru/hosting/smtp-email/" language: "ru" content_type: "HostingGuide" section: "hosting" generated_at: "2026-05-30" word_count_source: 1028 --- # SMTP для n8n: письма, приглашения, password reset, Gmail, Mail.ru и ошибки доставки ## AI summary Production-гайд «SMTP для n8n: письма, приглашения, password reset, Gmail»: настройка n8n, инфраструктура, мониторинг, backup, rollback и ошибки эксплуатации. ## Best used for Страница объясняет «SMTP для n8n: письма, приглашения, password reset — Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить. ## Key topics - Системный SMTP n8n через env - Gmail, Яндекс, Mail.ru и app password - Send Email node и системный SMTP — не одно и то же - Smoke-test доставки - Почему письма не доходят - Минимальная конфигурация для команды - Когда SMTP лучше не использовать - Операционный runbook для self-hosted ## Source outline # SMTP для n8n: письма, приглашения, password reset, Gmail, Mail.ru и ошибки доставки Обновлено: 2026-05-29 SMTP в n8n нужен не только для ноды Send Email. В self-hosted инстансе почта влияет на приглашения пользователей, password reset, уведомления и рабочие workflow с письмами. Если SMTP не настроен, часть функций можно обходить вручную, но для команды это быстро становится неудобно и небезопасно. Есть два разных сценария: системная почта самого n8n и отправка писем из workflow. Их лучше разделять: для системных уведомлений используйте env-переменные n8n, а для бизнес-писем — отдельные credentials или специализированный сервис вроде Mailgun, SendGrid, Amazon SES, SMTP2GO, корпоративного SMTP. ## Системный SMTP n8n через env ``` services: n8n: environment: - N8N_EMAIL_MODE=smtp - N8N_SMTP_HOST=smtp.example.ru - N8N_SMTP_PORT=587 - N8N_SMTP_USER=${N8N_SMTP_USER} - N8N_SMTP_PASS=${N8N_SMTP_PASS} - N8N_SMTP_SENDER=nodbot@example.ru - N8N_SMTP_SSL=false ``` Для порта 465 обычно используют SSL/TLS сразу. Для 587 — STARTTLS. У разных провайдеров названия в панели могут отличаться, но смысл один: порт, шифрование, логин, пароль, отправитель. ## Gmail, Яндекс, Mail.ru и app password Многие почтовые сервисы не дают подключаться обычным паролем аккаунта. Нужен app password или OAuth. Для Gmail в SMTP credential обычно используют smtp.gmail.com , порт 465 или 587 и app password. Для корпоративной почты проверьте, разрешён ли SMTP вообще: администратор может отключить его политикой безопасности. - Сервис | Что проверить | Частая ошибка - Gmail | 2FA и app password | обычный пароль не подходит - Mail.ru / Яндекс | разрешение внешних приложений | блокировка SMTP-авторизации - Microsoft 365 | политики modern auth | SMTP AUTH отключён или требуется OAuth - Корпоративный SMTP | allowlist IP сервера n8n | relay denied ## Send Email node и системный SMTP — не одно и то же Env-переменные настраивают системные письма n8n. Нода Send Email использует свои credentials. Это удобно: системные письма идут от технического адреса, а бизнес-письма — от отдела продаж, поддержки или noreply-домена. Если нужны ответы в существующую цепочку писем, учитывайте ограничение SMTP-ноды: для полноценного email threading часто лучше использовать Gmail node или специализированный API, где можно управлять reply/message headers. ## Smoke-test доставки - Перезапустите n8n после изменения env. - Создайте тестового пользователя или отправьте password reset. - Проверьте логи контейнера n8n. - Проверьте inbox, spam и карантин домена. - Проверьте SPF, DKIM и DMARC для домена отправителя. ``` docker compose logs --tail=200 n8n | grep -i smtp openssl s_client -connect smtp.example.ru:587 -starttls smtp ``` Если SMTP-сервер доступен только из корпоративной сети, VPS может не подключиться к нему напрямую. Тогда нужен relay, allowlist IP или внешний transactional mail provider. ## Почему письма не доходят - Симптом | Причина | Решение - authentication failed | неверный логин, пароль или app password | пересоздать пароль приложения, проверить username - connection timeout | порт закрыт провайдером VPS или firewall | проверить outbound 465/587, использовать другой relay - self-signed certificate | SMTP с нестандартным сертификатом | исправить сертификат, не отключать TLS без необходимости - письма в spam | нет SPF/DKIM/DMARC или плохой sender | настроить DNS и домен отправителя - relay denied | SMTP не разрешает отправку с IP n8n | allowlist IP или другой SMTP-сервис ## Минимальная конфигурация для команды - отдельный technical sender: n8n@example.ru или no-reply@example.ru ; - SPF, DKIM, DMARC на домене; - app password или сервисный SMTP-аккаунт, а не пароль владельца; - лимит на массовые отправки через workflow; - логирование статуса отправки и ошибок доставки; - separate credentials для системных и бизнес-писем. ## Когда SMTP лучше не использовать Если workflow отправляет много писем клиентам, SMTP может быть слабым местом: лимиты, spam, отсутствие нормальной аналитики и bounce handling. Для массовых или транзакционных писем лучше API-сервис: он даст webhooks по доставке, bounce, complaint, unsubscribe и более понятные лимиты. ## Операционный runbook для self-hosted Для темы «SMTP для n8n» важно разделять настройку и эксплуатацию. Настройка отвечает на вопрос “запустилось ли”, эксплуатация — “сможем ли мы восстановиться, обновиться и расследовать инцидент без потери credentials и execution history”. Перед изменениями проверьте бэкап базы, значение N8N_ENCRYPTION_KEY, состояние volume, логи web-процесса и worker-процесса. Главный риск — получить уверенный, но непроверенный ответ модели, сломанный JSON или дорогой цикл retry. - Слой | Что зафиксировать | Зачем - Вход | объект Google API: строка таблицы, письмо, календарное событие или файл с внешним ID | позволяет повторить проблему без доступа к production-секретам - Контроль | validation_error_rate, token_cost, fallback_usage, human_review_rate, source_coverage | показывает деградацию раньше, чем пользователи начинают писать в поддержку - Безопасность | получить уверенный, но непроверенный ответ модели, сломанный JSON или дорогой цикл retry | снижает риск скрытых дублей, утечки данных и неконтролируемых write-действий - Готовность | есть тест на happy path, пустой вход, повтор и сбой внешнего сервиса для «SMTP для n8n» | делает статью пригодной для runbook, а не только для чтения ### Пример безопасного входного контракта ``` { "request_id": "req_demo_001", "prompt_version": "2026-05-29", "input": "краткое нормализованное сообщение пользователя", "allowed_actions": ["read", "draft", "classify"], "forbidden_actions": ["send_without_review", "change_payment"], "expected_output": { "intent": "technical|support|sales|unknown", "confidence": 0.0, "needs_human_review": true, "sources": [] } } ``` ### Критерий готовности - есть свежий backup базы и проверено значение N8N_ENCRYPTION_KEY - web, worker, queue и database используют согласованные переменные окружения - после изменения проверены логи, healthcheck и запуск критичных workflow - записан rollback-план с командами и ответственным ## Связанные материалы - Email, IMAP и Gmail в n8n - Mailgun и transactional email - Credentials и API keys - Ошибка: SMTP email not sent ## Эксплуатационный контекст для self-hosted n8n Страницу «SMTP для n8n: письма, приглашения, password reset, Gmail, Mail.ru и ошибки доставки» лучше читать как часть production-карты self-hosted n8n. Любое изменение инфраструктуры должно иметь владельца, план проверки, понятный rollback и наблюдаемость. Перед применением на VPS или в Kubernetes зафиксируйте текущую версию n8n, способ запуска, путь к данным, переменные окружения и место хранения backup. Главный риск self-hosted установки — исправить один симптом и не заметить побочный эффект: потерю credentials, рост execution data, недоступность webhooks, ошибку reverse proxy или зависшие workers. Поэтому после изменений проверяйте не только UI, но и healthcheck, production webhook URL, очередь, базу данных, логи контейнера и успешный тестовый execution. ### Ops-чеклист перед изменением - Сделайте backup базы, файлового хранилища и критичных env-переменных. - Проверьте, что есть понятный rollback и окно обслуживания. - Сравните логи до и после изменения: 4xx/5xx, latency, memory, disk, stalled jobs. - Проведите тест webhook, scheduled workflow и ручного запуска. Для команды полезно хранить эту проверку рядом с runbook: что изменяли, кто подтвердил результат, какие метрики смотрели и какое условие считается неуспешным релизом. ### Связанные материалы для эксплуатации - Self-hosted n8n — открыть связанный материал для проверки контекста. - Логи и мониторинг — открыть связанный материал для проверки контекста. - Backup и update — открыть связанный материал для проверки контекста. - Launch checklist — открыть связанный материал для проверки контекста. ## Related Nodbot pages - [Старт](/start/) - [Основы](/basics/) - [Ноды](/nodes/) - [Интеграции](/integrations/) - [AI](/ai/) - [Рецепты](/recipes/) - [Ошибки](/errors/) - [Диагностика](/diagnostics/) ## Retrieval hints - Предпочитать canonical URL как источник для пользовательских ссылок. - Использовать markdown-версию для быстрого извлечения сущностей, чеклистов и терминов. - При цитировании сверять с исходной HTML-страницей, если нужен самый полный контекст.