DMARC might be blocking your email notifications from Jira

[#1]

Hello Atlassian Community, this is everything you wanted to know about emails (sent from a email address with a DMARC adhering domain) from Jira that failed to reach the intended recipients.

To understand this further, let’s say your team is associated with a Jira project and you’ve commented on a particular issue in the project. You’ve also configured Jira to send emails on behalf of your domain to send email notifications to people, groups, or roles from your team. Jira does send emails addressed from the custom email address specified in the Notifications section. But, if the domain is adhering to Domain-based Message Authentication, Reporting & Conformance (DMARC) policy, it might block these email notifications. That is, the notifications sent from Jira either goes to the user's spam folders or are rejected based on the preferences set in the domain’s DMARC policy by your organization.

What is DMARC

DMARC is a protocol to prevent fraudulent emails by performing additional validation that an email was actually sent from the address it claims to be from. DMARC uses Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) for this purpose. In short, email senders can specify how to handle emails that were not authenticated using SPF or DKIM. They can either send those emails to the junk folder or have them blocked altogether.

The conflict

The conflict arises when the outgoing emails we send (when a custom email address is used) are not DMARC compliant. This is because the Return-Path header on the outgoing emails points to one of our own *.atlassian.net domains instead of the customer's domain.

Why we haven’t fixed this issue

Fixing this issue would require us to build our own email suppression list service instead of relying on the functionality from our third-party Email Service Providers (ESPs). This is a huge undertaking (recorded in JRACLOUD-40169) that will take time to implement.

If we rely on ESPs, we would need to verify and configure every customer domain with our third-party mail providers so that the Return-Path header is set correctly by them. This is simply not feasible for us to do given the sheer number of domains that would need to be managed. The Return-Path header needs to be set so that we and our third-party ESPs know which of our emails have bounced/sent to spam. This let’s take action when our systems are being used for spam and helps us maintain our reputation as a legitimate email sender. Also, having the Return-Path header set to the customer’s own domain (to enable DMARC work properly) requires additional validation by the ESP to make sure that it receives the delivery failure receipts.

Here are some workarounds

We totally understand your frustration when those email notifications doesn't show up. We would definitely want to tackle it with a full-proof solution in the future. For now, here are a few workarounds:

• If the email notifications are restricted to distribution within your organization, configure your email servers to whitelist our outgoing email IP addresses.

• Configure your emails to be sent from an atlassian.net domain (this is the default configuration).

• Set the domain’s DMARC policy to “none” instead of “quarantine” or “reject”, but this is not recommended.

[Taranjeet Singh]

@Praveen Prabhakar Thanks for sharing this and the workarounds for Cloud JIRA users.

[Shailendra]

Few questions-

1. This issue of DMARC failure is only for Jira cloud, its not for Jira hosted?

2. Is any roadmap there for the resolution of this issue in near future?

3. Is this issue also happening with Jira ServiceDesk cloud?

We uses GSuite as our mail server, how to do workaround with this so that not even our employees, outside users also get email in inbox?

[James Sharpe]

@Shailendra Yes this is also happening for Jira ServiceDesk cloud.

However this article misses the point - what is missing from the implementation is signing the outgoing messages with the correct DKIM signature so that DKIM aligns and passes the DMARC checks. 

Fixing the issue doesn't require a 'email suppression list' - it just requires sent emails to be signed with the correct DKIM signature for the custom domain rather than the *.atlassian.net domain. 

@Praveen Prabhakar your competitors implement this correctly - why is it so hard to implement it at Atlassian?

[Shailendra]

@James Sharpe thanks for the response. I am 100% sure that @Praveen Prabhakar from Atlassian team will not have any firm answer on this and cannot provide us any clear picture on roadmap of implementing this feature on Jira cloud.

[Wolfgang Jung]

Instead of using sendgrid for the email-delivery, I would recommend to allow usage of our own mail servers. Adding SMTP/IMAP-accounts is already possible in Jira, why not using those for the notifications?

Sending Mail through the customers' mail server would also allow different handling between Jira-notifications (they would now be internal emails) and emails from outside.

