Short answer: for a B2B SaaS signup flow spanning the US and EU, keep verification-link templates and their versions in the application, while delegating DKIM signing, suppression enforcement, bounce collection, and final delivery to an email API provider; choose provider-owned templates only when non-engineers must publish copy without an application release.
That split makes the awkward boundary visible. The application owns what the message means, which tenant and locale it belongs to, and which verification policy produced the link. The delivery layer owns mailbox-facing mechanics and recipient history. Combining those concerns in a hosted template editor looks tidy until a deployment, a regional failover, and a copy edit produce three different answers to the question, "what did we send?"
For this workload, deliverability isn't a single score. It is a chain of evidence: authenticated domain, stable message construction, enforceable suppression, observable delivery events, and a reset flow that remains secure when an email arrives late or twice.
Start with the signup constraint, not the sending feature
A verification message is transactional, but that label doesn't make it privileged. The receiving system still evaluates authentication and sender behavior, and Google explicitly requires sender authentication; its published guidance also distinguishes requirements for all senders from the additional requirements applied to bulk senders. A custom domain therefore belongs in the initial design, not in a post-launch branding ticket. The exact DNS records and policy depend on the sending arrangement, but the acceptance test is plain: a message sent through each production path must authenticate as the domain the recipient sees.
