What the DMARC?!

Brandon Viertel

Good morning Atlassian Community,

We enabled DMARC protecting for our JSM site roughly a year ago, and it... works, I guess. One of the things that we've struggled with is having a org friendly name where users can send mail to, ex. test@myorg.com. We use Microsoft for our org mail. I will also preface this by stating that I am by no means an expert in mail.

We have a process setup where we have a Shared Mailbox in our org that users send to, that then forwards the mail to the appropriate atlassian.net project. That works great for addresses for users with our domain, gmail.com, yahoo.com, and some other addresses. However, legitimate emails going through this process are failing DMARC when hitting JSM after they have been forwarded by the Shared Mailbox, with hotmail.com, outlook.com, and some others always failing the DMARC check after forwarding. 

I know that you can create an OAuth connection to an account within the mail settings per JSM project, but our org is hesitant to allow login and mailbox enabled accounts for this intent with our current policies.

Something I did read, was that there's this thing called ARC validation, which I'm hoping that Atlassian will implement for their DMARC checks in the near future. 

I want to know if anyone else has figured out a solution, on the JSM or Microsoft side, that still allows enforcing DMARC but not failing entire domains. If you have also struggled with this, feel free to chime in. Or even if you have an "unofficial" solution, we're open to it. 

Thanks! 

Brandon 

James Gamble

Hola Brandon,

What you're seeing is a normal failure mode for forwarded mail rather than a problem limited to Hotmail or Outlook. DMARC requires either SPF or DKIM to pass and align with the address in the visible From header. When Microsoft 365 forwards the message to the Atlassian-provided address, the forwarding hop changes the sending path, which can break SPF. If the message or its headers are altered, DKIM can fail as well. Domains with stricter DMARC policies will expose the problem more consistently.

Microsoft 365 uses the Sender Rewriting Scheme for external forwarding, but SRS mainly repairs the envelope sender used by SPF. It doesn't rewrite the visible From address, so it can't guarantee DMARC alignment. ARC could preserve the original authentication result through the forwarding chain, but that only helps when the final receiving service validates and trusts the ARC chain. I couldn't find Atlassian documentation confirming that Jira Service Management currently uses ARC to override these forwarded-message DMARC failures.

There also isn't a reliable Microsoft transport rule exception that'll preserve the original customer as the sender while ensuring every forwarded message passes Atlassian's DMARC check. Rewriting the visible From address to your own domain could align authentication. Still, it would change the requester's identity and weaken the check's security value, so that I wouldn't use it for a service desk intake channel.

The clean supported approach is to connect the organization-friendly Microsoft 365 address directly to the JSM email channel instead of forwarding it to the atlassian.net address. That lets Jira retrieve the original message from the mailbox before a forwarding hop breaks authentication. Atlassian documents connecting Microsoft accounts through OAuth here.

If your policy doesn't permit a mailbox-enabled account for that purpose, I don't think there's another dependable native configuration that preserves both strict DMARC enforcement and the original external sender. In that case, I'd raise an Atlassian Support request asking specifically whether ARC validation is supported or planned for the JSM incoming email processor. Atlassian also notes that forwarded messages often fail DMARC and that custom email accounts offer greater control.

Thanks,

James