Mail Laravel Package

Product Decisions This Supports

• Build vs. buy on email construction (not delivery): Message/MimePart/HtmlComposer give us a battle-tested layer for the things teams hand-roll badly — MIME encoding, UTF-8 headers, inline image embedding, attachments, <title>→subject extraction, and automatic plain-text alternatives. The changelog is essentially a list of bugs we would otherwise file ourselves (v4.1.1 alone fixes emails killed by >500 kB data: URIs, filenames with spaces/parentheses, and address phrases with commas). Decision this supports: stop budgeting bespoke email templating work and redirect that capacity to product features.
• Deliverability as revenue protection, not infrastructure hygiene: DKIM signing with full-coverage headers (v3.1.0, corrected in v4.1.1 so Subject and To are actually signed) plus To: undisclosed-recipients for Bcc-only sends (v4.0.1) and correct display-name quoting (v4.2.1 — accented names no longer arrive wrapped in quotes). Frame this as recovered revenue on password resets, receipts, and dunning emails landing in inboxes rather than spam.
• Roadmap: transactional email hardening as a scoped, estimable epic: CSS inlining across clients (CssInliner, v4.1.0, with Outlook bgcolor/width/align attributes and preserved <style> for @media), attachment edge cases, DKIM coverage, slow-SMTP timeouts (v4.0.2), TLS/AUTH negotiation (v3.1.3, v4.0.0). This converts an open-ended "email is flaky" backlog into 1–2 sprints with demoable acceptance criteria.
• Roadmap: safe-by-default environments — a cheap, high-visibility PM win: Interceptor (v4.1.2) rewrites all To/Cc/Bcc and read-receipt headers to one address, preserves originals in X-Original-*, optionally prefixes the subject; MailTracy then lists every sent message (From / To+Cc+Bcc / Subject / Status) in the debug bar. Decision this supports: shipping a hard guarantee that staging and dev cannot email real customers — a recurring incident class, and a compliance/QA talking point that costs one config line.
• Feature bets it unlocks: HtmlComposer as a standalone pipeline (accumulate stylesheets, inlineCss(), embedImages($basePath), subject extraction, text alternative) is the natural insertion point for AI/personalized content and white-label multi-tenant templates where brand CSS is composed at runtime — without us owning a CSS parser.
• Architecture option-value: adopting it behind our own mailer interface keeps ESP portability (Postmark/SES/SendGrid/Symfony Mailer swap) while we own the message-construction layer we actually differentiate on. In a Laravel codebase this matters most precisely because Laravel's Mail facade hides construction behind Symfony Mailer — we'd be choosing to own that seam.
• Explicit non-decision: this is not an ESP, queue, or templating product. It does not replace database-backed queues, bounce/webhook handling, or analytics — see the adoption criteria below.

When to Consider This Package

Consider it when:

• You have PHP services outside a full framework (Nette apps, worker/CLI jobs, legacy PHP, microservices) that need reliable message construction plus SMTP/sendmail/mail() delivery with zero dependencies beyond nette/utils.
• Email rendering correctness is a recurring bug source and you want a tested CSS inliner, image embedder, and MIME encoder off the shelf — and you'd rather not own a Dom\HTMLDocument/regex tokenizer yourself.
• You need DKIM including Ed25519 keys (ext-sodium) or RSA (ext-openssl), plus a FallbackMailer (v2.4.0) for multi-transport resilience.
• Dev/test email leakage is an active incident class and you want Interceptor + a debug panel as a drop-in mitigation.
• You can commit to PHP 8.2–8.6 and ext-iconv, with ext-dom (PHP 8.4+) required for CssInliner.

Look elsewhere when:

• You are on Laravel and already use Mail/Notifications. Symfony Mailer (Laravel's transport) already provides CSS inlining, inline images, attachments, and DKIM. Adopting nette/mail means either running two mail stacks or writing and maintaining a bridge — integration cost that usually exceeds the benefit. Default to not adopting; revisit only if a specific gap (e.g. HtmlComposer semantics or Interceptor) is genuinely unmet.
• License cannot be cleared. The repository reports NOASSERTION. Nette packages are typically triple-licensed (BSD-3-Clause / GPL-2.0 / GPL-3.0) — that's likely fine, but legal must confirm before it enters the dependency graph. This is a blocking gate, not a footnote.
• Ecosystem signals must be strong. ~490 stars, 0 dependents, and a near-future dated release (2026-10-27) mean limited third-party validation and a small maintainer surface. Budget for the possibility of forking or vendor-patching; do not adopt it as an unowned transitive dependency.
• You need deliverability operations, not deliverability encoding. Bounce processing, suppression lists, reputation monitoring, per-tenant sending domains, and analytics belong to an ESP. This package gets the message right on the wire; it does not tell you whether it arrived.
• Your team has no Nette familiarity. The DI extension (mail.redirect, mail.dkim.*, mail: debugger: true) is idiomatic and clean, but it is Nette-idiomatic — not Laravel service-provider idiom. Account for a learning curve in the estimate.

How to Pitch It (Stakeholders)

One-liner: A small, dependency-light PHP library that builds and sends correct, deliverable email — so we stop re-filing the same "email looks broken / went to spam / hit a real customer from staging" tickets.

For executives (the business case): Three cost lines move in our favor. (1) Engineering capacity: CSS inlining, MIME encoding, inline images, and plain-text fallbacks are commodity work we keep paying for; this is pre-built and has a changelog full of fixes we'd otherwise discover in production. (2) Revenue at risk: DKIM signing that actually covers Subject and To, correct Bcc handling, and clean UTF-8 display names improve inbox placement on the emails that gate logins and payments — password resets, receipts, dunning. (3) Incident prevention: a one-line interceptor makes it structurally impossible for staging to email real customers, with the debug bar showing exactly what was sent. Cost is small and bounded; the main open item is a license sign-off (repo reports NOASSERTION; Nette is usually BSD-3-Clause among others).

For engineering (the honest framing): Strong message-construction layer — Message/MimePart, HtmlComposer (CSS inlining, image embedding, <title>→subject, text alternative), SMTP/sendmail/mail() mailers, FallbackMailer, DKIM (RSA and Ed25519), Interceptor + Tracy panel for dev safety. It is not a replacement for our queue or ESP. On Laravel we should assume the default answer is no unless a specific gap is proven, because Symfony Mailer already covers inlining and DKIM; if we do adopt, we wrap it behind our own Mailer interface so the transport stays swappable and the message layer stays ours. Known constraints: PHP 8.2–8.6, ext-iconv required, ext-dom on 8.4+ for inlining, ~490 stars / 0 dependents (thin ecosystem — we should be prepared to own patches), and license must clear legal first.