# Changes to Outgoing Email Configuration - Routes & Connectors

{% hint style="info" %}
Please note: this change will apply to all clients as part of this Feature Wave. We recommend reviewing it during your 4-week UAT window.
{% endhint %}

An update we’re introducing as part of the April 2026 Feature Wave is additional configurable Routes (Aliases) for both normal and Graph API Outbound Email Connectors. Previously, only Inbound Email Connectors had the option for additional configurable Routes.

Here’s how you set up additional routes for your Outgoing Email Connectors..

### **Setting up Additional Outbound Email Routes**

Once you have finished configuring an Outgoing Graph API Connector and set it live, you can if needed create additional Outgoing Email Routes - this allows you to define multiple 'From' email addresses Aliases for this outbound connector.

To do this, navigate to the Routes page in the Email section of Builder. Once there, locate the Outgoing Connector that you wish to create an additional Route for and click to add a new Route.

<figure><img src="/files/vujyY8Pcj7oWvL6XsuNm" alt=""><figcaption></figcaption></figure>

In the resulting pop-up you will need to give your new Outbound Email Route a Name, a Description and Email Address, i.e. the additional Alias ‘From’ address you're adding to the connector. The Email Connector Name will default to the name of the Connector you are creating the Alias/Route for.

<figure><img src="/files/jumGCFoX1Wh0ZvDRrG8y" alt=""><figcaption></figcaption></figure>

After you have finished with your configuration, you will need to 'Test Connection' of the Route. After you have a successful 'Test Connection' you can Enable the Route, and then click Save to set it live. Once you set a Outgoing Connector Live, you can not change the direction to Incoming.

Once your new Outgoing Email Route (Alias) has been created, it can now be used as a legitimate 'From' email address when configuring Cases, Tickets and Actions in your processes.

### Is there a Default Outbound Route for a Connector?

Yes. Just like with Inbound Connectors, all Outbound Connectors will have a default Route, which you create while setting up the Connector. The default Routes will be automatically enabled once you have set up an Outbound connector and as these default Routes are Connector level Email Routes.

## Replacement of System Default SMTP Gateway

As part of our move towards explicit outbound email addresses and configurable outbound Routes/Aliases, we are changing the way that the standard system outbound connector approach works. Previously, some email routing happened behind the scenes via the "System Default SMTP Gateway”. To give Builder users a greater visibility of outgoing email configuration, Enate is retiring the "hidden" system default and replacing it with a fully visible, manageable connector called ‘**Outgoing Connector’**.

This new ‘Outgoing Connector’ will be visible on the Connectors page in Builder and will be fully configurable. Additionally, the Outgoing Connector will be visible on the Email Routes page of Builder, where users will be able to see and interact with all the email routes that previously fell under the old ‘System Default SMTP Gateway’. Builder users will be able to add, delete and edit these outgoing routes.

{% hint style="info" %}
Please note that deletion of ‘Outgoing Connector’ is allowed in the system. You should exercise extra caution when editing this connector as deleting it would mean that any emails intended to be sent out via the Routes under this connector would no longer be processed, and the connector and its routes would have to be created again.
{% endhint %}

### Migration from System Default SMTP Gateway to Outgoing Connector

As part of the migration to this new approach:

* A new Outgoing Connector will be created to replace the old System Default SMTP Gateway.
* All outgoing routes that previously operated under this old Gateway” will automatically be reassigned to the new ‘Outgoing Connector’ and will instantly be created as visible Routes on the Email Routes page.
* Additionally, any previously created Outbound Connectors will show on the Routes page along with their default Route.

{% hint style="info" %}
Note: While Enate has automated all of these migration steps, any *new* routes created after the upgrade will require successful testing before they can be Enabled and set Live.
{% endhint %}

## Requirement: Setting of 'From' Email Address in Case & Ticket Configuration

As part of these changes, there is a change to be aware of when setting the 'From' email address in Case & Ticket configuration. **The system now performs a validation check to ensure that the email address set for this is linked to an ENABLED mail connector that is set with either 'Outgoing' or 'Both'.** Previously, if an unconfigured email address was set used, this would fall back to the system default gateway connector - that fallback no longer exists.

{% hint style="warning" %}
**If the connector related to the selected 'From' address is not yet enabled you will be met with a validation message in your Process Configuration screen on attempted saves, and will be unable to set the process to live.**
{% endhint %}

### Setting up 'Both Direction' Connectors in Production environments

As mentioned above when setting Case & Ticket Processes live, the 'from' email address must be linked to an already Enabled 'Outgoing' or 'Both' Connector. However, this can result in a pre-go live problem: in Production environments, you will very likely not want to set a connector processing incoming emails to enabled until the very point of go-live. Below are recommendations for how to set a 'Both' Connector to enabled in advance, to allow you to set Live Case & Ticket processes which reference it, but without yet processing live incoming production emails:

#### Recommended Approach - set an alternate Connector folder&#x20;

In order to all you to set your 'Both' connector to Enabled, you can set the Folder value to a dummy email Folder which will not be receiving incoming production emails. Note: this email folder would still need to exist, so you would need to speak to your email administrator to create the folder.

<figure><img src="/files/bPH2sTTlhz7JxYKOzjzh" alt=""><figcaption></figcaption></figure>

Once that is set, you Test & Enable the connector as normal. Because this folder path does not point to a production folder, the connector can be enabled and referenced in Builder process configurations without triggering production email processing.

As you hit your go-live point, steps would be as follows:

1. Remove / Repoint the dummy folder path from the connector
2. Rerun the test connection
3. Re-enable the connector

This keeps the go-live 'switch on' activity very familiar - you're still coming to the mail connector to enable things, with one additional step of adjusting the folder.

{% hint style="info" %}
**Important reminders on this:**

* Do **not** set the connector live with the real folder path before go live.
* Do **not** set it live without a dummy folder path in place during pre-go live configuration.
  {% endhint %}

#### Alternative - Use Separate Incoming and Outgoing Connectors

If you do not wish to use the above dummy folder approach, there is an alternative method that can be used: replacing the single 'Both directions' connector with two separate connectors, one for Incoming and one for Outgoing (each still referencing the same email address). This allows you to decouple of the 'Enabling' of the outbound connector from the inbound connector. At the point of go-live you would test and Enable the Incoming connector as normal. If you have a very large volume of email connectors, you may not wish to use this approach due to duplicating such large numbers of connectors.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.enate.net/whats-new/april-2026-feature-wave/april-2026-feature-wave/changes-to-outgoing-email-configuration-routes-and-connectors.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.