DMARC Failures: Improving Atlassian Notification Delivery

[#1]

Hey Community folks ! My name is Waqas, and I’m part of the APAC Cloud Support Team. I wanted to share my recent experience with a customer who was facing problems with email notifications not being received due to a DMARC failure on their end. However, according to our MXtoolbox, the DMARC configuration appeared to be correctly setup.

Understanding DMARC and Email Delivery

To begin, let’s take a closer look at DMARC, a protocol designed to safeguard your domain from unauthorised usage, including phishing and email spoofing. When you send an email, it navigates through spam filters that assess the DMARC policy. If the email does not meet this policy check, it may be blocked, quarantined, or discarded.I would like to present a diagram that illustrates the functioning of industrial spam filters. In this diagram, MTA stands for Mail Transfer Agents (the mail servers), while MUA refers to Mail User Agents (the end users who receive the emails).

In IT, whenever an email is sent, it first passes through a spam filter. This filter verifies the DMARC policy. Depending on the outcome of this verification, the email is either forwarded to the mail server for processing or, if the verification fails, quarantined or discarded.

I have analysed the initial failure messages from the customer side and made the following observations:

1. The DMARC header results were included in the X-IMSS-DMARC-Authentication-Results header instead of the Authentication-Results header. This indicates that the header was added by a third party Spam Filter.

2. The SMTP mail sender address is mail-us.atlassian.net, rather than sitename.atlassian.net. We have identified a bug that causes emails to be dispatched from mail-us.atlassian.net instead of sitename.atlassian.net. However, this discrepancy should not lead to any failures, as mail-us is a subdomain of atlassian.net.

   
   To ensure the integrity of our DMARC records and tackle concerns about potential misclassification by spam filters—especially given that millions of users depend on the system—we can leverage a lesser-known feature in Jira called "Send Email." This can be found under Cog > System settings › Send mail.
   
   

The notification sent from the Send Email utility was not received at the customer's official company  address, although it was successfully delivered to the customers private google address. Google showed the following headers, which claimed that SPF and DKIM records are ok.

Following the test, the SPAM filter logs were examined, revealing the true root cause of the issue. It was not a failure of the SPF or DKIM protocols; rather, the problem stemmed from a misalignment between SPF and DKIM.

The root cause of the problem lies in the SPAM filter settings, which are configured in strict mode and don't respect the relaxed alignment as per RFC 7489. This configuration does not align with the relaxed mode specified in Atlassian's DMARC records, leading to the rejection of email notifications.

Strategies to Enhance Atlassian Notification Deliverability

To ensure that email notifications are received without issues, consider the following options that can be implemented if you face above scenario:

1. IP Whitelisting: Ensure that you whitelist the IP addresses associated with Atlassian notifications in your SPAM filter.

2. Consult Your SPAM Filter Vendor: Seek advice from your SPAM filter provider regarding email alignment to improve deliverability.

Conclusion

By understanding the nuances of DMARC, using the Send Email Utility effectively, we can significantly improve email delivery for Atlassian notifications. If you have any questions or need further assistance, please feel free to reach out in the comments!