Gmail quarantines the emails from bitbucket / atlassian

[Murat Saglam]

Emails originating from John Doe < commits-noreply@bitbucket.org > are failing to get through and are getting held up in triage. Our company relies on Google for email services, but there doesn't appear to be an option in the admin panel to permit these emails. Given that Atlassian and Gmail are commonly used together, I assume we're not the first to face this issue. Any assistance would be greatly appreciated.

[Murat Saglam]

After a discussion with Gmail support team the root cause is spoofing filters. 

Is there a way where we can receive emails that do not appear as sent from one of our employees? John Doe < commits-noreply@bitbucket.org > 

John Doe is our employee however commits-noreply@bitbucket.org is not his email/domain so these type of messages are stuck at spoofing filters.

Removing spoofing filters have other disadvantages.

Can bitbucket just send it simply as commits-noreply@bitbucket.orgwithout any employee name association?

[Jakub Krauz]

We just migrated to Jira Cloud and are currently facing the exact same issue with all email notifications being flagged as potential spoofing due to the sender being "John Doe (Jira) <jira@xyz.atlassian.net>".

@Murat Saglam Did you manage to resolve the problem, please?

[Murat Saglam]

Unfortunately no resolution yet

[Jakub Krauz]

Just an update for anyone who may read this, we got this problem resolved in Jira Cloud by customising the "Email from" value in Jira settings (Settings -> System -> General configuration). I missed this configuration option initially.

Note this does not answer the original question, I believe the mentioned configuration option is not available in Bitbucket Cloud currently.

[De Marque]

Thanks @Jakub Krauz ! I also missed this configuration option initially... The default will always backfire on decent email platforms.

[Patrik S]

Hello @Murat Saglam and thank you for reaching out to the Community!

We are not currently tracking any issues with emails being sent from Atlassian to the Gmail provider. Also, I looked at all the workspaces you have access to and was not able to find the user John Doe in any of those workspaces to check if this user was in any suppression list, so I went ahead and removed from the suppression list any email containing your company's domain. You can test now and check if the emails are being correctly received.

If you still identify the emails are getting quarantined, I would suggest reaching out to Gmail support since from Atlassian end the emails are being delivered, but Gmail is wrongly classifying them.

Thank you, @Murat Saglam !

Patrik S

[Murat Saglam]

Thank you Patrick. None of our developers now can receive email notification because of the above-mentioned issue. I did not want to expose real names therefore used John Doe. But I can confirm that the issue unfortunately persists.

Example:

Just a few minutes ago a notification from bitbucket 

From: John Doe <pullrequests-reply@bitbucket.org>

To: jane.doe@mycompany.com

is captured by the spoofing filter because pullrequests-reply@bitbucket.org is named as John Doe by Atlassian and Gmail treat this as spoofing. On the google side, the only option offered is switching off the spoofing filter which has other security disadvantages. 

Note that John Doe, jane.doe@mycompany.com are not real and used here for demonstrative purposes. 

I can also confirm that this is issue is general for all of our Atlassian users and not a specific case for a specific person

[Patrik S]

Hello Murat,

Since this filter is happening on the Gmail end, it falls a bit outside of Atlassian immediate control, as from Atlassian end the emails are being sent and delivered. In this case, I would suggest reaching out to Gmail to check if there's any way to disable spoofing filter for particular domains, so you can configure it to always allow emails coming from atlassian domain.

Thank you, Murat!

Patrik S

[Murat Saglam]

Hi Patrik,

Understood, partly agreed, but partly disagreed.... I think, from Atlassian side, the emails should not necessarily come in a spoof unfriendly way.  The fact the  "the user's name" and "pullrequests-reply@bitbucket.org" come together make message more likely to be filtered out. Therefore I categorize the issue a bit inside Atlassian's scope. But I understand, as of now, two parties do not offer a resolution apart from disabling the filter globally.

Thanks Patrik.