Почему Resend часто берут вместо «просто SMTP» — и где на нём ломаются

Почему Resend часто берут вместо «просто SMTP» — и где на нём ломаются

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

Но есть правило: сервис доставки не спасает плохую схему отправки. Если не настроены SPF, DKIM и домен-отправитель, письма будут попадать в спам или теряться. Второй частый промах — слать всё с одного адреса: отдельно держите парольные, уведомления и маркетинговые письма, иначе репутация домена смешается.

Ещё одна ошибка — не проверять idempotency и ретраи. При сбоях API письмо может уйти повторно, если приложение не защищено от дублей. И не забывайте про bounce/complaint события: без обработки webhooks список адресов быстро портится, а доставляемость падает 📩

Если нужен простой почтовый слой для продукта, Resend хорош как старт и как рабочая база. Но настройка домена, раздельные потоки писем и обработка статусов важнее самого провайдера.