Редакция PLPB ·
Как протестировать письма Resend до запуска: доставка, bounce и жалоба
Пошагово проверьте доставку, bounce и жалобу на спам в Resend: тестовые адреса, журнал событий, webhook и финальный чек-лист.


Сервисы и инструменты
Resend
Доступные варианты в каталоге
- Resend PRO на 1 год6 999 ₽
Зачем проверять сценарии до запуска
Одного успешного ответа API недостаточно, чтобы проверить всю цепочку письма. Приложение может отправить запрос, но не обработать отказ или жалобу на спам. В Resend можно прогнать такие исходы на специальных адресах и проверить, как на них реагируют журнал отправок и ваш webhook, не используя почту реального получателя. Этот набор подходит для проверки интеграции и обработки событий; он не заменяет тест в настоящем почтовом ящике.
Четыре тестовых адреса Resend
В актуальной базе знаний Resend перечислены адреса для четырёх исходов:
delivered@resend.dev — сценарий успешной доставки.bounced@resend.dev — отказ принимающего почтового сервера. Для этого исхода Resend указывает SMTP-ответ 550 5.1.1 (Unknown User).complained@resend.dev — письмо помечается как спам.suppressed@resend.dev — отправка подавляется.Это адреса для симуляции, а не почтовые ящики. Resend указывает, что тест позволяет проверять поток без риска для репутации отправляющего домена. Для различения прогонов большинству таких адресов можно добавить метку после +: например, bounced+signup@resend.dev. Ограничение: адрес suppressed@resend.dev пока не поддерживает метки. Полный перечень смотрите в актуальной базе знаний Resend о тестовых адресах; у сценария bounce также есть описание SMTP-кода.
Отправьте одно письмо из приложения
Для контрольной отправки используйте ту же серверную функцию и шаблон, что и в приложении, но замените адрес получателя на тестовый. Так проверяется реальная интеграция с API, а не только локальный рендер письма. Например, для Node.js SDK:
import { Resend } from 'resend'
const apiKey = process.env.RESEND_API_KEY
const from = process.env.RESEND_FROM
if (!apiKey || !from) {
throw new Error('Set RESEND_API_KEY and RESEND_FROM on the server')
}
const resend = new Resend(apiKey)
const { data, error } = await resend.emails.send({
from,
to: ['delivered@resend.dev'],
subject: 'Проверка письма перед запуском',
html: '<p>Проверка шаблона и обработки события.</p>',
})
if (error) {
throw new Error(`Resend API error: ${error.message}`)
}
console.log('Resend email id:', data?.id)Ключ передаётся серверному коду из переменной окружения; не вставляйте его во frontend и не выводите его значение в лог. Resend отдельно рекомендует хранить ключи в переменных окружения и не помещать их в клиентский код — см. инструкцию по безопасному обращению с API-ключами. В примере используется структура запроса из API-документации Resend. RESEND_FROM задайте адресом отправителя, допустимым для вашего аккаунта. Для рабочих отправок Resend требует добавить и подтвердить собственный домен; тестовый получатель эту настройку не проверяет. Требование описано в руководстве о подтверждённых доменах.
Положительный результат вызова — лишь начало проверки: сохраните ID, который вернул API, и найдите соответствующее событие. Не считайте наличие ID подтверждением того, что письмо появилось в личном почтовом ящике. Тестовый адрес моделирует исход, а не открывает настоящий inbox.
Проверьте обработку четырёх исходов
Отправьте один и тот же тестовый шаблон по очереди на каждый специальный адрес. Между отправками меняйте только получателя. В журнале приложения сохраните ID запроса и результат, чтобы сопоставить их с событиями Resend.
delivered@resend.dev убедитесь, что приложение сохраняет успешный исход и не показывает пользователю ошибку.bounced@resend.dev проверьте, что обработчик фиксирует bounce и не запускает бесконечные повторы. В документации описан ответ 550 5.1.1; проверьте, как ваше приложение показывает или обрабатывает такую причину.complained@resend.dev убедитесь, что событие попадает в нужный обработчик и ваш код не продолжает обычную цепочку писем этому адресу.suppressed@resend.dev проверьте, что система распознаёт подавленную отправку и не считает её обычной доставкой.Чтобы событие дошло до приложения, заранее зарегистрируйте публичный URL webhook и выберите нужные типы событий в Dashboard; Resend отправляет события POST-запросами на зарегистрированный адрес. Это отдельный шаг настройки, а не результат вызова emails.send. В руководстве по вебхукам приведён пример обработки email.delivered. Кроме того, с изменением от 22 января 2026 года Resend документирует отдельное событие для каждого результата доставки и получателя. Если один запрос включает несколько адресов, связывайте состояние с конкретным получателем, а не только с общим ID письма. См. описание видимости событий вебхуков.
Что ещё проверить перед боевым отправлением
Тестовые адреса помогают проверить интеграцию и ветки обработки, но не показывают, как письмо выглядит в Gmail, Яндекс Почте или Outlook, попало ли оно во «Входящие» и корректно ли отображаются изображения. Для этого после подтверждения собственного домена отправьте одно контрольное письмо на доступный вам реальный адрес и проверьте HTML- и текстовую версии, ссылки, тему, имя отправителя и мобильный вид.
Перед включением письма для пользователей проверьте короткий список:
delivered, bounced, complained и suppressed;Если вы выбираете Resend для отправки писем из приложения, посмотреть страницу сервиса в каталоге можно по ссылке: Resend в каталоге PLPB.
Нужен доступ к сервису?
Выберите товар в каталоге, оформите заказ и оплатите его на сайте. Дальнейшие шаги появятся в чате заказа.
Купить ResendВопросы: help@plpb.tech