Email Best Practices

Postmark has delivered billions of transactional emails over 15+ years. This skill distills that expertise into actionable guidelines for building reliable, compliant, high-deliverability email systems.

Quick Reference

| Topic | Use When | |-------|----------| | Deliverability | Setting up SPF/DKIM/DMARC, warming a new domain, diagnosing delivery issues | | Compliance | Building unsubscribe flows, handling GDPR/CAN-SPAM/CASL requirements | | Transactional Design | Designing welcome emails, password resets, receipts, alerts | | List Management | Handling bounces, suppressions, list hygiene | | Testing | Testing safely without hurting sender reputation | | Sending Reliability | Idempotency, retry logic, rate limits |

Deliverability Fundamentals

The three authentication records every sending domain must have:

| Record | Purpose | Priority | |--------|---------|----------| | SPF | Authorizes servers to send as your domain | Required | | DKIM | Cryptographically signs emails to prove authenticity | Required | | DMARC | Policy for handling SPF/DKIM failures | Required |

With Postmark, DKIM is configured automatically when you verify a sender domain. SPF and DMARC must be set up in your DNS.

See references/deliverability.md for DNS setup, reputation factors, and domain warm-up guidance.

Transactional vs. Broadcast Email

Never mix transactional and broadcast email in the same sending stream. They have different delivery characteristics, compliance requirements, and reputation profiles.

| Type | Examples | Compliance | Unsubscribe Required | |------|----------|------------|---------------------| | Transactional | Password resets, receipts, alerts, notifications | CAN-SPAM exemption possible | No (but good practice) | | Broadcast | Newsletters, promotions, announcements | CAN-SPAM, GDPR, CASL apply | Yes — legally required |

Postmark enforces this separation with Message Streams — use outbound for transactional, broadcast for marketing.

See references/compliance.md for CAN-SPAM, GDPR, and CASL requirements.

Transactional Email Design

Good transactional emails are:

Expected — The recipient triggered this email
Timely — Sent immediately after the triggering event
Actionable — One clear call to action
Plain — Minimal design; content over decoration

Common transactional email types and their essential elements:

| Email Type | Must Include | Avoid | |-----------|--------------|-------| | Welcome | Product name, next step CTA, support contact | Marketing upsell on day 1 | | Password reset | Expiry time, ignore-if-not-you notice, support link | Long copy | | Receipt / Invoice | Line items, total, billing address, support | Promotional content | | Shipping notification | Tracking link, estimated delivery, items | Unrelated promotions | | Security alert | What happened, when, action required, how to secure | Panic-inducing language |

See references/transactional-design.md for design patterns, copy guidelines, and HTML email best practices.

List Health

Sending to invalid, inactive, or unengaged addresses is the leading cause of deliverability problems.

Key rules:

Remove hard bounces immediately and permanently
Suppress spam complaints immediately — never re-add
Re-permission lists older than 12–18 months before mailing
Never purchase or rent email lists
Validate addresses at the point of collection

See references/list-management.md for suppression strategies, list hygiene schedules, and re-engagement workflows.

Testing Safely

Never test with real addresses at consumer providers (gmail.com, yahoo.com, etc.) — it damages sender reputation.

| Method | How | Use For | |--------|-----|---------| | API test token | Use POSTMARK_API_TEST as your server token | Validating API calls in CI/development | | Black hole | Send to test@blackhole.postmarkapp.com | Functional testing — appears in activity | | Sandbox server | Create a dedicated sandbox server in dashboard | Full send pipeline without delivery | | Bounce testing | hardbounce@bounce-testing.postmarkapp.com | Testing bounce webhook handlers |

See references/testing.md for full testing setup and domain warm-up schedules.

Sending Reliability

Production email systems need idempotency keys, retry logic, and rate limit handling to avoid duplicate sends and silent failures.

See references/sending-reliability.md for idempotency patterns, retry strategies, and rate limit handling.

Notes

Postmark is purpose-built for transactional email — use it for triggered 1:1 emails, not bulk marketing
Deliverability is not just about authentication — it's about sending wanted email to engaged recipients
A single spam complaint from a real user is more damaging than 1,000 hard bounces
Monitor your bounce rate (keep below 2%) and spam complaint rate (keep below 0.04%)