Configure Mautic with Amazon SES SMTP Safely

Getting a green “SMTP connection succeeded” message is only the beginning. A trustworthy Mautic–SES setup also needs an authenticated sending domain, production access, controlled rates, background queue processing, unsubscribe/consent discipline, and a tested path for bounces and complaints.

Architecture at a glance

consented contact
      │
      ▼
Mautic campaign/broadcast → queue → Mautic worker
                                  │ TLS + SMTP credentials
                                  ▼
                         regional SES SMTP endpoint
                                  │ DKIM / MAIL FROM / policy
                                  ▼
                           recipient mail system
                                  │
                    bounce / complaint / delivery event
                                  ▼
                  SES notification or event publishing
                                  │
                                  └──► suppression/contact hygiene workflow

What the diagram makes explicit

• Mautic decides who and when to send; SES accepts and relays mail under regional identity, quota, reputation, and policy controls.

• SMTP credentials authenticate submission but do not configure DNS authentication, production access, feedback ingestion, or consent.

• A successful SMTP response means SES accepted a message for processing—not that it reached the inbox.

• Bounces and complaints must return to an automated, monitored workflow that prevents repeated harmful sends.

1. Choose one SES Region deliberately

SES identities, SMTP credentials, sandbox/production state, quotas, suppression preferences, and feedback configuration are regional. Pick the Region that matches your compliance, latency, operational ownership, and feature needs; keep every related setting in that Region.

$ region='us-east-1'
endpoint="email-smtp.${region}.amazonaws.com"
printf 'Region: %s\nEndpoint: %s\n' "$region" "$endpoint"

Region-selection takeaways

• The values are documentation examples. Confirm the exact SMTP endpoint in the SES console or AWS endpoint reference for your selected Region.

• SMTP credentials generated for one Region do not authenticate in another.

• Verifying a domain in one Region does not silently reproduce all identity/feedback settings in another.

• Do not use a global/API endpoint name as though it were the regional SMTP interface.

2. Verify and authenticate the sending domain

In the chosen SES Region, create a domain identity and publish the DNS records SES provides. Prefer domain verification with Easy DKIM so multiple legitimate From addresses can be managed without verifying them one by one.

$ dig +short CNAME selector1._domainkey.example.com
dig +short TXT _dmarc.example.com
dig +short MX bounce.example.com
dig +short TXT bounce.example.com

DNS-check takeaways

• Replace the selector and domains with values shown for your SES identity; never copy another tenant’s DKIM tokens.

• Easy DKIM normally uses SES-provided CNAME records. Wait for SES—not only a local resolver—to mark verification successful.

• DMARC requires alignment through DKIM or SPF. Start policy changes with reporting and evidence, then tighten according to domain governance.

• A custom MAIL FROM subdomain needs the SES-provided MX and SPF TXT values and should be dedicated to that purpose. It is optional, but useful for aligned SPF and branded return paths.

• DNS caching and delegation errors can delay or split results; query authoritative nameservers when debugging.

3. Confirm sandbox status and quotas

A new SES Region commonly starts in the sandbox. In sandbox, sending is restricted—including recipient verification—and quotas are deliberately low. Request production access only after the use case, website, consent flow, bounce handling, and sending practices are ready for AWS review.

• Production access is regional; a different Region may still be sandboxed.

• Daily quota uses a rolling 24-hour window and counts recipients, while the sending-rate quota limits recipients per second.

• Mautic batch and worker throughput must remain below the lower of SES limits, host resource limits, and your reputation-safe warm-up rate.

• A quota increase is capacity, not permission to send unsolicited mail. Maintain traceable opt-in, clear identity, unsubscribe handling, and list hygiene.

4. Create dedicated SES SMTP credentials

1. Open SES → SMTP settings in the selected Region.

1. Choose Create SMTP credentials and create a purpose-specific identity such as mautic-production-smtp.

1. Download or securely copy the SMTP username and password once; do not email the CSV or commit it.

1. Restrict who can manage the IAM identity and monitor the permission-management operations used to create credentials.

1. Plan rotation: create a new credential, update and test Mautic, then revoke the old one after observing successful delivery.

5. Prove shared-host network access before configuring Mautic

$ endpoint='email-smtp.us-east-1.amazonaws.com'
getent ahosts "$endpoint"
nc -vz -w 10 "$endpoint" 587

Connectivity takeaways

• Run from the same hosting account/container/network as PHP. A successful test from your laptop proves nothing about shared-host egress.

• getent ahosts tests the application host’s configured name-service path.

• nc tests TCP reachability to port 587; it does not authenticate, negotiate STARTTLS, or send mail.

