Optimize Email Deliverability and Engagement

Covers the operational side of email - transactional delivery, marketing automation, deliverability, and infrastructure decisions - framed around the fact that email returns $36 for every $1 spent, yet most startups still send bulk blasts with no personalization. Five core principles anchor the guide: keep transactional and marketing email on separate providers/IPs (transactional needs 100% delivery, marketing tolerates lower priority), treat permission as non-negotiable (double opt-in, one-click unsubscribe, ruthless list hygiene), treat deliverability as infrastructure (SPF, DKIM, and DMARC DNS records, IP warm-up, bounce-rate monitoring), give every email exactly one goal and one CTA, and respect send timing and frequency via user-set preferences. Six implementation patterns follow: a transactional email queue with exponential-backoff retries, full lifecycle event tracking (queued/sent/delivered/opened/clicked/bounced/complained), versioned templates for safe rollback and A/B testing, a bounce-handling state machine (hard bounces invalidate immediately, soft bounces after 3 failures, complaints trigger instant unsubscribe), React Email components for building templates, and a preference center for frequency and topic control.

# Required DNS records:

TXT record: v=spf1 include:_spf.google.com include:sendgrid.net ~all
```

Use it when setting up or auditing an application's transactional and marketing email - onboarding sequences, password resets, receipts, campaigns - especially before scaling send volume, switching providers, or troubleshooting deliverability problems. It is not a copywriting or visual-design skill: the guide explicitly delegates subject-line and body copy to a copywriting skill, template visuals to ui-design, tracking dashboards to analytics-architecture, and queue/server infrastructure to devops. It documents ten "sharp edges" with severity ratings - missing SPF/DKIM/DMARC (critical), transactional email sharing a spam-flagged provider's IP (high), unprocessed bounce webhooks (high), hidden or missing unsubscribe links (critical), HTML-only emails with no plain-text part (medium), sending high volume from a fresh unwarmed IP (high), emailing non-opted-in contacts (critical), image-only emails (medium), missing preview text (medium), and unlogged bulk sends with no partial-failure recovery (high) - each paired with a concrete fix.

Inputs are the emails to send (transactional events like password resets, or marketing campaigns) plus provider credentials and DNS access for authentication records. Outputs are working code patterns: a queued send job (queue.add('email', {...}, {attempts: 3, backoff: {type: 'exponential', delay: 2000}})), a bounce webhook handler that marks addresses invalid or unsubscribes on complaint, a multipart send (HTML plus plain text) via Resend, and ten automated validation-check messages - such as "Email API key appears hardcoded in source code" at ERROR severity, or "Bulk email sending without apparent rate limiting" at WARNING - meant to be run against a codebase.

Names specific providers by role: Postmark or Resend for transactional email, ConvertKit or Customer.io for marketing, and React Email for template components; bounce and complaint handling is wired through provider webhooks. It hands off to four sibling skills - copywriting, ui-design, analytics-architecture, and devops - via explicit delegation triggers, and defines two multi-skill workflows: an "Email Marketing Stack" (infrastructure to templates to copy to campaign to tracking) and a "Transactional Email" flow (provider setup to template coding to queue integration to monitoring).

Backend and full-stack developers setting up or hardening an application's email infrastructure - deliverability, queuing, bounce handling, compliance - who will hand off copy and visual design to separate specialists rather than write the marketing prose themselves.