Messaging, Events and Email Systems · Asynchronous Workflows
Email Delivery Architecture
Send transactional and bulk email reliably and keep messages out of spam.
Send email asynchronously through a queue to an email provider (SES, SendGrid, Postmark, Mailgun). Separate transactional (receipts, resets) from marketing traffic (different streams/IPs/subdomains) so bulk issues don't hurt critical mail. Authenticate your domain with SPF, DKIM and DMARC, process bounce/complaint webhooks to suppress bad addresses, include one-click unsubscribe for bulk mail, and monitor delivery rates.
; DNS records for mail.example.com
mail.example.com. TXT "v=spf1 include:amazonses.com -all"
s1._domainkey.mail.example.com. CNAME s1.dkim.provider.net.
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]; adkim=s; aspf=s"
Flow: app → outbox/queue → mail worker → provider API → recipient
provider → webhook (delivered / bounced / complained) → suppression list
Common pitfalls
- Sending from the app request thread.
- Ignoring bounces and complaints (reputation damage).
- Mixing marketing and password-reset traffic.
Key points
- Queue + provider, never inline
- SPF, DKIM, DMARC
- Handle bounces; separate streams
Further reading: Cloudflare: SPF, DKIM and DMARC
Practice questions
What do SPF, DKIM and DMARC each do?
Answer
SPF lists servers allowed to send for a domain; DKIM signs messages so receivers verify integrity and domain; DMARC tells receivers how to handle failures and where to send reports, requiring alignment with the From domain.
Why separate transactional and marketing email streams?
Answer
Marketing mail has higher complaint rates; isolating it protects the sending reputation of critical transactional email like password resets.
Open in the app to mark lessons complete, take notes and track your progress.