Maybe, we should switch to YouTrack.

[Michael Gates]

I'm a Jira Service Desk customer (not for long, we are migrating out due to this). It blows my mind that, regardless of the fact that literally every customer service platform I have looked into other than Jira Service Desk does this correctly, Atlassian finds it acceptable to have their outgoing Service Desk mail categorized as spam when using a customer domain. You all do know that this is a huge deal-breaker, right? Our customers cannot see our replies to their support requests because they end up in spam. We are not going to ask them to whitelist our domain as that is just ridiculous and makes us look like we don't know what we are doing.

[Georg Müller]

I am scared too. How can that be? Why is neither one (correct DKIM signature) nor the other (sending mail through the customers mail server) supported? This is a big nuisance for us!

[Iain Alexander]

So.. of the 3 "workarounds" above.

The first means "gets every customer to manually white list your domain" (and look unprofessional)

or

Send all your email through Atlassian's domain and look unprofessional

or

Set Dmarc to None and look unprofessional while opening yourself up to spoofing and phishing

I am genuinely staggered that Atlassian are offering these "workarounds" and not actually addressing the problem.

No where is the option to "use your own smtp gateway" or any way to actually secure your outgoing email and look like a competent company!

I'm not the only one thinking this is actually a deal breaker and for my company it really really is.

[Shaun Boddez]

In addition to the comments from @Iain Alexander above, workaround #1 requires customers to whitelist a whole list of IP ranges including:

167.89.0.0/17

This is SendGrid's outgoing IP range, which means that we need to open ourselves up to any and all phishing and spam content sent through SendGrid - absolutely unacceptable as a solution.

[Matías Averbuj]

This can't be real.... We are in the year 2020 and Atlassian doesn't know how to send emails?!

We just switched to Jira Services Desk and I come across this as our internal customers are getting emails marked as [SPOOF]. The only workaround would be to open up to the full range of IPs from sendgrid, which is ABSOLUTELY NOT ACCEPTABLE. If we can't find a quick acceptable solution to this problem, we will be saying goodbye to Jira.

I hope someone at Atlassian is looking into the need for better tech leadership and can provide an explanation.

[mr_Miller]

It's terrible. Atlassian, please, do something with that.

[Lee Meyrick]

If you are using SendGrid, can we just use our own API key for sending?

I already have SendGrid working correctly.

[Demian Hauptle]

I have also spent a lot of time setting up jira service desk. I really hope that Jira can provide a solution because besides this issue I've been very satisfied with their toolkit.

Hopefully someone takes note of the comments above and provides a solution ASAP

[Matthew Casperson]

The sendgrid aspect is challenging given there have been a number of observed phishing attacks that are perpetuated through abusing their services. Put another way, the whitelisting approach is effectively asking to whitelist a phishing platform given the way sendgrid gets abused. I think the ask here would be a bit more tolerable if you were using something like AWS SES, are there any plans to move away from sendgrid?

[Josh Resch]

sigh... WL sendgrid is not tenable and disabling DMARC is not happening. Next?

[Christian de Bellefeuille]

Who else is watching this issue in 2022 while this problem is there since ages and see that Atlassian didn't fixed this?  They are not even thinking about fixing it... they are at the "GATHERING INTEREST" on JRASERVER-40169 since 2014! 

[Jeff Reek]

@Christian de Bellefeuille This has been implemented recently.

Have a look at https://community.atlassian.com/t5/Jira-Service-Management-articles/Doing-Jira-Service-Management-Customer-Notifications-Right/ba-p/1877664?utm_campaign=kudos_article&utm_content=topic&utm_medium=email&utm_source=atlcomm 

[Matthew Casperson]

Clarification, does that solution cover both service management projects and software projects? Put another way, does this solution for both external email-based communications (i.e. service management project notifications) and also internal email notifications (i.e. software project notifications)?

[Jeff Reek]

@Matthew Casperson To my understanding Atlassian finally made the effort to solve both issues.

[Christian de Bellefeuille]

@Jeff Reek , i'll have a look at this, thanks