Is your feature or enhancement related to a problem? Please describe.

Yes, the current implementation forces a dependency between IMAP and SMTP settings at the channel level.

The problem is that I cannot configure a custom SMTP provider for an email channel without first enabling and validating IMAP credentials. This prevents me from using a "forwarding" model for incoming emails while still using a specific SMTP service (like Postmark or SendGrid) for outgoing emails.

My desired workflow is to receive emails via forwarding to the address Chatwoot provides and send replies through a dedicated SMTP server to maximize deliverability, but the current system makes this impossible.

Describe the solution you'd like

Hello Chatwoot Team,

First of all, thank you for this fantastic open-source project.

I am writing to suggest a change in the configuration of email channels. Currently, it's not possible to configure a channel's specific SMTP settings without first enabling and configuring IMAP. This creates a limitation for a very common and robust workflow.

Current Behavior
When creating an email channel, the SMTP configuration section is locked until IMAP is successfully configured and saved. The interface displays a note stating: Note: To enable SMTP, please configure IMAP.

This forces the user to use IMAP for incoming mail if they want to use a specific SMTP for outgoing mail.

Expected Behavior
The configuration for IMAP and SMTP should be completely independent. A user should be able to:

Create an email channel.

Leave IMAP disabled.

Enable and configure specific SMTP settings for that channel.

Use Case and Justification
A very popular setup for handling support emails is to use a transactional email service (like Postmark, SendGrid, etc.) for both inbound and outbound mail. The workflow is as follows:

• Inbound: The external service receives the email (e.g., at [email protected]) and forwards it to the unique forwarding address provided by the Chatwoot channel. This "push" method is efficient and reliable.
• Outbound: To ensure deliverability and brand consistency, replies sent from Chatwoot should be sent via the same service's SMTP servers, using the [email protected] address as the sender.

The current dependency on IMAP makes this simple and effective architecture impossible without workarounds. It forces users into an IMAP "pull" model, even if they prefer a forwarding "push" model for receiving emails.

Decoupling these settings would provide greater flexibility and allow users to integrate Chatwoot with best-practice email architectures.

Thank you for your consideration.

Describe alternatives you've considered

A simpler alternative to implementing a full per-inbox SMTP configuration would be to leverage the existing global SMTP settings but allow for dynamic sender addresses.

The Current Behavior:
If a global SMTP provider (like Postmark, SendGrid, etc.) is configured via environment variables, all replies sent from any email inbox use the globally defined MAILER_SENDER_EMAIL as the From: address. This forces all departmental inboxes to send emails from a single, generic address.

Proposed Alternative Solution:
Introduce a new behavior, perhaps enabled by a toggle, where Chatwoot uses the globally configured SMTP service but dynamically sets the email's From: header to match the address of the specific inbox from which the reply is being sent.

Example:

• The global MAILER_SENDER_EMAIL is set to [email protected].
• An agent replies from the "Sales" inbox, which is configured in Chatwoot with the address [email protected].
• Instead of sending the email from [email protected], Chatwoot would use the global SMTP credentials to send the email with a From: header of [email protected].

This would require the administrator to have the necessary domains or sender signatures authorized in their transactional email provider, which is standard practice.

This approach would solve the core problem of sender identity and brand consistency for users who utilize a single provider for all their transactional mail, potentially being a simpler and faster feature to implement than a full per-inbox SMTP credential system.

Additional context

No response