How the email processor decide if an incoming email should be a new issue or a new comment in JSM Cloud

Platform Notice: Cloud - This article applies to Atlassian products on the cloud platform.

Summary

Assume that you've setup an Incoming Email address for your Service project. It can be the project's default, or a custom one. We're not considering rejected emails.

Processing emails

When it is processing an email it received, Jira will check three places for information to decide whether that email should be processed as a new issue or a comment to be added to an existing one:

  1. The sender
  2. The subject
  3. The headers

The Decision Process

With the above in mind, the usual decision flow is the following:

  1. Does the sender have the proper permissions on the project?
    1. Is your project open so anyone can send a request? if not, is the sender a customer for this particular project?
  2. Does the Subject of this email contain an Issue Key?
    1. If it does, is this particular sender involved in that issue?
    2. Is anyone allowed to comment on an issue as long as it has been identified with its key?
    3. If there are multiple issue keys on on the email subject, the first one mentioned (leftmost) takes precedence on the decision.
  3. Do the email headers contain references to other emails processed by Jira in the past?

The Headers

Steps #1 and #2 above are simple, it's on the third that things can get tricky. There are a few specific headers that Jira will take into consideration when analyzing the email headers: Message-ID, In-Reply-To, and References.

An email that is sent within a thread may have its headers look like so:

Email headers showing the In-Reply-To, Date, Content-Transfer-Encoding, Message-Id, References, and To fields.  The To email address is partially redacted.

Why is that even relevant?

Whenever Jira processes an email, that email's Message-ID header is stored in the notificationinstance table in its database:

A table with columns for ID, notification type, source, email address, and message ID. The email addresses and some message IDs are redacted. The notification types are ISSUE_CREATED_FROM_EMAIL and ISSUE_COMMENTED_FROM_EMAIL. The source IDs are numeric.

And for any new email it process, Jira will attempt to match the ids it finds in those headers to the data stored in that notificationinstance table. If any of them matches, a new comment will be added to the issue stored (by its id) on the source column.

Edge cases

Although it's not that common, there are cases where how your customer sent an email will affect that decision process and can cause confusion:

  1. Let's say that your customer needs to create two issues in your Service project, and does so via email.
  2. They write the first email with the subject "Need assistance regarding X" and send it to support@yourinstance.atlassian.net.
  3. Now, instead of writing a new email from scratch, they forward or reply to the first one, but change the subject to "Need assistance regarding Y" and send it to support@yourinstance.atlassian.net again.
    1. Note that the second email does not contain the Key from the issue that was created by the first one.
  4. However, contrary to what the project admin may expect, the second email is added as a comment on the ticket created by the first one.

This is where the headers are most relevant. By forwarding or replying to the original message, even changing the email body or subject, instead of creating a new email from scratch, their email client will add the original email's Message-ID as a reference in the new one.

With the Message-ID included in the headers, during step #3 of the decision process, Jira will match the new email to the first one, thus creating a new comment instead of a new issue.

Because of this, we'd advise you and your team to always create new emails from scratch when a new ticket is necessary.

Last modified on Mar 25, 2025

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.