Email & Transactional Messaging

5.8.1Definition

Transactional email is any message triggered by a specific user action — a password reset, an order confirmation, a receipt — as opposed to marketing email sent in bulk on a schedule. Most products send transactional email through a dedicated provider (Resend, Postmark, SendGrid, Amazon SES) rather than a raw SMTP server, for the deliverability reasons below.

5.8.2Why It Exists

Email deliverability — actually reaching the inbox instead of spam — depends on sender reputation, authentication records, and infrastructure that took mailbox providers years to trust. Transactional email providers exist because building and maintaining that reputation from a fresh mail server is slow, fragile, and easily destroyed by a single sending mistake; providers arrive with reputation and infrastructure already established.

5.8.3Deliverability Fundamentals

• SPF, DKIM, DMARC — DNS records (1.7) that let receiving mail servers verify a message genuinely came from the domain it claims to, without which messages are far more likely to be marked spam.
• Dedicated vs. shared sending domain — high-volume senders benefit from a dedicated subdomain to isolate their reputation from other customers on the same provider.
• Bounce and complaint handling — actively removing hard-bounced or complained-about addresses, since continuing to send to them damages sender reputation for every future message.

5.8.4Common Mistakes

• Sending transactional email from an unauthenticated domain with no SPF/DKIM/DMARC records configured, causing password-reset emails to land in spam at unpredictable rates.
• Mixing marketing and transactional sending on the same reputation, so a marketing campaign's spam complaints degrade deliverability for critical password-reset and receipt emails.
• Sending emails synchronously inside the request that triggers them, slowing down the user-facing action and risking a failed send blocking the whole request (5.10).

5.8.5Best Practices

• Configure SPF, DKIM, and DMARC before sending a single production email.
• Send transactional email asynchronously via a queue (5.10), decoupled from the request that triggers it.
• Separate transactional and marketing sending domains/reputations where volume justifies it.