Email routing traditionally relies on recipient domain as the primary factor for directing messages.

Cisco ESA / Ironport manages it using SMTP routes, where you match the receiving domains with the destination hosts:

While logical, this approach can present challenges in specific scenarios. For example, I encountered a situation where I needed to selectively route outgoing emails to different relay servers during testing or migration processes.

This would allow to gain the flexibility to direct emails to either the existing relay or the new one, depending on the sender's address/domain, providing greater control and helping to keep the flow uninterrupted. To address this challenge, I researched how routing based on the sender can be achieved on Cisco ESAs. Here is how i managed to do it:

Create dictionary

Using a dictionary allows granularity to add patterns to which the new route will be applied:

Later we will associate the dictionary to envelope sender address condition so, in this example, it would apply to:

  • address ->
  • domain -> @test.mydomain.ocm

Configure "fake" SMTP route

Using a fake domain name (in this example, create a new smtp route.
That hostname does not need to be created, exist, or even be registered in DNS... it's a fake name.

The destination (or destinations) must be the hostname of the relay server (or servers, in case of round robin) where you are going to send emails that matches certain conditions (like the sender based one we want).

Configure outgoing content-filter

Open "Outgoing Content-Filters" section and create a new one:


As you want, f.e. "CF_Route_NewRelay"


Based on which conditions do you want to route the outgoing emails through the new relay? Here you will define it.

We can use the "Envelope sender" - "contains". But this does not offer enough flexibility. For that reason, as commented before, let's use the dictionary containing the patterns that, in case of matching the sender, will cause the CF to be applied.


This is what causes the magic to happen. Set the "Send to Alternate Destination Host" action pointing to the fake name we have used in a previous step:

This will cause to match the SMTP route with that domain name and use the relay configured in that entry.

You might think, why not directly put the relay server in alt mail host? That doesn't work, apparently it tries to match it in the 'receiving domain' values of the routes and doesn't find it, causing it not to work this way.

The rule would be as follows:


Just apply and commit the changes and verify that it's working.