<b>Resend: когда email-слой нужен разработчику, а не маркетологу</b>

<b>Resend: когда email-слой нужен разработчику, а не маркетологу</b>

Resend закрывает типичную боль: отправка писем из продукта без тяжёлого SMTP-админа и бесконечных «почему не дошло». Для веб-команд это обычно транзакционные письма: регистрация, сброс пароля, уведомления, инвойсы, webhooks в почту.

На что смотреть до интеграции:
— поддержка шаблонов и переменных без ручной сборки MIME;
— доменная аутентификация: SPF, DKIM, DMARC;
— лог доставки и поиск по message ID;
— отдельные ключи для dev/stage/prod;
— webhooks по событиям доставки и отказов.

Главная ошибка — считать email «просто отправкой». На деле ломается не код, а инфраструктура: неправильный From, невалидный домен, одинаковые письма из нескольких окружений, отсутствие rate limit на массовые триггеры. Если сервис не даёт нормальный аудит, дебаг превращается в угадайку.

Ещё один момент: проверь, как у него устроены batch-рассылки, suppression list и retry-логика. Для SaaS это важнее красивого SDK. Хороший сервис не только шлёт письма, но и помогает не отправлять повторно то, что уже упало в спам или было отклонено.

Если email в проекте уже стал бизнес-функцией, а не утилитой — выбирай сервис с наблюдаемостью, раздельными окружениями и понятной обработкой ошибок.