Product Decisions This Supports
- Deliverability & abuse handling as a first-class feature. The core capability here — ingesting AWS SES bounce and complaint notifications and suppressing bad addresses — is table stakes for any product that sends transactional or lifecycle email. If we don't do this, a handful of bad imports can degrade our SES sending reputation and take down password resets and receipts for every customer.
- Suppression list & compliance posture. Automatic suppression on hard bounce and on complaint is the artifact legal/security will ask for during review ("prove we stop emailing people who complained"). This is a compliance decision, not just an engineering one.
- Build vs. buy vs. adopt. This package is best treated as a reference specification for our own implementation rather than a dependency. It answers "what does the bounce/complaint pipeline need to do?" so we can scope the build with confidence, and it argues against buying a standalone deliverability SaaS at our current volume.
- Roadmap scoping for the notifications platform. Committing to in-house suppression changes downstream roadmap items: preference centers, per-channel opt-out, re-permission campaigns, and list-hygiene tooling all depend on having a canonical suppression store.
- Provider strategy. The package couples us to SES-specific notification semantics. Adopting it is implicitly a decision to stay on SES for the foreseeable future; it should be evaluated alongside any "multi-provider email" initiative, not before it.
- Onboarding and data-import decisions. Which lists we import, and how we validate them, is a product decision that the bounce-handling guarantees feed directly into.
When to Consider This Package
Consider it only when all of the following are true:
- There is an existing Symfony 2.8/3.x application still using the SwiftMailer transport (not Symfony Mailer, not a custom SES client).
- SES is the sole or primary sending provider and there is no near-term plan to change that.
- The team is willing to vendor the code into the repo and own it — treat it as a starting point, not a maintained dependency.
- Someone has bandwidth to review the SNS subscription verification and signature validation paths before anything ships; 2017-era webhook handlers rarely meet current security expectations.
Look elsewhere (or build) when:
- The application is Laravel, or Symfony 4.4+, or uses Symfony Mailer. This is a Symfony bundle with no Laravel service provider, no facades, and no configuration bridge — you would re-implement the wiring anyway, at which point you are writing the feature yourself.
- SwiftMailer is EOL (November 2021). A package whose integration surface is a dead transport library is a liability, not an asset.
- Zero stars, zero dependents, last release December 2017. There is no community to catch regressions, no security response, and no compatibility work for PHP 8.x. Any CVE in its transitive dependencies lands on us.
- You need multi-provider support, modern SES v2 APIs, or event-driven suppression shared across services — the package's scope is narrower than the problem.
- Recommended alternative: implement directly against SES → SNS → HTTPS endpoint with the AWS SDK, plus a suppression table. Roughly 2–4 engineer-days for an MVP, and the code is ours.
How to Pitch It (Stakeholders)
For executives: We evaluated an open-source package that handles bounces and complaints from Amazon SES. It is functionally in the right problem space but is not adoptable: last release 2017, no stars, no downstream users, and it is built on a mail library that reached end of life in 2021. Adding it would mean owning an unmaintained dependency in a path that affects every customer email we send. Recommendation: do not adopt; use it as a design reference and build the capability in-house. Cost is small and bounded; the alternative is an open-ended maintenance and security liability on a revenue-critical channel.
For engineering: The package documents the right shape of the solution — subscribe an endpoint to the SES bounce/complaint SNS topics, verify the subscription and message signature, classify notifications as hard bounce / soft bounce / complaint, write to a suppression table, and gate all sends through a suppression check. That last step is the one that matters and the one a bundle can't do for you, because it has to live in our send path. SwiftMailer filters are the wrong integration point for us regardless: they're transport-specific and predate Symfony Mailer. Plan for a small, well-tested module behind an interface we control, with the suppression store as the source of truth so we can swap providers later without rewriting the policy logic.
Shared framing: This is a build decision dressed up as a buy decision. The package's value to us is as a checked-off requirements list, not as code we ship.