How to configure outgoing mail in confluence cloud instance

[Nitin Hiwale]

Currently I am using free plan for confluence cloud and not able to get option to configure mail server.

Could you please help on the same.

[Daniel Eads]

Hi Nitin,

Confluence Cloud uses Atlassian's outgoing mail relays and these aren't user-configurable. From our reference documentation:

Atlassian Cloud comes with an internal SMTP server configured to send notifications. The internal SMTP server is not configurable, but you can configure Jira Cloud to send emails on behalf of your domain.

Is there something in particular that you needed to change with the mail settings?

Cheers,
Daniel

[Nitin Hiwale]

Thanks for the information @Daniel Eads 

How can we configure it on the behalf of our domain as I can see only Enable and Disable option in outgoing mail configuration.

[Daniel Eads]

Hey Nitin - sorry for the confusion. Although the snippet does mention sending on behalf of in Jira, the bit I was hoping to draw attention to is that the SMTP settings are not configurable.

For clarity: sending on behalf of a domain is a setting in Jira, but is not a configurable setting in Confluence.

[Alex Franks]

Jumping in here because this is the closest relevant question I can find - we were able to change the "From Name" for the email in our Jira Cloud instance (as documented here) but I cannot find any similar configuration for Confluence Cloud. This appears to be a configurable setting in Confluence Server as well.

Does this exist or is it not available at the moment?

[Daniel Eads]

Hi Alex - the documentation linked above is still up-to-date. The outgoing mail settings aren't currently configurable in Confluence Cloud.

[Alex Franks]

Thanks for confirming Daniel.

What's the best way to file a feature request for something like this? Seems like a fairly clear lack of parity between the products and this particular config has (potentially) significant impact depending on other service providers.

[Daniel Eads]

Hey Alex, to be honest, this isn't something many folks are asking for. I don't want to get your hopes up... A feature request does exist here which you can watch and vote on, but given the limited activity in the time it's been open, it's very unlikely to be prioritized. For more information about how Atlassian prioritizes feature requests made on jira.atlassian.com, check out this Community post.

[Alex Franks]

Thanks Daniel.

Agreed that this is probably low urgency/impact from the standpoint of the broader community. But ultimately this wouldn't require a full custom email server configuration as in your linked feature request - just the same options currently available in Jira Cloud's General Configuration.

Cheers!

[Adrian Smith]

Being able to specify our own email server is very important as the notifications from confluence@mail-us.atlassian.net originate from outside our organization and therefore are flagged differently. Many cloud services we use allow us to configure a user within our o365 environment to send emails directly within our ecosystem.

[Bruno Abele]

While we trust Atlassian to handle our data, our company requires all emails must be encrypted or at least SSL-protected when sent out by Atlassian. As a lot of mail servers still do not provide TLS on port 25, Atlassian will probably not enfoce this.

With a forwarding to our own mail servers, we can then re-send mails to our users. For this, we need all site for our mail to be routed to a certain mail server, and we should be able to add some smtp headers.

As we have a mix of user with company-emails and others coming from other companies, it is not sufficient to send just our company email to our server - must be done for every mail created by our sites.

We cannot activate email notifications like it is now, and of course this is a downside as many of the non-company users cannot access our other tools like Slack or Teams which could replace emails.

Big change on architecture, of course, but sending all our ticket content out unprotected into the open internet is nothing we want to have.

[Bruno Abele]

Maybe one of the simplest approaches could be:

* It is possible to define the sender address for that email (so it can be a company email, not the generic Atlassian cloud sender address).

* In the email servers, there could be a switch that forwards all mails coming from that sender to a certain defineable mail server (aka relayhost), maybe with additional static headers.

This might be easier to achieve than setting up individual mail servers for each site. And as sender emails are validated, it is also very safe against spoofing