Your software
My Mautic version is: 7.2
My PHP version is: 8.5
My Database type and version is: MariaDB 11.x
Your problem
My problem is: Connecting to AWS SNS
These errors are showing in the log: I am unable to complete confirmation for subscription to SNS using the ‘MauticAmazonSesBundle’ plugin.
Steps I have tried to fix the problem: I literally used ChatGPT for instructions and troubleshooting for 3 hours now and still nothing works
Hi @HullioGQ,
First, I would remove PHP 8.5 from the equation. Mautic 7.2 should be run with a supported PHP version such as PHP 8.3 or 8.4, with both PHP-FPM and the CLI using the same version. PHP 8.5 can introduce unrelated compatibility problems and makes the SNS issue harder to diagnose.
For SES sending plus SNS bounce/complaint callbacks, the relevant plugin is etailors/mautic-amazon-ses. It supports Mautic 7. There are two installation paths; use one, not both.
Option 1: Composer installation, recommended because it resolves the plugin dependencies:
cd /path/to/mautic
composer require etailors/mautic-amazon-ses:^1.0 -W
rm -rf var/cache/*
php bin/console mautic:plugins:reload
Option 2: Git installation, if you need to manage the plugin checkout manually:
cd /path/to/mautic
composer require aws/aws-sdk-php:^3.0 -W
cd plugins
git clone https://github.com/pm-pmaas/etailors_amazon_ses.git AmazonSesBundle
cd ..
rm -rf var/cache/*
php bin/console mautic:plugins:reload
After that, configure the SES transport in Mautic Email Settings using your SES API credentials and region. The SNS subscription endpoint for this plugin is:
https://your-mautic-domain.example/mailer/callback
That endpoint must be publicly reachable over HTTPS with a valid certificate. It must not require login, be blocked by a firewall/WAF, or be cached by a proxy/CDN. Check the web-server access log while creating the SNS subscription: AWS should make a request to /mailer/callback.
Please share the exact error from var/logs/mautic_*.log, with credentials and tokens removed, plus the HTTP status recorded for the callback request. That will distinguish a PHP/plugin problem from an endpoint, proxy, or AWS SNS configuration issue.
Thanks for your help, Alex! We actually ended up taking a different approach and have it functioning now. We abandoned the SES/SNS callback plugins entirely.
Mautic is now sending through Amazon SES using the standard SMTP transport. For bounces and complaints, we enabled the Amazon SES account-level suppression list and built our own server-side synchronization process. A Python script periodically queries the SES suppression list through a least-privilege AWS API account, matches those email addresses against contacts in Mautic, and uses the Mautic REST API to mark bounces and complaints as “Do Not Contact.”
So there is no SNS topic, HTTPS subscription, /mailer/callback, or third-party SES callback plugin involved anymore. We would have preferred the simplicity of the old Mautic v4 SES API integration, but this approach gives us direct control over the feedback process and removes the dependency on third-party plugins.
So far everything is working in testing. We have not put it through a live sending workload yet, as we are still migrating companies and contacts. Fingers crossed it proves as reliable as our Mautic v4 setup, which served us well for about three years without any updates.
Hi @HullioGQ, glad you have a working test setup. One clarification for others reading this thread: a custom suppression-list sync is not the only option for Mautic 7. There are several SES/SNS callback plugins, including etailors, iamjpsingh, and matbcvo. They offer ways to process SNS feedback without maintaining a separate polling script.
Your approach has a reasonable trade-off: you control the integration, but you also own its scheduling, error handling, monitoring, and the delay between an SES event and the contact being updated in Mautic. I would test those failure cases before relying on it in production.
SMTP is a valid SES transport, but I would not assume it will match the throughput of an API-based setup for larger sends. The difference depends on connection reuse, concurrency, rate limits, and the particular plugin configuration, so it is worth measuring with your actual workload rather than treating either transport as universally faster.