• Port 25 is frequently rate-limited or blocked and is unnecessary here. SES supports STARTTLS on 587/2587 and implicit TLS on 465/2465; use the mode Mautic correctly supports.

• If egress is blocked, ask the provider for a documented exception to the specific SES endpoint/port or move platforms. Do not expose a proxy or disable TLS.

Inspect the STARTTLS handshake

$ openssl s_client -starttls smtp \
  -connect email-smtp.us-east-1.amazonaws.com:587 \
  -servername email-smtp.us-east-1.amazonaws.com \
  -verify_return_error </dev/null

TLS-test takeaways

• -starttls smtp performs the SMTP upgrade before TLS; connecting with raw TLS to a STARTTLS port is the wrong protocol.

• -servername supplies SNI and -verify_return_error makes certificate verification failures visible.

• Use the OS/PHP trust store Mautic will use; a shell test can pass while PHP has stale CA certificates.

• Do not type SMTP credentials into an ad hoc terminal session where shell history, process inspection, or logs may capture them.

6. Configure Mautic Email settings

In Mautic, open Settings → Configuration → Email Settings. Current Mautic uses Symfony Mailer; old SwiftMailer screenshots and Swift_SmtpTransport errors no longer describe the implementation. Labels can vary by Mautic release, so map the following values by meaning.

Mailer transport:     Other SMTP Server / SMTP
Server / host:        email-smtp.us-east-1.amazonaws.com
Port:                 587
Encryption:           TLS / STARTTLS
Authentication:       Login / automatic supported auth
Username:             <SES SMTP username for us-east-1>
Password:             <SES SMTP password for us-east-1>
From address:         marketing@example.com
From name:            Example Engineering
Reply-To:             monitored-replies@example.com

Configuration takeaways

• Select generic SMTP if no maintained SES-specific transport is installed. Mautic constructs the Symfony Mailer DSN from these fields.

• Match host, credentials, identity, sandbox/production status, quotas, and feedback configuration to the same Region.

• On port 587 select STARTTLS/TLS upgrade, not implicit SMTPS. For implicit TLS use the provider-supported wrapper port and matching Mautic mode.

• The visible From domain should be a verified identity and align with DKIM/DMARC policy. Use a monitored Reply-To instead of a dead no-reply address.

• Never include real credentials in screenshots, support tickets, application logs, backups without encryption, or migration trackers.

7. Test connection, then test delivery

Mautic’s connection test checks some transport properties, but it cannot prove inbox placement, authentication alignment, unsubscribe behavior, queue execution, or feedback processing. Send a real low-volume message to controlled addresses at multiple mailbox providers.

$ dig +short TXT _dmarc.example.com
dig +short CNAME selector1._domainkey.example.com

Delivery validation checklist

• Confirm the message arrives with the intended From, Reply-To, subject, HTML/text alternatives, links, unsubscribe mechanism, and tracking policy.

• Inspect received headers for spf=pass, dkim=pass, and dmarc=pass with the expected aligned domains.

• Check the SES sending event/reputation dashboard and Mautic logs rather than treating inbox appearance as the only signal.

• Test a controlled bounce and complaint simulation using AWS-approved SES simulator addresses where applicable; never click “spam” on real test mail to manufacture feedback.

• Verify Mautic marks or suppresses contacts according to the implemented feedback integration.

8. Queue mail instead of blocking web requests

Immediate delivery makes a browser or campaign action wait on remote SMTP and can collide with shared-host execution limits. For meaningful volume, configure Mautic’s email queue and run the documented consumer with an explicit lifetime.

$ php /home/account/mautic/bin/console messenger:consume email --time-limit=160

Queue-worker takeaways

• Replace the path with the deployed Mautic console and use the same supported PHP binary/configuration as the application.

• Mautic documents a time, message, or memory limit for cron-launched consumers because otherwise the consumer is long-lived.

• Schedule the next run after the previous budget with enough margin, and prevent overlap using the hosting platform’s supported locking mechanism.

• Queueing smooths web latency; it does not automatically enforce SES quota/reputation-safe rate or fix failed feedback handling.

• Capture exit status and Mautic logs. A cron control panel showing “ran” is not proof that messages were consumed.

Example crontab entry

*/5 * * * * /usr/bin/php /home/account/mautic/bin/console messenger:consume email --time-limit=160 >> /home/account/logs/mautic-email-worker.log 2>&1

Cron safety notes

• Cron has a minimal environment; use absolute executable/application paths and ensure the job runs as the Mautic owner.

• The example appends logs, which must be permission-protected, rotated, monitored, and checked for recipient or error data.

• A five-minute schedule is only an example. Shared hosts may impose 15/30-minute minimums or terminate workers early.

• Do not send credentials as command-line flags or environment assignments embedded in a control-panel cron field.

