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