Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal


  • Give kudos
  • Received
  • Given


  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

DMARC might be blocking your email notifications from Jira

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 * 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 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 Community Leader Jul 31, 2020

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

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?

@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 * domain. 

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

@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.

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.

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.

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!

So.. of the 3 "workarounds" above.

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


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


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.

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

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.

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.

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

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

I already have SendGrid working correctly.

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


Log in or Sign up to comment

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you