ShippedTransactional email
Make email part of your application. Connect verified sending for the messages your users expect after they take an action.
Send from a domain you control
Verify your sending domain and add the required DNS authentication records before using it for application mail. Connect your app with scoped sending credentials instead of a general account secret. Use a recognizable sender and clear message content so people can understand why they received an invitation, recovery link, or notification from your product.
Build email into the user journey
Send account invitations, recovery messages, receipts, and other transactional notifications from your application’s workflow. Keep links tied to the correct environment and make sensitive tokens expire. For messages triggered by background work, record the sending intent so a retry can distinguish an unsent message from one already accepted for delivery.
Respect sending limits and recipients
Review sending quotas and usage before increasing volume. Bounce, complaint, and suppression handling help your application stop repeatedly contacting addresses that should not receive mail. Delivery also depends on recipient systems, domain reputation, and message content; build a useful recovery path in your product when a user cannot find the email they expected.
A little more detail
Questions about Transactional email?
Is this a mailbox for receiving and reading email?
No. Transactional email is application sending. It does not provide an employee inbox, a mail client, or general mailbox hosting.
Does successful sending guarantee an inbox delivery?
No. A sending service accepting a message is different from the recipient placing it in an inbox. Authentication, reputation, recipient filtering, and message content all affect delivery.
From your workspace to the web