Handling phishing reports in Jira Service Management

How phishing reports arrive on a request

Most teams route reports into JSM through its email channel. Three patterns are common:

• Forward as attachment. The user forwards the suspicious email to the service desk address as an attachment. The original arrives on the request as a .eml file, or, when it goes through Jira's mail handler, as a file without an extension.
• Report button in Microsoft 365. If your tenant sends user-reported messages to a custom mailbox and that mailbox is the JSM email channel, every report becomes a request with the original message attached.
• Drag and drop. An agent or user drags the message from Outlook onto an existing request. Classic Outlook produces a .msg file, new Outlook and Mac clients produce .eml.

Forwarding inline (the text pasted into the body) is the one pattern to discourage: it drops the headers, which are exactly what you need to judge the email.

Looking at the email without opening it in Outlook

JSM cannot show .eml or .msg attachments; it offers them as a download. The habit that follows, download and open in Outlook, is the one thing phishing training tells people not to do: it can load remote tracking images, render active content and make the links one accidental click away. Safer options, in order:

1. Read the raw .eml in a text editor. Safe, but the headers are hard to read and the body is often base64 or HTML soup.
2. Use a viewer that renders the email with scripts, forms and remote images stripped, and that shows the headers in plain words. Inside JSM is best, so the triage happens on the request and the answer goes back through the same ticket.

What to check

Authentication results. The receiving mail server records three checks in the headers. SPF: was the sending server allowed to send for that domain? DKIM: was the message signed by the domain and unchanged since? DMARC: does the visible From address line up with those two, and what did the domain owner ask to happen on failure? A fail on all three is a strong signal; a pass on all three does not prove the email is safe, only that it really came from that domain. The email check on this site shows these results for a file or pasted headers, as the receiving server recorded them.

The From domain. Look for lookalikes: an extra letter, a swapped character, an accented letter that renders like the real one, or the brand name in a subdomain of an unrelated domain. Compare it with the Reply-To address, which attackers often point somewhere else.

Where links really go. The link text and the link target are two different things. Check the target of every link and button, and treat "the text says our portal, the target is somewhere else" as a red flag. When you paste a link into the ticket, defang it (hxxps://, dots in brackets) so nobody clicks it by accident.

Attachments inside the email. Note the names and types. Office files with macros, archives and HTML files deserve a sandbox, not a double-click.

Pressure. "Within 24 hours", "your mailbox will be suspended", "final notice". Urgency is the oldest trick and still the most common.

Answering and closing

Write the findings into the request in plain words so the reporter learns something: which checks failed, which domain was faked, where the link went. Keep the original attachment on the request; it is your evidence. If the email was genuine, say so and thank the reporter, because the next report from that person may be the one that matters.

Doing this inside JSM

Full disclosure: Dortus makes an app for exactly this. MailView shows .eml and .msg attachments on the request in the agent view, with scripts and remote images blocked, and adds a Details tab with the SPF, DKIM and DMARC results from the headers in plain English, warnings for domains with lookalike letters from other alphabets or with accents, the address behind every link, and a "Copy findings" button that puts a defanged summary in the clipboard for the ticket comment. It runs on Atlassian and stores or sends nothing. It is an aid for the agent's judgement, not a replacement for it.

Short answers

Can JSM preview a reported email? No. .eml and .msg attachments are downloads only.

Is a DMARC pass enough to mark a report as safe? No. It shows the email came from the domain it claims. A compromised or newly registered domain passes just fine.

Should agents open reported emails in Outlook? Not as a routine. Use a text editor or a viewer that strips active content, and check the link targets before anyone clicks.

Questions

Spotted something wrong on this page, or a case we missed? Email support@dortus.com.