Forwarding emails into Jira Service Management: what gets lost and how to keep it

1. The reporter is the mailbox, not the customer

When a shared mailbox (security@, support@, legal@) forwards a message to the Jira project address, Jira sees the mailbox as the sender. The ticket's reporter becomes the mailbox account, the real customer is not on the request, and the customer never gets the "request received" confirmation.

Check what Jira actually received. In the project, go to Channels & self service, then Email, then View logs, then Processing log, then More, then "Download raw email message". If the From line is the mailbox, the sender's identity was lost before Jira saw the message; no Jira setting brings it back.

Fix it at the source. Instead of forwarding, connect the mailbox itself as an email channel of the project ("Add external email", a Jira admin can do this). Jira then reads the original messages, with the customer as sender. Check two settings at the same time: whether the project is Open or Private for customers, and whether unknown addresses may create an account when they email the project. If both are closed, requests from new customers may be refused ("Signup is not currently available").

2. In Outlook, the first email does not join the conversation

A customer sends a request, Jira answers with a confirmation, agents reply from Jira. In the new Outlook, everything after the first email groups into one conversation, but the customer's original email stays on its own. This is a known limitation, not a misconfiguration: Outlook groups messages by headers (Thread-Index, In-Reply-To, References), and Jira's confirmation is a new message that does not reference the customer's original. Moving or removing the issue key in the subject does not help; the headers decide.

There is no Jira Service Management setting that changes this today. What works: point customers to the "View request" link in any notification (the portal shows the full history), and accept that the first email sits apart in Outlook.

3. Formatting and inline images do not survive

An HTML email that arrives as a ticket description or comment loses part of itself: lists come out flat, signatures come out wrong, and inline images show "Preview unavailable" in the comment while the image files appear as attachments. HTML parsing for the email channel is the setting to check first; people report the problem with it switched on. The faithful copy of the email is the email itself, and the ticket does not keep it: the raw message sits in the email processing log (Channels & self service, Email, View logs) until the Database cleaner removes it, not on the work item.

If the exact appearance matters (a complaint, a contract, a phishing report), attach the original message to the ticket as a file. From Outlook, drag the message onto the work item, or save it as .msg or .eml and upload it. The file keeps the formatting, the inline images, the headers and the attachments inside the message. Jira Cloud cannot display that file on its own; see how to open .msg and .eml attachments in Jira.

4. Signature images become attachments

Every reply by email adds the sender's logo, social icons and banner as attachments to the ticket. Atlassian added a built-in check that skips duplicate images from emails; users report it misses images that mail clients re-encode. Atlassian's own knowledge base describes a workaround with an Automation rule and a webhook that deletes attachments by file name pattern, with the warning that deleted attachments cannot be recovered. Test such a rule in a sandbox project before switching it on, and keep it to the projects that receive email.

Which route for which desk

• A customer-facing desk (IT support, HR, facilities): connect the mailbox as a channel, send customers to the portal link, and tolerate the Outlook quirk. The ticket text is what matters.
• A desk that handles evidence (security reports, legal, procurement, complaints): the email as it was sent matters. Attach the original .msg or .eml to the ticket in addition to the forwarded text, so the headers and the exact content are there when someone asks.

Reading the attached email on the ticket

Once the original email is attached as a file, the remaining problem is reading it inside Jira. Marketplace apps add a viewer to the work item. For a service desk, compare them on: both formats (.msg and .eml, including forwarded emails that arrive without a file name), where the email is processed (prefer apps that render in the browser with no external servers, "Runs on Atlassian"), nothing stored, and whether headers and links are shown so a reported email can be judged without opening it elsewhere.

Full disclosure: Dortus makes such an app. MailView shows .msg and .eml attachments on the work item, including forwarded emails attached without a file name, reads the attachment with the permissions of the person looking, renders it in the browser, stores nothing, and adds a plain-English check of the headers and links for reported emails. It works in Jira and in the Jira Service Management agent view.

Short answers

Can Jira keep the original sender when a mailbox forwards the email? Not from a forwarded message: the forward is sent by the mailbox. Connect the mailbox as an email channel instead.

Can I make Jira's confirmation join the customer's Outlook conversation? Not with a Jira Service Management setting today; it is a known limitation. Use the portal link.

Does Jira keep the original email file? Not on the ticket. The email becomes a ticket or comment; the raw message is only in the email processing log. Attach it yourself when you need the exact copy on the work item.

Questions

Running a desk on email and unsure which route fits? Email support@dortus.com.

See also: Jira Service Management not creating requests from email