nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Unauthenticated Email Mailer Daemon When Forwarding to Jira Mail Handler

Todd Henson

When forwarding to create an issue in cloud software project, we randomly receive the a mailer-daemon with the following error message and the issue is not created "Unauthenticated email is not accepted due to the sending domain's SPF policy."

To test, I sent five emails from the same account to the same email addresses (that forwards to Jira). One of the five emails failed to create the issue even though I took identical steps to send (and automatically forward) each.

Accepted answers

Guido Leenders

Problem still occurs with our environment. Have had to make apologies on various occasions to customers and prospects which received no response to a sales enquiry and/or incident ticket. We have sent out mailing to our customers asking them to use the portal instead of mail to get in touch. I will raise ticket with Atlassian, it seems to get not sufficient attention to ensure solution, but it would also be hard to pinpoint I guess.

All comments

Bernt Linde

We have the exact same problem. I think it started a few days ago?

Todd Henson

Sorry to hear that.

Correct. It started about a week ago.

SebastianN_zkto96

We´ve seen this error as well.

Guido Leenders

Same here. Approximately 1 out of 25 customer mails. We receive email on Mx of spamhero, then forwarded to JIRA Service Desk through Microsoft Office365 exchange. No recent changes made. Used to work. Logging in preceding steps before JIRA shows no issues.

Adam Ryan_wwzgo4

Same here, started about mid-July as well

Carlos Serrano-Morales

We have started having the same issue over the past few weeks.
No changes done on our infrastructure.
Of course, this creates a pretty bad first experience for some of our users...

Guido Leenders

A helpful support engineer informed me that Atlassian has recently updated their validation policy for email using SPF. Email delivery will fail when the SPF check fails when I understand correctly. He provided excellent assistance.

In our case this means that:

* mail from users with incorrect SPF setup mailing directly to box@company.atlassian.net will not land in the ticket system (in our case 38 mails).

* mail *forwarded* from our central mailbox to the box@company.atlassian.net email address fail sometimes when the users company has set up SPF (in our case 56 mails).

At the moment we can not use the customer email account functionality because it was obsoleted being not sufficiently reliable, but even when using a customer email account, users with incorrect SPF setup mailing directly to box@company.atlassian.net will not have their mail registered.

It seems that the non-registration happens silently (no bounce mail reported).

Despite having many customers in finance and accounting, still many of them have partial or incorrect SPF setup. A popular problem being that a professional works at home at these times, but sends company mail from an incorrectly configured mail client. We can not provide assistance to so thousands of customers on how to set up their SPF properly for individual users.

For the moment, I am a little puzzled and I don't see a workable solution, except creating a custom mail handler and using the API to load them. But that takes at least several developer weeks despite having done it before. Issues such as duplicate mail detection, auto-replies etc.

Clayton Dilks

Thank you, Guido, for keeping us in the loop on your conversations and research. We've been scratching our heads on this for a month now, and it's nice to at least have the issue diagnosed.

SebastianN_zkto96

This is still not resolved and support has no solution.

We have started a project today to check the migration to Zendesk.

Sad to maybe break up with Jira - but there is no other choice. We are missing roundabout 25 important emails every day.

Guido Leenders

For us it is still unfixed. We can just forward everyone to use the portal directly (which is quite hard). I hope someone within Atlassian allows a property to be set to disable the SPF checks. I would recommend logging a case.

Guido Leenders

It is quite hard (not yet succeeded) to work around the enforced SPF check by Atlassian. We receive mails after spamhero and Office 365 spam checks. They are received at support@acme.com, archived and forwarded to support@acme.atlassian.net.

Since the problem is still relevant and we receive customer complaints about rejected tickets, I have reopened the case requesting a flag to disable the check or something else, just like you can disable SPF checks for some senders.

The Atlassian formal point of view is that the SPF enforcement is permanent and no disabled will be made possible to circumvent it for some or all customers. The argumentation is based upon security, but I don't grasp the big picture since the security guidelines are to be enforced by us as data owner over the whole process and the security risks are covered already by preceding checks.

I gathered the following solutions:

Request all customers to list acme their delivery agent IP-addresses to their DNS (not practical nor feasible for most but very dedicated parties).
Add a custom email in the support project as described on https://support.atlassian.com/jira-service-desk-cloud/docs/add-an-email-account/ (in our case that one proved operational unreliable during setup, but we will reconsider it).
When forwarding rewrite the Sender in the envelope to a domain which your delivery agent IP-addresses are allowed and upon receipt manually change the reporter to the customer's email address for every ticket.
Switch to another solution.

Regarding (3) I was made aware of the following suggestion:

JRACLOUD-71946 : Modify the mailhandlers to read 'x-original-sender' header

which would allow solution (3) to add a header to the envelope to add the intended sender.

When you think (3) is a good and feasible approach to workaround about the rigid check, please cast your vote.

We will try (2) on a test environment. When it runs apply it to production. Since our support desk service is already degraded, there is no need for extensive checks.

Todd Henson

The issue self-resolved for my organization although we did not make any changes. We are on Microsoft Office 365, so I can only assume that either Microsoft or Atlassian made a change that resolved the issue. I wish I could share more information. I accepted @Guido Leenders post on 9/23 as the closest thing to an answer. Thank you, @Guido Leenders. Good luck to everyone. I hope you are able to get it resolved.

SebastianN_zkto96

I did so.

There has been no real help.

We started investigating other solutions.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-software

mail-handler

atl-gruland

bug