• Run Mautic’s other required campaign/segment maintenance commands according to the exact installed-version documentation; the mail worker alone does not execute every automation stage.

9. Close the bounce and complaint loop

Generic Symfony SMTP transports send one message per request and, according to current Mautic documentation, do not provide transport callback handling. That means “SMTP works” does not automatically mean Mautic understands SES delivery, bounce, or complaint events.

• Choose a maintained Mautic integration/plugin or a carefully secured event-processing service that maps SES feedback to Mautic contacts and supports your exact Mautic version.

• Configure SES identity notifications or event publishing for bounces and complaints in the same Region. Avoid duplicate processing when enabling multiple notification methods.

• Authenticate webhook/SNS ingress, validate message signatures, make processing idempotent, restrict network access, and protect recipient data.

• Immediately stop mailing confirmed complaints and hard bounces. Treat transient bounces according to an evidence-based retry policy.

• Monitor SES account-level suppression, bounce/complaint reputation metrics, queue failures, notification delivery failures, and integration lag.

• Test feedback end to end before production campaigns and after upgrades or credential/Region changes.

Security and privacy baseline

• Serve Mautic only over HTTPS; protect admin accounts with strong authentication and least privilege.

• Patch Mautic, plugins, PHP, database, and dependencies on a tested schedule. Old FTP-upload installs are difficult to reproduce and audit.

• Store SMTP secrets outside web-accessible paths, restrict configuration/backups, and rotate credentials without downtime.

• Collect only necessary contact data, document lawful basis/consent, honor unsubscribe and deletion requirements, and define retention.

• Prevent arbitrary contact import and campaign send privileges; a compromised marketing platform can rapidly damage domain and SES reputation.

• Back up database, uploaded assets, configuration, and encryption-critical material; restore-test before upgrades.

Troubleshooting by layer

• Connection timed out: shared-host egress/firewall, wrong endpoint/port, DNS, IPv4/IPv6 path, or provider outage. Test from the PHP runtime network.

• TLS handshake fails: wrong implicit-vs-STARTTLS mode, stale CA store, intercepted connection, time skew, or incorrect SNI hostname. Never disable certificate verification.

• Authentication failed: AWS access key used instead of SMTP password, wrong Region credential, rotated/deleted IAM SMTP user, whitespace/copy error, or auth mode mismatch.

• Message rejected / identity not verified: From/MAIL FROM identity is unverified in this Region, sandbox recipient is unverified, or policy denies it.

• Daily/rate quota error: Mautic throughput exceeds regional quota; throttle responsibly and request increases only with a mature use case.

• Connection test passes but no campaigns send: queue/consumer, campaign/segment cron, permissions, stuck messages, resource limits, or application log errors.

• Mail arrives in spam: investigate consent/engagement, content, list quality, reputation, DKIM/SPF/DMARC alignment, sending cadence, and mailbox-provider feedback—not SMTP port changes.

• Bounces continue receiving campaigns: SES feedback is not connected, not authenticated, delayed, duplicated, or not mapped to Mautic suppression state.

• Only some mail fails: inspect per-recipient SES events, suppression status, mailbox response, content, and quota—not just the global connection test.

Production-readiness checklist

1. Confirm supported Mautic/PHP/database stack, HTTPS, update strategy, backups, cron/worker support, and hosting resources.

1. Select the SES Region; verify domain, enable DKIM, establish DMARC alignment, and optionally configure custom MAIL FROM.

1. Obtain production access and quotas appropriate to a consented, reputation-safe warm-up plan.

1. Create dedicated regional SMTP credentials and store/rotate them securely.

1. Prove DNS, TCP 587, STARTTLS, PHP CA trust, and Mautic connection from the hosting environment.

1. Send controlled tests; validate headers, content, unsubscribe, SES events, bounce/complaint ingestion, and Mautic suppression.

1. Enable bounded queue consumers and required Mautic automation jobs with locking, monitoring, and log rotation.

1. Monitor delivery, bounces, complaints, suppressions, quotas, worker lag, failures, and credential/identity changes.

Related email and hosting guides

• Protect DNS changes with SPF, DKIM and DMARC troubleshooting.

• Automate safely using Linux cron job examples.

• Diagnose blocked outbound connections with Linux networking commands.

Primary references

• Mautic documents current Email transport and queue settings and its Symfony Mailer/SMTP behavior.

• Mautic’s cron documentation defines the bounded messenger:consume email worker.

• AWS documents SES SMTP credentials, including regional scope and the distinction from AWS secret keys.

• AWS explains SES SMTP endpoints and TLS modes.

• Review SES sandbox and sending quotas, which are regional and recipient-count based.

• AWS documents bounce and complaint notifications and DMARC alignment.