Guides

Resend-compatible SMTP relay setup

If your app already sends mail through `smtp.resend.com`, moving to Irisend's relay is a host-and-password change, not a rewrite — Irisend's SMTP server accepts `resend` as a username alias specifically so an existing config doesn't need its username touched.

1. 1.Swap the host and password only

   Everything else about the transport config stays the same: same two ports, same AUTH mechanism, same username if you don't want to change it.

   // Resend                                  // Irisend
   host: "smtp.resend.com",                    host: "smtp.irisend.com",
   auth: {                                     auth: {
     user: "resend",                             user: "resend", // unchanged — accepted as an alias
     pass: "re_xxxx",                             pass: "ir_xxxx", // your Irisend API key
   },                                           },

2. 2.Pick a port

   Both `465` (implicit TLS) and `587` (STARTTLS) are available, same as Resend's own relay. AUTH before STARTTLS, and MAIL/RCPT before AUTH, are both rejected outright — there is no plaintext-AUTH fallback on either port.

3. 3.Idempotency over SMTP

   Add an `Idempotency-Key` message header exactly like the REST API's header — the SMTP relay reads it straight off the parsed message and applies the same 24-hour, body-hash-checked dedupe.

   headers: { "Idempotency-Key": "welcome-email-user-42" }

4. 4.Know the rate limits before you go to production

   Failed AUTH attempts are throttled per source IP before the username/password are even checked, so a brute-force run costs one Redis round trip instead of a password hash and DB query per guess. Once authenticated, each accepted `DATA` transaction is charged against the same per-team requests-per-second budget the REST API enforces — so a burst over SMTP can't outrun what `POST /emails` would have blocked.