> 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/guide/uvedomleniya/uvedomlenie-po-e-mail/podklyuchenie-resend.md). # Подключение Resend Resend — сервис для отправки транзакционных писем через API. В iEXExchanger он подключается напрямую и не требует SMTP-сервера, порта, логина, SMTP-пароля или выбора шифрования. Для работы подключения используются: * API-ключ Resend; * E-mail отправителя; * имя отправителя; * состояние подключения. Тексты и шаблоны системных писем формирует iEXExchanger. Resend используется только для их отправки и доставки почтовым серверам получателей. {% hint style="info" %} Общие переключатели E-mail, адрес службы поддержки, адреса администраторов, список событий и их приоритеты настраиваются отдельно на странице «Уведомления по E-mail». В этой инструкции рассматриваются только подготовка Resend и создание подключения в iEXExchanger. {% endhint %} {% content-ref url="/pages/OkKDfMApGsB2m3bvCsHg" %} [Уведомление по E-mail](/guide/uvedomleniya/uvedomlenie-po-e-mail.md) {% endcontent-ref %} ## Чем Resend отличается от SMTP Gmail, Yandex и Zoho подключаются к iEXExchanger через SMTP. Resend работает через HTTPS API: ``` api.resend.com ``` Поэтому для подключения типа **«Resend»** не требуются: * SMTP-сервер; * SMTP-порт; * SMTP-логин; * SMTP-пароль; * SSL или TLS для SMTP; * настройки почтового клиента. Также для стандартной отправки iEXExchanger не требуется отдельно настраивать в Resend: * Templates; * Contacts; * Broadcasts; * Automations; * Receiving; * Webhooks. Шаблоны писем остаются на стороне iEXExchanger. ## Что потребуется Перед настройкой подготовьте: * аккаунт Resend; * собственный домен или поддомен; * доступ к DNS-записям; * адрес отправителя; * доступ к административной панели iEXExchanger; * E-mail для получения тестового письма. Для рабочей отправки клиентам необходимо подтвердить собственный домен. Тестовый домен `resend.dev` подходит только для первоначальной проверки и имеет ограничения. *** ## Какой домен использовать Resend позволяет подтвердить основной домен или отдельный поддомен. | Вариант | Подтверждённый домен | Пример отправителя | | -------------------- | --------------------------- | ----------------------------------- | | Основной домен | `example.com` | `support@example.com` | | Поддомен уведомлений | `notifications.example.com` | `noreply@notifications.example.com` | | Почтовый поддомен | `mail.example.com` | `support@mail.example.com` | Для системных писем можно использовать, например: ``` notifications.example.com mail.example.com notify.example.com transactional.example.com ``` Использование отдельного поддомена позволяет отделить репутацию транзакционных писем от основного домена и других видов почтовой отправки. {% hint style="warning" %} Адрес отправителя должен соответствовать подтверждённому домену. Если в Resend подтверждён: `notifications.example.com` используйте адрес: `support@notifications.example.com` Адрес `support@example.com` в таком случае относится уже к другому домену и потребует отдельного подтверждения `example.com`. {% endhint %} Не регистрируйте специально для уведомлений похожий, но отдельный домен вида `example-notify.com`, если для этого нет отдельной необходимости. Такой адрес может быть менее понятен клиентам и выглядеть как сторонний домен. ## Создание аккаунта Resend Откройте: [Resend](https://resend.com/signup) Затем: 1. Создайте аккаунт. 2. Подтвердите E-mail, если Resend запросит это. 3. Создайте команду или выберите существующую. 4. Укажите понятное название проекта. Например: ``` Example Exchange ``` Если с Resend работают несколько сотрудников, добавляйте их отдельными участниками команды. Не передавайте нескольким сотрудникам один общий пароль от аккаунта. API-ключи, домены, лимиты и платёжные настройки относятся к соответствующей команде Resend. ## Добавление домена В панели Resend откройте: **Domains** Нажмите: **Add Domain** Затем: 1. Укажите домен или поддомен. 2. Выберите регион отправки. 3. Оставьте отправку писем включённой. 4. Добавьте домен. Получение входящих сообщений для обычного подключения iEXExchanger включать не требуется. ## Выбор региона Resend поддерживает несколько регионов отправки, среди которых: * North Virginia — `us-east-1`; * Ireland — `eu-west-1`; * São Paulo — `sa-east-1`; * Tokyo — `ap-northeast-1`. Регион влияет на инфраструктуру отправки и на DNS-параметры, которые Resend создаёт для домена. Для проекта с основной аудиторией в Европе можно выбрать Ireland. {% hint style="warning" %} Не копируйте MX или другие DNS-записи из инструкции для другого региона. Используйте только значения, которые Resend показывает в карточке вашего домена. {% endhint %} Если для проекта действуют отдельные требования к обработке персональных данных, выбор региона отправки не следует считать подтверждением того, что все данные Resend хранятся исключительно в этом регионе. Такие требования необходимо отдельно проверять по политике сервиса. ## Настройка DNS После добавления домена Resend покажет DNS-записи, необходимые для отправки. Обычно используются: * DKIM; * SPF; * MX для Return-Path; * дополнительные записи, если включены отдельные функции отслеживания. Не используйте DNS-значения из чужого проекта. {% content-ref url="/pages/p1Gm5iDWlX7fh95MUVut" %} [Файлы подтверждений](/guide/sait/faily-podtverzhdenii.md) {% endcontent-ref %} {% content-ref url="/spaces/uyjsNtEAtO6Sby8CHWyD/pages/43DGhWN1Ki1aj8RrllVR" %} [Настройка DNS](/help-center/administrirovanie/seti-i-bezopasnost/cloudflare/nastroika-dns.md) {% endcontent-ref %} Все имена, значения и регион берите непосредственно из карточки домена в Resend. ## DKIM DKIM используется для подтверждения подлинности исходящих писем. Resend предоставит TXT-запись с именем, похожим на: ``` resend._domainkey ``` Значение содержит длинный публичный ключ. Скопируйте его полностью. Не: * сокращайте значение; * добавляйте свои данные; * разбивайте ключ вручную; * удаляйте отдельные части. ## SPF SPF разрешает инфраструктуре Resend отправлять письма от имени настроенного домена. В Resend служебная SPF-запись обычно создаётся не в корне домена, а на поддомене `send`. Например, для: ``` example.com ``` может использоваться: ``` send.example.com ``` Для: ``` notifications.example.com ``` может использоваться: ``` send.notifications.example.com ``` Используйте точные имя и значение из интерфейса Resend. ## MX для Return-Path MX-запись Resend, создаваемая для отправки, используется для служебного Return-Path, обработки возвратов и других почтовых сигналов. Она обычно относится к служебному поддомену `send`. Например: ``` Основная почта: example.com Return-Path Resend: send.example.com ``` Поэтому использование Resend для отправки не требует переносить основную входящую почту в Resend. {% hint style="danger" %} Не удаляйте существующие MX-записи Google Workspace, Yandex, Zoho или другого почтового провайдера основного домена только ради подключения Resend. Для стандартной отправки iEXExchanger это не требуется. {% endhint %} ## Добавление DNS-записей Откройте сервис, в котором фактически управляется DNS-зона домена. Добавьте все записи, показанные Resend. После этого: 1. Сохраните изменения. 2. Вернитесь в Resend. 3. Откройте карточку домена. 4. Нажмите **Verify DNS Records**. 5. Дождитесь завершения проверки. При добавлении записей учитывайте особенности DNS-провайдера: * некоторые панели автоматически добавляют основной домен к имени записи; * вместо `send.example.com` может требоваться только `send`; * длинный DKIM необходимо копировать полностью; * не добавляйте лишние кавычки; * не добавляйте лишние пробелы; * следите, чтобы домен не продублировался в имени записи. Если используется Cloudflare и Resend требует CNAME, такую запись следует оставить в режиме **DNS only**, если Resend не указывает иной вариант. Обновление DNS может занять некоторое время. ## Состояния домена В Resend могут отображаться разные состояния.
СостояниеЧто означает
Not startedПроверка ещё не запускалась
PendingResend ожидает DNS-записи
VerifiedДомен подтверждён
Partially verifiedПодтверждена только часть настроек
FailedНеобходимые записи не были подтверждены
Temporary failureРанее подтверждённая запись временно перестала определяться
Для рабочего подключения домен должен иметь подтверждённую возможность отправки. Если отображается `Failed`, исправьте DNS и повторите проверку. Если ранее работавший домен получил `Temporary failure`, проверьте, не были ли его DNS-записи изменены или удалены. ## DMARC После успешной настройки SPF и DKIM рекомендуется добавить DMARC. DMARC определяет правила обработки писем, которые не прошли проверку подлинности. На первом этапе можно использовать политику наблюдения. Пример: ``` Имя: _dmarc Тип: TXT Значение: v=DMARC1; p=none; rua=mailto:dmarc@example.com; ``` Адрес после `rua=` должен существовать и принимать отчёты. {% hint style="warning" %} Не включайте сразу строгую политику `p=reject`, если с домена одновременно отправляют Gmail, Zoho, Yandex, Resend или другие сервисы. Сначала убедитесь, что все законные источники правильно настроены. {% endhint %} После анализа отчётов можно постепенно переходить к более строгой политике. ## Создание API-ключа После подтверждения домена откройте в Resend: **API Keys** Нажмите: **Create API Key** Затем: 1. Укажите название. 2. Выберите право **Sending access**. 3. Ограничьте ключ нужным доменом, если такая возможность доступна. 4. Создайте ключ. 5. Сразу скопируйте его. Для production можно использовать название: ``` iEXExchanger Production ``` Для тестовой среды: ``` iEXExchanger Staging ``` API-ключ начинается с: ``` re_ ``` Например: ``` re_xxxxxxxxxxxxxxxxxxxxxxxxx ``` Для обычного подключения iEXExchanger право **Full access** не требуется. Достаточно права отправки. {% hint style="danger" %} Полный API-ключ показывается только при создании. Если ключ потерян, получить его повторно через Resend нельзя. Создайте новый ключ. {% endhint %} ## Создание подключения в iEXExchanger В панели управления откройте: **«Настройки» — «Общие настройки» — «Уведомления» — «Подключения»**
Затем: 1. Нажмите **«Добавить»**. 2. В поле **«Тип подключения»** выберите **«Resend»**. 3. Укажите название. 4. Нажмите **«Создать»**. 5. Найдите подключение в таблице. 6. Нажмите на его название. Новое подключение создаётся как выключенный черновик. ## Настройки Resend Заполните поля: | Поле | Значение | | -------------------------- | ---------------------------------------------- | | **«Название»** | Понятное внутреннее название | | **«API-ключ»** | Ключ `re_...` из Resend | | **«E-mail отправителя»** | Адрес на подтверждённом домене | | **«Имя отправителя»** | Название обменного пункта или службы поддержки | | **«Подключение включено»** | Включите после успешного теста | Для подключения типа **«Resend»** отсутствуют и не требуются: * SMTP-сервер; * порт; * логин; * SMTP-пароль; * выбор SMTP-шифрования. ## Пример для основного домена Если в Resend подтверждён: ``` example.com ``` можно использовать: ``` Название: Resend — Example Exchange E-mail отправителя: support@example.com Имя отправителя: Example Exchange ``` API-ключ укажите в соответствующем поле. ## Пример для поддомена Если подтверждён: ``` notifications.example.com ``` используйте адрес на этом же поддомене. Например: ``` Название: Resend — системные письма E-mail отправителя: noreply@notifications.example.com Имя отправителя: Example Exchange ``` ## E-mail отправителя После подтверждения домена Resend позволяет использовать адреса на этом домене. Если подтверждён: ``` example.com ``` можно использовать, например: ``` support@example.com notifications@example.com noreply@example.com ``` Отдельно создавать каждый такой адрес внутри Resend не требуется. При этом Resend не создаёт полноценный почтовый ящик для получения ответов. ## Если клиенты должны отвечать на письма Если используется: ``` support@example.com ``` и вы хотите получать ответы клиентов, создайте настоящий почтовый ящик у используемого почтового провайдера. Например: * Google Workspace; * Yandex; * Zoho Mail; * другой почтовый сервис. При этом входящие MX-записи основного домена могут оставаться у этого провайдера, а Resend использоваться только для исходящей отправки. Если ответы не обрабатываются, можно использовать адрес вида: ``` noreply@example.com ``` или: ``` noreply@notifications.example.com ``` В этом случае обязательно укажите рабочий адрес поддержки в общей настройке E-mail-уведомлений, если он должен отображаться клиентам. ## Проверка подключения До успешной проверки оставьте **«Подключение включено»** выключенным. В форме найдите: **«E-Mail для проверки»** Затем: 1. Укажите адрес, к которому у вас есть доступ. 2. Нажмите **«Отправить тест»**. 3. Дождитесь результата. 4. Проверьте «Входящие». 5. Проверьте «Спам». 6. Проверьте другие категории почтового клиента, если они используются. 7. Откройте Resend Dashboard. 8. Перейдите в **Emails**. 9. Найдите тестовое письмо. 10. Проверьте его состояние. Если всё работает: 1. Вернитесь в iEXExchanger. 2. Включите **«Подключение включено»**. 3. Нажмите **«Сохранить»**. Кнопка **«Отправить тест»** сохраняет текущую конфигурацию и выполняет реальную отправку. Обычная кнопка **«Сохранить»** сохраняет подключение без тестового письма. *** ## Тестирование через resend.dev До подтверждения собственного домена Resend предоставляет тестового отправителя: ``` onboarding@resend.dev ``` Он предназначен только для первоначального тестирования. Такой адрес может отправлять письма только на E-mail, связанный с аккаунтом Resend. Попытка отправить письмо клиенту или на другой произвольный адрес будет отклонена. Для теста можно использовать: ``` E-mail отправителя: onboarding@resend.dev E-Mail для проверки: E-mail владельца аккаунта Resend ``` Для production: 1. Подтвердите собственный домен. 2. Создайте API-ключ. 3. Ограничьте его нужным доменом. 4. Укажите E-mail своего домена. 5. Повторите тест. 6. Только после этого включите рабочее подключение. ## Проверка доставки в Resend В Resend откройте: **Emails** Для каждого сообщения отображаются данные отправки и история доставки. Основные состояния: | Состояние | Что означает | | ------------------ | ---------------------------------------------- | | `Queued` | Письмо ожидает отправки | | `Sent` | Resend передал письмо | | `Delivered` | Сервер получателя принял письмо | | `Delivery delayed` | Доставка временно задержана | | `Bounced` | Сервер получателя отклонил письмо | | `Failed` | Отправка завершилась ошибкой | | `Suppressed` | Адрес находится в списке подавления | | `Complained` | Получатель сообщил о спаме | | `Opened` | Зафиксировано открытие при включённом tracking | | `Clicked` | Зафиксирован переход при включённом tracking | {% hint style="info" %} `Delivered` означает, что почтовый сервер получателя принял письмо. Это не гарантирует, что оно находится именно во «Входящих». Получающий сервис может переместить его в спам или другую категорию. {% endhint %} Для дополнительной диагностики откройте письмо и используйте связанный журнал запроса, если он доступен. Для стандартного подключения iEXExchanger webhook Resend не требуется. ## Возвраты и Suppression List Если адрес не существует или почтовый сервер окончательно отклоняет сообщение, возникает постоянный возврат. После таких возвратов или жалоб на спам Resend может добавить адрес в **Suppression List**. Следующие сообщения на такой адрес не отправляются и получают состояние: ``` Suppressed ``` Это помогает защищать репутацию отправителя. Не удаляйте адрес из Suppression List без выяснения причины. Сначала убедитесь, что: * исправлена опечатка; * почтовый ящик существует; * клиент подтвердил адрес; * проблема на стороне принимающего сервера устранена. Если причина не устранена, следующий постоянный возврат снова приведёт к подавлению адреса. ## Лимиты Resend Ограничения зависят от используемого тарифа. В исходной конфигурации бесплатного плана могут применяться ограничения по: * количеству писем в сутки; * месячной квоте; * количеству собственных доменов; * частоте API-запросов. Актуальные значения проверяйте непосредственно в Resend: **Settings — Usage** и в официальной документации сервиса. Каждый получатель в `To`, `CC` или `BCC` может учитываться в объёме отправки отдельно. API-лимит относится к команде Resend и может совместно использоваться всеми API-ключами этой команды. Если лимит превышен, API может вернуть ошибку `429`. ## Репутация нового домена Новый домен не рекомендуется сразу использовать для резкого большого объёма отправки. Увеличивайте количество сообщений постепенно. Для системных писем рекомендуется: * отправлять только ожидаемые уведомления; * не использовать купленные базы адресов; * удалять недействительные E-mail; * следить за возвратами; * контролировать жалобы; * не отправлять повторно на заведомо неработающие адреса; * регулярно проверять **Emails** и журналы Resend. Если растёт количество возвратов или жалоб, не увеличивайте объём до устранения причины. ## Open Tracking и Click Tracking Отслеживание открытий и переходов не требуется для работы iEXExchanger. При включении Open Tracking Resend добавляет технический элемент, позволяющий определить открытие письма. При включении Click Tracking ссылки могут проходить через систему отслеживания Resend. Для системных писем, содержащих: * подтверждение E-mail; * восстановление доступа; * персональные ссылки; * другие защищённые URL, включайте tracking только при реальной необходимости и после проверки поведения всех ссылок. ## Что не требуется настраивать {% stepper %} {% step %} ### Receiving Получение входящих сообщений Resend не требуется для стандартной работы iEXExchanger. Если основная почта уже работает через Gmail, Yandex, Zoho или другой сервис, не меняйте её корневые MX-записи ради подключения Resend. {% endstep %} {% step %} ### Webhooks Для стандартной отправки через подключение **«Resend»** webhook не требуется. Не создавайте webhook только ради отправки системных писем. {% endstep %} {% step %} ### Templates Шаблоны системных писем формирует iEXExchanger. Создавать их копии в Resend не требуется. {% endstep %} {% step %} ### Contacts и Broadcasts Эти разделы используются для других сценариев и не участвуют в обычных системных уведомлениях iEXExchanger. {% endstep %} {% step %} ### SMTP Resend также может предоставлять SMTP-возможности, но подключение iEXExchanger с типом **«Resend»** работает через API. SMTP-параметры для него не используются. {% endstep %} {% endstepper %} ## Изменение API-ключа После сохранения iEXExchanger не показывает полный API-ключ. В форме отображается только защищённое значение. При повторном открытии: * пустое поле **«API-ключ»** оставляет сохранённый ключ без изменений; * новое значение заменяет существующий ключ. Если вы изменяете только имя или E-mail отправителя, повторно вводить API-ключ не требуется. ## Безопасная замена API-ключа Если нужно заменить действующий ключ без остановки отправки: 1. Создайте новый API-ключ в Resend. 2. Выберите **Sending access**. 3. Ограничьте его тем же доменом. 4. Откройте подключение в iEXExchanger. 5. Укажите новый ключ. 6. Выполните **«Отправить тест»**. 7. Проверьте состояние письма в Resend. 8. Убедитесь, что отправка работает. 9. Сохраните подключение. 10. Только после этого удалите старый ключ в Resend. {% hint style="warning" %} Не удаляйте старый рабочий API-ключ до успешной проверки нового. {% endhint %} ## Защита API-ключа API-ключ предоставляет доступ к отправке через ваш аккаунт Resend. Не: * отправляйте его в мессенджерах; * публикуйте в документации; * размещайте на скриншотах; * добавляйте в клиентский JavaScript; * сохраняйте в публичном Git-репозитории; * передавайте подрядчикам без необходимости. Если ключ стал известен постороннему лицу: 1. Создайте новый ключ. 2. Замените его в iEXExchanger. 3. Проверьте отправку. 4. Удалите скомпрометированный ключ. ## Доступ к Resend Dashboard Участники команды Resend могут видеть данные отправленных писем и диагностическую информацию. Предоставляйте доступ только сотрудникам, которым он действительно необходим. Не создавайте публичные ссылки на письма, содержащие: * данные клиентов; * реквизиты; * ссылки безопасности; * персональные данные; * другую чувствительную информацию. ## Ошибка API-ключа Если Resend сообщает об ошибке авторизации, проверьте: * ключ скопирован полностью; * сохранён префикс `re_`; * отсутствуют лишние пробелы; * ключ не был удалён; * ключ создан в правильной команде; * используется актуальное значение. При необходимости создайте новый ключ и повторите тест. ## Ошибка `403` при использовании resend.dev Адрес: ``` onboarding@resend.dev ``` может использоваться только для ограниченного тестирования. Для отправки клиентам подтвердите собственный домен и замените отправителя. ## Ошибка `403` из-за домена Сравните подтверждённый домен и **«E-mail отправителя»**. Неправильно: ``` Подтверждён: notifications.example.com Отправитель: support@example.com ``` Правильно: ``` Подтверждён: notifications.example.com Отправитель: support@notifications.example.com ``` Если API-ключ ограничен конкретным доменом, убедитесь, что отправитель относится именно к нему. ## Домен не подтверждается Проверьте: * добавлены ли все записи, показанные Resend; * записи находятся у фактического DNS-провайдера; * имя домена не продублировано; * DKIM скопирован полностью; * MX соответствует выбранному региону; * DNS-панель не изменила имя или значение записи; * изменения DNS успели распространиться. После исправления повторно запустите проверку домена. ## Ошибка `429` Ошибка означает превышение одного из действующих ограничений. Проверьте: * частоту API-запросов; * суточную квоту; * месячную квоту; * другие приложения, использующие ту же команду Resend. Откройте: **Settings — Usage** и журналы Resend, чтобы определить причину. ## Тест отправлен, но письмо не пришло Откройте **Emails** в Resend и проверьте состояние. Если отображается: **`Delivered`** — сервер получателя принял письмо. **`Delivery delayed`** — доставка временно задержана. **`Bounced`** — принимающий сервер отклонил письмо. **`Suppressed`** — адрес находится в Suppression List. **`Failed`** — отправка завершилась ошибкой. Дополнительно проверьте папки «Спам» и другие категории почтового клиента. ## Письма попадают в спам Проверьте: * домен имеет состояние `Verified`; * SPF подтверждён; * DKIM подтверждён; * DMARC настроен корректно; * E-mail отправителя соответствует подтверждённому домену; * объём отправки не вырос резко; * отсутствует большое количество недействительных адресов; * домен не используется для нежелательных рассылок. Успешный статус API не гарантирует попадание письма во «Входящие». ## Ответы клиентов не приходят Resend позволяет отправлять письмо с адреса подтверждённого домена, но не создаёт для него почтовый ящик. Если клиент должен иметь возможность ответить на: ``` support@example.com ``` создайте этот ящик у отдельного почтового провайдера. Если используется `noreply`, укажите отдельный рабочий адрес службы поддержки в общих настройках E-mail. ## Тест работает, но обычные уведомления не отправляются Если **«Отправить тест»** работает, API-подключение уже настроено. Проверьте в iEXExchanger: * включено ли **«Подключение включено»**; * сохранено ли подключение; * включена ли **«Отправка уведомлений»**; * включены ли **«Уведомления по E-mail»**; * включено ли нужное событие для Resend; * сохранены ли настройки событий; * существует ли корректный получатель. Не меняйте API-ключ без причины, если тестовая отправка проходит успешно. ## Завершение настройки E-mail После успешного тестирования Resend откройте общую страницу «Уведомления по E-mail». {% content-ref url="/pages/OkKDfMApGsB2m3bvCsHg" %} [Уведомление по E-mail](/guide/uvedomleniya/uvedomlenie-po-e-mail.md) {% endcontent-ref %} Настройте: * **«Отправка уведомлений»**; * **«Уведомления по E-mail»**; * **«E-Mail адрес службы поддержки»**; * **«E-Mail адреса администраторов»**; * клиентские события; * административные события; * приоритеты уведомлений. Рабочее API-подключение не включает системные события автоматически. ## Проверка настройки Подключение Resend настроено правильно, если: * создан аккаунт Resend; * выбран собственный домен или поддомен; * домен подтверждён; * DNS-записи Resend добавлены; * существующая входящая почта не нарушена; * создан API-ключ с правом отправки; * ключ ограничен нужным доменом, если это используется; * **«E-mail отправителя»** соответствует подтверждённому домену; * указано **«Имя отправителя»**; * тестовое письмо успешно отправлено; * в Resend проверен результат доставки; * подключение включено; * настройки подключения сохранены; * включены необходимые события; * включены общие E-mail-параметры; * контролируются возвраты и Suppression List; * API-ключ хранится в защищённом виде. После успешной проверки Resend готов использоваться как API-подключение для E-mail-уведомлений iEXExchanger.