A password reset flow has two separate trust decisions: can the service identify the account, and will the recipient's mail provider trust the message? I would keep those decisions in one operational boundary when the team wants one key and one bill for both backend services. A dedicated email provider is the better boundary when deliverability tooling, regional controls, or a mature template program matter more than shared ownership.

The important answer is direct: a weak sending-domain reputation makes a reset email more likely to land in spam or be rejected. Providers use domain reputation as part of spam scoring; repeated delivery attempts to invalid addresses damage that reputation, and missing SPF, DKIM, or DMARC records reduce trust.…