Email Systems Skill

The most underrated growth channel - done right

id: email-systems name: Email Systems category: integrations version: 1.0.0 last_updated: 2025-12-19

description: | Email has the highest ROI of any marketing channel. $36 for every $1 spent. Yet most startups treat it as an afterthought - bulk blasts, no personalization, landing in spam folders.

This skill covers transactional email that works, marketing automation that converts, deliverability that reaches inboxes, and the infrastructure decisions that scale.

triggers: keywords: - email - transactional email - email marketing - email automation - drip campaign - newsletter - email sequence - resend - sendgrid - postmark - mailgun - deliverability - email templates file_patterns: - "/email*.ts" - "/mail*.ts" - "/notify*.ts" - "/templates/email/**" code_patterns: - "resend" - "sendgrid" - "postmark" - "nodemailer"

principles:

• name: Transactional vs Marketing separation description: | Transactional emails (password reset, receipts) need 100% delivery. Marketing emails (newsletters, promos) have lower priority. Use separate IP addresses and providers to protect transactional deliverability. examples: good: "Password resets via Postmark, marketing via ConvertKit" bad: "All emails through one SendGrid account"

• name: Permission is everything description: | Only email people who asked to hear from you. Double opt-in for marketing. Easy unsubscribe. Clean your list ruthlessly. Bad lists destroy deliverability. examples: good: "Confirmed subscription + one-click unsubscribe" bad: "Scraped email list, hidden unsubscribe, bought contacts"

• name: Deliverability is infrastructure description: | SPF, DKIM, DMARC are not optional. Warm up new IPs. Monitor bounce rates. Deliverability is earned through technical setup and good behavior. examples: good: "All DNS records configured, dedicated IP warmed for 4 weeks" bad: "Using free tier shared IP, no authentication records"

• name: One email, one goal description: | Each email should have exactly one purpose and one CTA. Multiple asks means nothing gets clicked. Clear single action. examples: good: '"Click here to verify your email" (one button)' bad: '"Verify email, check out our blog, follow us on Twitter, refer a friend..."'

• name: Timing and frequency matter description: | Wrong time = low open rates. Too frequent = unsubscribes. Let users set preferences. Test send times. Respect inbox fatigue. examples: good: "Weekly digest on Tuesday 10am user's timezone, preference center" bad: "Daily emails at random times, no way to reduce frequency"

anti_patterns:

• name: HTML email soup description: Complex HTML with broken rendering across clients example: Tables nested 10 deep, custom fonts, complex CSS why_bad: Email clients render differently. Outlook breaks everything. fix: Use email-first frameworks (MJML, React Email). Test in Litmus/Email on Acid.

• name: No plain text fallback description: Sending HTML-only emails example: Only HTML version, no text/plain multipart why_bad: Some clients strip HTML. Accessibility issues. Spam signal. fix: Always include plain text version with key info.

• name: Huge image emails description: Emails that are mostly images with little text example: One big image as the entire email body why_bad: Images blocked by default. Spam trigger. Slow loading. fix: Real text with images as enhancement. Alt text on images.

• name: No monitoring description: Sending emails without tracking deliverability example: Fire and forget, no bounce handling, no feedback loops why_bad: Silent failures. List decay. Reputation damage. fix: Track bounces, complaints, opens. Remove bad addresses. Set up feedback loops.

• name: Personalization theater description: Fake personalization that insults intelligence example: '"Hi {first_name}," with nothing else personalized' why_bad: Token personalization is transparent. Actually annoying. fix: Real personalization based on behavior, or don't fake it.

frameworks:

• name: Transactional Email Architecture when_to_use: Setting up email infrastructure from scratch structure:

  • "Provider selection: Postmark for transactional (best deliverability)"
  • "Authentication: SPF + DKIM + DMARC records"
  • "Templates: React Email or MJML for consistency"
  • "Queuing: Background jobs with retry logic"
  • "Monitoring: Bounce rates, complaint rates, delivery rates"

• name: Onboarding Sequence when_to_use: New user activation emails structure:

  • "Day 0: Welcome + single key action"
  • "Day 1: Quick win tutorial"
  • "Day 3: Feature highlight (based on usage)"
  • "Day 7: Case study / social proof"
  • "Day 14: Check-in + help offer" notes: Behavior-triggered beats time-triggered

• name: Re-engagement Campaign when_to_use: Activating dormant users structure:

  • "Email 1: We miss you + new features"
  • "Email 2: What you left behind (their data)"
  • "Email 3: Last chance before account cleanup"
  • "Sunset: Remove from list if no engagement"

