Transactional and marketing emails properly distinguished

CAN-SPAM §5 defines transactional email (password resets, receipts, security alerts) as exempt from its commercial email requirements — but that exemption disappears the moment promotional content is added to a transactional template. Injecting a 'You might also like' banner into an order confirmation reclassifies the entire message as commercial, requiring unsubscribe compliance that transactional flows typically lack. Beyond compliance, mixing the two in a single code path destroys the deliverability benefit of keeping transactional mail on dedicated IP streams: a complaint on a promotional email poisons deliverability for password resets on the same IP pool.

Maintain separate functions and separate sending configurations for transactional and marketing email — never route both through the same code path.

// lib/email.ts — explicit type separation
export async function sendTransactionalEmail(opts: { to: string; subject: string; html: string }) {
  // No List-Unsubscribe headers; no promotional content in html
  return client.send({ from: 'noreply@yourproduct.com', ...opts })
}

export async function sendMarketingEmail(opts: { to: string; subject: string; html: string; unsubUrl: string }) {
  // Always includes unsubscribe headers; only called for opted-in subscribers
  return client.send({
    from: 'hello@yourproduct.com',
    headers: { 'List-Unsubscribe': `<${opts.unsubUrl}>`, 'List-Unsubscribe-Post': 'List-Unsubscribe=One-Click' },
    ...opts,
  })
}

If using Postmark, configure separate message streams (Transactional vs. Broadcast). This also gives you separate deliverability metrics to catch issues before they affect your transactional sending reputation.