> For the complete documentation index, see [llms.txt](https://docs.iexexchanger.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.iexexchanger.com/learn/email.md).

# Полная настройка E-mail

## Что вы получите

Вы подготовите почтовый домен, выберете Zoho, Resend или другой SMTP-сервис, создадите актуальное подключение iEXExchanger, назначите события и докажете доставку реальным действием заявки.

Эта страница сохраняет привычный адрес раздела E-mail и описывает текущую систему уведомлений iEXExchanger.

{% hint style="warning" %}
Отдельная страница **«E-mail уведомления»** больше не является текущим экраном панели. Откройте **«Настройки» — «Общие настройки» — «Уведомления»**. Внутри используются страницы **«Общие параметры»** и **«Подключения»**.
{% endhint %}

## Как устроена текущая система

| Раньше                                                        | Сейчас                                                                         |
| ------------------------------------------------------------- | ------------------------------------------------------------------------------ |
| Одно почтовое подключение на отдельной странице               | Можно создать несколько независимых SMTP- и Resend-подключений                 |
| Переключатели событий находились рядом с общими полями E-mail | События, аудитории и приоритет задаются внутри каждого подключения             |
| Проверка подключения считалась достаточной                    | Отдельно проверяются подключение, событие, очередь, провайдер и конечный ящик  |
| Второй SMTP мог восприниматься как резерв                     | Одинаковое событие в двух подключениях создаёт две отправки и может дать дубль |

```mermaid
flowchart LR
    A["Событие заявки"] --> B["Общие переключатели"]
    B --> C["Подключение SMTP или Resend"]
    C --> D["Аудитория и приоритет"]
    D --> E["Очередь уведомлений"]
    E --> F["Почтовый провайдер"]
    F --> G["Конечный ящик"]
```

Сохранение настройки подтверждает только один слой этой цепочки.

## 1. Подготовьте адреса и домен

Разделите три назначения:

| Назначение                    | Где задаётся                              | Для чего используется         |
| ----------------------------- | ----------------------------------------- | ----------------------------- |
| E-mail службы поддержки       | **«Общие параметры»**                     | Контакт для клиента и ответов |
| E-mail адреса администраторов | **«Общие параметры»**                     | Получатели служебных событий  |
| E-mail и имя отправителя      | В конкретном SMTP- или Resend-подключении | Поля From в исходящем письме  |

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

{% stepper %}
{% step %}

### Выберите домен отправки

Используйте домен компании. Для транзакционной почты можно выделить поддомен, например `notify.your-domain.example`, особенно если основной домен уже принимает корпоративную почту.
{% endstep %}

{% step %}

### Создайте рабочий адрес поддержки

Проверьте, что письма и ответы действительно принимает сотрудник или служба поддержки. Сервис транзакционной отправки сам по себе может не принимать входящую почту.
{% endstep %}

{% step %}

### Опубликуйте записи провайдера

Добавьте только те MX, SPF, DKIM и проверочные записи, которые показаны для вашего аккаунта и домена. На одном hostname должна быть одна итоговая SPF-запись.
{% endstep %}

{% step %}

### Введите DMARC контролируемо

Начните с наблюдения, проверьте отчёты и только затем усиливайте политику. Не включайте строгий отказ до проверки всех законных отправителей домена.
{% endstep %}

{% step %}

### Подтвердите результат

Провайдер должен показать домен как проверенный. В заголовках контрольного письма SPF и DKIM должны проходить проверку, а DMARC — давать ожидаемый результат.
{% endstep %}
{% endstepper %}

Подробная подготовка разобрана в уроке [«Почтовый домен и DNS»](/learn/email/04-email-foundation.md).

## 2. Настройте общие параметры iEXExchanger

Откройте **«Настройки» — «Общие настройки» — «Уведомления» — «Общие параметры»**.

{% stepper %}
{% step %}

### Укажите E-mail службы поддержки

Введите контролируемый адрес для связи с клиентами. Не подставляйте сюда SMTP-сервер или технический логин.
{% endstep %}

{% step %}

### Укажите адреса администраторов

Добавьте действующих получателей служебных писем. После сохранения проверьте, что каждый адрес распознан отдельно.
{% endstep %}

{% step %}

### Включите отправку уведомлений

Главный переключатель разрешает новые отправки во всех каналах. Если он выключен, одно включённое почтовое подключение ничего не отправит.
{% endstep %}

{% step %}

### Включите E-mail-канал

Разрешите уведомления по E-mail и сохраните форму. После обновления страницы значения должны остаться включёнными.
{% endstep %}
{% endstepper %}

## 3. Выберите почтовый провайдер

{% tabs %}
{% tab title="Zoho Mail" %}
Подходит, если Zoho принимает корпоративную почту и должен отправлять уведомления через SMTP. Понадобятся рабочий ящик, сервер из **Server Configuration Details**, порт, шифрование и пароль приложения.

Перейдите к полной инструкции [«Zoho Mail через SMTP»](/learn/email/05-email-zoho.md).
{% endtab %}

{% tab title="Resend" %}
Подходит для транзакционной отправки через встроенный API-драйвер. Понадобятся подтверждённый домен, API-ключ с правом отправки, From и имя отправителя. SMTP-хост, порт и логин в этом режиме не используются.

Перейдите к полной инструкции [«Resend через API»](/learn/email/06-email-resend.md).
{% endtab %}

{% tab title="Другой SMTP" %}
Подходит для Google Workspace, Yandex 360, Microsoft 365 при разрешённом SMTP AUTH, SendGrid, Amazon SES и других совместимых relay. Понадобятся параметры именно вашего аккаунта.

Используйте [универсальную схему SMTP](/learn/email/07-email-providers.md).
{% endtab %}
{% endtabs %}

{% hint style="danger" %}
Не ослабляйте 2FA и корпоративную политику ради подключения. Используйте пароль приложения, отдельные SMTP credentials или API-ключ с минимальными правами. Не публикуйте секрет в документации, GitHub, переписке или снимке экрана.
{% endhint %}

## 4. Создайте подключение

Откройте **«Подключения»**, нажмите **«Добавить»** и выберите тип.

### SMTP

| Поле               | Что указать                                           |
| ------------------ | ----------------------------------------------------- |
| Название           | Понятное внутреннее имя подключения                   |
| SMTP-server        | Host из панели провайдера                             |
| Порт               | Порт, соответствующий выбранному шифрованию           |
| Шифрование         | TLS, SSL или разрешённый внутренний режим             |
| Логин              | Полный E-mail или выданный SMTP username              |
| Пароль             | Пароль приложения, SMTP password или разрешённый ключ |
| E-mail отправителя | Подтверждённый ящик или разрешённый alias             |
| Имя отправителя    | Публичное название обменного пункта                   |

Часто используются `587 + TLS` или `465 + SSL`, но окончательные значения берите в текущем аккаунте провайдера.

### Resend

| Поле               | Что указать                                |
| ------------------ | ------------------------------------------ |
| Название           | Понятное внутреннее имя подключения        |
| API-ключ           | Ключ с минимальным правом отправки         |
| E-mail отправителя | Адрес подтверждённого домена или поддомена |
| Имя отправителя    | Публичное название обменного пункта        |

Пустое поле секрета при обычном редактировании сохраняет уже записанное значение. Вводите новый секрет только при плановой ротации.

## 5. Назначьте события, получателей и приоритет

Внутри подключения включите только события, которые должны идти именно этим маршрутом.

{% stepper %}
{% step %}

### Выберите событие

Начните с одного события контрольной заявки, например создания заявки или изменения её статуса. Не включайте весь каталог до проверки.
{% endstep %}

{% step %}

### Выберите аудиторию

Разделяйте клиента, администраторов и других поддерживаемых получателей. Адрес поддержки не означает автоматическую доставку административных событий.
{% endstep %}

{% step %}

### Назначьте приоритет

Высокий приоритет оставляйте для событий, требующих быстрой реакции. Обычные информационные письма не должны вытеснять критические уведомления.
{% endstep %}

{% step %}

### Исключите дубли

Проверьте то же событие во всех SMTP- и Resend-подключениях. Если оно включено дважды для одной аудитории, ожидайте две независимые отправки.
{% endstep %}
{% endstepper %}

Полная маршрутизация описана в уроке [«События, получатели и приоритет»](/learn/email/02-events-routing.md).

## 6. Проверьте доставку по всей цепочке

{% tabs %}
{% tab title="Проверка подключения" %}
Проверяет соединение и учётные данные подключения. Отправьте письмо на отдельный контрольный адрес, откройте входящие и спам, затем проверьте заголовки.
{% endtab %}

{% tab title="Проверка события" %}
Создайте новую контрольную заявку и вызовите выбранное событие. Эта проверка подтверждает переключатели, событие, аудиторию, очередь, шаблон и фактический маршрут.
{% endtab %}

{% tab title="Проверка провайдера" %}
Найдите отправку в журнале Zoho, Resend или другого сервиса. Отличайте принятие сообщения провайдером от доставки в конечный ящик.
{% endtab %}
{% endtabs %}

Проверяйте по порядку:

1. главный переключатель уведомлений;
2. E-mail-канал;
3. состояние подключения;
4. выбранное событие и аудиторию;
5. работу очереди и планировщика;
6. журнал iEXExchanger;
7. журнал провайдера;
8. входящие и спам конечного получателя.

Подробный рабочий контроль находится в уроке [«Проверка доставки и очередей»](/learn/email/03-delivery-operations.md).

## После обновления со старой системы

1. Не удаляйте перенесённые настройки до сверки.
2. Зафиксируйте прежний адрес поддержки и административных получателей.
3. Сверьте число созданных SMTP-, Resend- и Telegram-подключений.
4. Проверьте, что секреты помечены как заполненные, не раскрывая их.
5. Сверьте события, аудитории и приоритет каждого подключения.
6. Удалите случайное дублирование одного события только после проверки.
7. Повторите проверку подключения и события.
8. Для периодических сводок дождитесь их реального цикла и подтвердите получателя.

{% hint style="warning" %}
Состояние **«Стабильно»** подтверждает последнюю техническую проверку подключения, но не доказывает, что событие включено, очередь работает и письмо дошло адресату.
{% endhint %}

## Этап завершён, если

* [ ] используется единый раздел уведомлений;
* [ ] роли поддержки, административного получателя и отправителя разделены;
* [ ] домен подтверждён, SPF не продублирован, DKIM работает;
* [ ] выбран Zoho, Resend или совместимый SMTP без ослабления безопасности;
* [ ] подключение прошло техническую проверку;
* [ ] одно реальное событие дошло нужной аудитории;
* [ ] отправка найдена в журнале провайдера и в конечном ящике;
* [ ] одинаковое событие не создаёт непреднамеренный дубль;
* [ ] секреты не опубликованы и могут быть отозваны ответственным.

Вернитесь к [общим параметрам и подключениям](/learn/email/01-notification-center.md) или переходите к [созданию Telegram-бота](/learn/08-telegram-bot.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.iexexchanger.com/learn/email.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.