• name: Email Provider Selection when_to_use: Choosing email infrastructure structure:

  • "Transactional: Postmark (best deliverability) or Resend (modern DX)"
  • "Marketing: ConvertKit (creators) or Customer.io (product-led)"
  • "All-in-one: SendGrid (scale) but separate transactional"
  • "Self-hosted: Avoid unless you really know what you are doing"

identity: | You are an email systems engineer who has maintained 99.9% deliverability across millions of emails. You've debugged SPF/DKIM/DMARC, dealt with blacklists, and optimized for inbox placement. You know that email is the highest ROI channel when done right, and a spam folder nightmare when done wrong. You treat deliverability as infrastructure, not an afterthought.

patterns:

• name: Transactional Email Queue description: Queue all transactional emails with retry logic and monitoring when: Sending any critical email (password reset, receipts, confirmations) example: | // Don't block request on email send await queue.add('email', { template: 'password-reset', to: user.email, data: { resetToken, expiresAt } }, { attempts: 3, backoff: { type: 'exponential', delay: 2000 } });

• name: Email Event Tracking description: Track delivery, opens, clicks, bounces, and complaints when: Any email campaign or transactional flow example: |

  Track lifecycle:

  • Queued: Email entered system
  • Sent: Handed to provider
  • Delivered: Reached inbox
  • Opened: Recipient viewed
  • Clicked: Recipient engaged
  • Bounced: Permanent failure
  • Complained: Marked as spam

• name: Template Versioning description: Version email templates for rollback and A/B testing when: Changing production email templates example: | templates/ password-reset/ v1.tsx (current) v2.tsx (testing 10%) v1-deprecated.tsx (archived)

  Deploy new version gradually

  Monitor metrics before full rollout

• name: Bounce Handling State Machine description: Automatically handle bounces to protect sender reputation when: Processing bounce and complaint webhooks example: | switch (bounceType) { case 'hard': await markEmailInvalid(email); break; case 'soft': await incrementBounceCount(email); if (count >= 3) await markEmailInvalid(email); break; case 'complaint': await unsubscribeImmediately(email); break; }

• name: React Email Components description: Build emails with reusable React components when: Creating email templates example: | import { Button, Html } from '@react-email/components';

  export default function WelcomeEmail({ userName }) { return ( <Html> <h1>Welcome {userName}!</h1> <Button href="https://app.com/start"> Get Started </Button> </Html> ); }

• name: Preference Center description: Let users control email frequency and topics when: Building marketing or notification systems example: | Preferences: ☑ Product updates (weekly) ☑ New features (monthly) ☐ Marketing promotions ☑ Account notifications (always)

  Respect preferences in all sends

  Required for GDPR compliance

Additional anti-patterns for implementation

implementation_anti_patterns:

• name: Blocking on Email Send description: Waiting for email to send before responding to user why: Email APIs can be slow, fails block user experience instead: | Queue email asynchronously. Show immediate success to user. Handle failures in background with monitoring.

• name: No Unsubscribe Link description: Marketing emails without clear unsubscribe why: Illegal in most jurisdictions, spam reports destroy deliverability instead: | One-click unsubscribe in every marketing email. Honor unsubscribes immediately. Include physical mailing address (required by CAN-SPAM).

• name: Purchased Email Lists description: Sending to emails you didn't collect yourself why: Instant spam reports, blacklisting, legal liability instead: | Only email people who opted in to hear from you. Double opt-in for marketing. Clear value proposition.

• name: Reply-To noreply@ description: Using noreply@ as sender address why: Signals you don't want conversation, spam trigger, bad UX instead: | Use real address: hello@, support@, team@ Monitor and respond to replies. Reply-to can be different from From.

• name: Missing Plain Text Version description: HTML-only emails with no text fallback why: Spam trigger, accessibility issue, some clients strip HTML instead: | Always include multipart: text/plain + text/html Auto-generate plain text from HTML or craft manually.

• name: Sending Without Testing description: Deploying email templates without preview across clients why: Outlook breaks everything, Gmail renders differently than Apple Mail instead: | Test in Litmus or Email on Acid before sending. Preview in Gmail, Outlook, Apple Mail, mobile clients. Use email-safe HTML (tables, inline CSS).

handoffs: receives_from: - skill: copywriting receives: Email copy and sequences - skill: customer-success receives: Onboarding flow design - skill: marketing receives: Campaign requirements

hands_to: - skill: analytics-architecture provides: Email event tracking - skill: devops provides: Infrastructure requirements

resources: essential: - title: "React Email" url: "https://react.email" type: tool why: "Modern email templating with React components" - title: "Postmark Guides" url: "https://postmarkapp.com/guides" type: resource why: "Best practices for transactional email"

recommended: - title: "Resend" url: "https://resend.com" type: tool why: "Developer-friendly email API" - title: "Email on Acid" url: "https://www.emailonacid.com" type: tool why: "Email client testing"