send() returned true. The email never arrived. Following one email from your app to the inbox

Most apps treat send() === true as “delivered”. It isn’t. It only means your email provider accepted the message. The real trip starts after that, and that’s where most failures happen.

I followed one email through the whole route: a sign-up confirmation with a typo in the address.

The route

Stop 1 · App → provider (port 587): your app logs in, starts TLS and submits the message. send() returns true here.
Stop 2 · DNS: the provider’s MTA looks up the MX record of gmail.com to find which server receives mail for that domain.
Stop 3 · The SMTP conversation (port 25): EHLO, MAIL FROM, RCPT TO, DATA. The envelope decides delivery, not the To: header you see.
Stop 4 · The response code: 2xx accepted · 4xx temporary (defer and retry with backoff) · 5xx permanent (bounce, don’t retry).

What happened to our email
RCPT TO:[e-mail] → 550 5.1.1 user unknown.
The provider records a bounce and suppresses the address. Your app still thinks everything worked, unless it listens to bounce notifications (webhooks, SNS, etc.).

Takeaways

“Accepted” and “delivered” are different states. Store them separately.
Keep delivery events per message: delivered, deferred, bounced.
Never retry a 5xx. Retry a 4xx with backoff. RFC 5321 suggests at least 30 minutes between retries and giving up after 4–5 days.