Short answer: when password reset email retries are causing duplicate links, check suppression before each send, keep one active reset token per request window, and poll delivery events before retrying.

A password-reset incident rarely begins with the email provider. It begins with a retry decision that forgot what the first attempt already created. The practical fix is to make the reset token and the recipient decision independent: keep one active token for a user and request window, check suppression before every send, and inspect polled events for bounce, deferral, or complaint evidence. That makes a retry a controlled observation, not a second password-reset workflow.

For a media marketplace, the same boundary matters when an order notification is sent to a seller. The message template belongs to the product team; delivery state belongs to the messaging boundary.…