Multiple email transport configuration for different purposes

Has your proposal been discussed on the Mautic Forums already?
Yes, this proposal has been discussed on the Mautic forums at https://forum.mautic.org/t/ability-to-specify-different-email-gateways-to-use-for-different-purposes/10620

The feature request has also been tracked in GitHub issue #3827 since 2017 (https://github.com/mautic/mautic/issues/3827) and has generated significant community interest across multiple forum threads.

Is your feature request related to a problem? Please describe.
Currently, Mautic only allows configuration of one email service provider (such as Sendgrid, Mandrill, or Amazon SES) at a time. This creates several critical challenges:

Domain reputation management: When organisations send both transactional and marketing emails through the same transport, promotional campaigns can negatively impact the deliverability of critical transactional messages (such as password resets, purchase confirmations, or invoices). Separating these email types onto different IP addresses or services is essential for maintaining domain reputation.

Service disruption risk: If a marketing campaign causes reputation issues or rate limiting, it can directly disrupt time-sensitive transactional communications, potentially impacting business operations and customer trust.

Cost optimisation: Different email service providers offer varying pricing models. Organisations cannot optimise costs by routing high-volume marketing emails through cost-effective providers whilst using premium services for critical transactional messages.

Multi-domain operations: Organisations operating multiple brands or domains cannot easily segment their email sending to maintain separate sender reputations for each domain.

Flexibility limitations: There is no ability to test new email providers for specific campaigns or segments without switching the entire instance to that provider.

Describe the solution you'd like
Implement a comprehensive multiple email transport system that allows administrators to:

1. Configure multiple email transports: Add and manage multiple email service providers (Amazon SES, Sendgrid, Mandrill, Mailgun, SMTP servers, etc.) within a single Mautic instance, each with their own credentials and configuration.

2. Email-level transport selection: Assign specific transports to individual emails at the email creation/editing stage, visible in the email settings panel. This allows marketers to designate which service sends which email. 

3. Purpose-based transport assignment: Implement transport selection based on email purpose:
   Transactional emails (form submissions, password resets, notifications)

   Marketing emails (campaigns, segment broadcasts)

   Per-campaign or per-email designation

4. Contact owner-based routing: Enable transport selection based on contact ownership, allowing different teams, brands, or business units to send through their designated providers whilst sharing a single Mautic instance. 

5. Fallback mechanism: Implement a default transport that serves as fallback when no specific transport is assigned to an email.

6. Transport management interface: Create an intuitive interface within Mautic settings to add, edit, remove, and test multiple transports without needing to modify configuration files.

7. Mautic 7+ compatibility: Ensure the solution works with Mautic's Symfony Mailer architecture and DSN-based configuration system.

Describe alternatives or workarounds you've considered
Several workarounds and partial solutions currently exist, each with limitations:

Third-party plugins:

• The Custom Email Settings Bundle (https://github.com/1FF/mautic-custom-email-settings) provides functionality for Sparkpost and Sendgrid with API key switching and multi-product settings, but is limited to specific providers and may not be maintained for Mautic 5+. 

• The MT Extendee Multiple Transport Plugin (https://www.mtcextendee.com/mautic-multiple-smtp-bundle) offers commercial support but requires licensing and may not cover all use cases. 

• Various community plugins exist but often lack comprehensive maintenance, documentation, or support for modern Mautic versions.

Local SMTP relay configuration:

Using a local Postfix server or similar to manage multiple upstream SMTP providers. This approach is technically complex, requires system administration expertise, and adds infrastructure overhead. 

Multiple Mautic instances:

Running separate Mautic installations for different purposes or brands. This significantly increases maintenance burden, duplicates contact data, complicates reporting, and prevents unified marketing automation workflows.

Manual transport switching:

Changing the global email configuration before each send. This is error-prone, labour-intensive, and impractical for automated campaigns.

None of these workarounds provide the flexibility, reliability, and user experience that a native multi-transport feature would deliver.

Additional context
Technical considerations for Mautic 5+:

Mautic 5 migrated from SwiftMailer to Symfony Mailer, fundamentally changing how email transports are configured and managed. The new architecture uses DSN (Data Source Name) strings and requires transport components to be installed via Composer as plugins or Symfony packages. Any implementation must account for this architectural shift.

Domain reputation context:

Email service providers and spam filters analyse the entire email "fingerprint," including sending domain, tracking domains, and link domains. When multiple email types share infrastructure, they influence each other's reputation. Mixed-domain configurations can lead to blacklisting propagation across all emails sent through the instance. Proper transport separation helps maintain healthy sender reputations.

User experience:

The interface should be accessible to marketers without requiring deep technical knowledge, whilst providing sufficient flexibility for advanced users and system administrators. Configuration should be possible through the Mautic UI rather than requiring file system access or command-line operations.

Backwards compatibility:

The implementation should maintain backwards compatibility with existing single-transport configurations, making adoption seamless for existing Mautic users.

Existing community interest:

This feature has been requested repeatedly across multiple forum threads and GitHub issues over several years, indicating sustained community need. The existence of multiple third-party plugins attempting to solve this problem further demonstrates the requirement for native functionality.

Does this issue could impact on users private data?
No direct impact on private data handling. The feature manages email sending infrastructure configuration and routing logic, not contact data storage or processing. Standard email transmission security practices (TLS, authentication) apply to each configured transport. Proper access controls should ensure only authorised users can configure email transports and view provider credentials.

Funded by
Not currently funded. This proposal is being submitted to gauge community interest and initiate discussion about implementation approach. Organisations or community members interested in sponsoring development of this feature are encouraged to indicate their interest.