Multiple Mail server

My question is , if I have declared more than a single mail server in the Lucee Admin,
is there a possibility to choose the mail server to be used when I use CFMAIL in the code.
Mail server 1 or mail server 2 or mail server 3
I can see the parameters : server and username (in CFmail)

Thanks for help.

I guess you can use the “server” attribute of cfmail

Just refer to the documentation:

If you have more than one mail server in the LUcee admin, then Lucee just tries them in order until it finds one that works. So the 2nd, 3rd,. etc are just failovers.

You cannot “tell” the cfmail tag to use a specific server defined in the admin, but you can completely override the mal server in the cfmail tag so it doesn’t use any of the mail servers from the admin at all.

@Pierre_Larde, if you need such a behaviour to switch mail server back and forth programmatically according to whatever you need, I’d totally skip the application.mailservers definition. That is used in first place, if you want to not use credential attributes in your cfmail tag. If I understand you correctly, id use a global custom struct for that. E.g.


Then you just use that in your cfmail template for newsmailings like this:

<cfmail to="" from="" subject="Example email" 
server="#appMailservers.newsletter.server#" username="#appMailservers.newsletter.username#" password="#appMailservers.newsletter.password#" port="#appMailservers.newsletter.port#" ..... >
  Your Email Message!!

Or for the ITdepartment like that:

<cfmail to="" from="" subject="Example email" 
server="#appMailservers.ITdepartment.server#" username="#appMailservers.ITdepartment.username#" password="#appMailservers.ITdepartment.password#" port="#appMailservers.ITdepartment.port#" ..... >
  Your Email Message!!

I’d go even further and wrap cfmail in a function that passes two structs: one for the mail object itself (like subject, recepient, message, etc) and one for the server like defined above. E.g.:

public struct function sendMail( struct mail required, struct mailserver required ){
   cfmail(to="#arguments.mail.recepient#", from="#arguments.mail.sender#", subject="#arguments.mail.subject#",
){ writeOutput( arguments.mail.message ); };


return someStruct;

Or more simply, use

<cfmail attributeCollection="#appMailservers.newsletter#"

There are also entire CF libraries such as cbmailservices which are designed to give you abstraction over the server, but also the service which sends the message (local file, mock, postmark, cfmail, etc) as well as automatic body token replacements. Ortus doesn’t even use CFMail any more directly in our apps :slight_smile:


Thanks for all, I will try these.

Back to this thread,
I tried to override the server , username, password with the CFMAIL
But mails fall in the undelivered.
Then I used the same values as the mail server declared in Lucee admin
server , username, password and port

So with same values/parameters, it falls also in the undelivered.
(no mail arrive)

Any Idea , why ?
00000002.tsk (6.7 KB)
I have attached the .tsk file of the undelivered mail
from /WEB-INF/lucee/remote-client/open

code was :
cfmail to="" from="" subject=“test mail server : sendmail” server=“” port=“465” username="" password=“…”
Mon test avec Autre compte mail : server=“” port=“465”


worked with port=25
I had to specify port=25 instead of port=465
and in the Lucee admin, I have port=465

1 Like

I would say go with what andreas said and use multiple structs ( possibly based in the application scope to be convenient).

As a legacy dev… I’m in the habit of avoiding functions in the CF/Lucee Administrator unless Absolutely necessary. Historically the CF Admin was unreliable at best… so I got in the habit of avoiding any functions within it.

  • Search
  • Mail
  • Scheduled Tasks( when possible)
  • and so on

The Less you put in the Administrator… the less you have to deal with during site migrations where the potential for things long forgotten in the CFAdmin… will break things… especially if you end up in some kind of recovery or crisis situation where you don’t even know what was in there because it was setup and forgotten about over a decade ago…