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; } } }

URL filter blocking the domain "atlas-trk.prd.msg.ss-inf.net"

jeff.schuelein

As of today our email security application is blocking access to the following domain redirect "atlas-trk.prd.msg.ss-inf.net" as spear-phishing, after clicking on view request from an automated Jira ticket email. Can someone tell me what this URL redirect is for and whether it is safe? Thx

Accepted answers

Andy Heinzer

Hi @jeff.schuelein

Sorry for the inconvenience here. Yes I can confirm that this URL is legitimately used by our Cloud messaging services. However it appears that new domain was not yet included into the official domains and IP ranges documentation.

It appears that the feature flag that enabled this change has been rolled back for now (within the last day and it can take some time to take affect in all environments) So perhaps the update to documentation might not be coming so quickly. However my understanding is that this change is being reverted as of now.

All comments

Dave Rosenlund (Trundl)

Welcome to the community, @jeff.schuelein 👋

I cannot find any information about this happening anywhere or to anyone else. So, I suspect you'll need your email security vendor's help here or the administrator of that system or service to whitelist that address.

However, given the urgency, I will escalate this thread to Atlassian support to see if they can provide helpful guidance.

Good luck,

-dave

jeff.schuelein

Thanks for the quick reply. I was able to whitelist the domain in order to prevent further issues in our environment. I was mostly curious what it was doing and if this was the new norm when opening Jira ticket links within our emails. Thx

Steve Smith_2mgp66

We have end users also getting this URL being used.

https://atlas-trk.prd.msg.ss-inf.net/f/a/

Is this a valid Atlassian url?

Christian Sorbello

Following.

This also started happening to us today. Emails are being blocked by our filter.

Can anyone confirm the validity of the domain and what has changed?

Christian Sorbello

Update:

I raised a support ticket with Atlassian who advised this is an intentional change, although they have not yet updated their IP Addresses page... IP addresses and domains for Atlassian cloud products | Atlassian Support.

Andy Heinzer

Hi @jeff.schuelein

Jan Tymiński_1pw3uu

Great.

So Atlassian is cool to go against the grain.

All the security trainings train people not to click strange-looking URLs and Atlassian introduces one as a legitimate URL (when a truly legitimate URL could be used instead) and will start teaching all these people to stop worrying about such URLs.

Atlassian, you can do much better and I expect you revise this approach and improve here.

This way you're contributing to lowering global security in the times where it gets extremely important to do everything to improve it.
Please take a couple of minutes, meet there internally and discuss this approach and an option to generate genuinely looking urls.

If there's `customer.atlassian.net` available for the `customer`, everyone at `customer` should get URLs starting with `customer.atlassian.net` within the spaces of the `customer.

I hope my point here is clear why it is important to not use urls like `blah-blahblah.blah-some.random-gibberish.unrelated-to-atlassian.net`

Raimo Neumann

@Steve Smith & @Jan Tymiński , same here!

Years of cyber security awareness training got our employees to finally be more careful with e-mails and an ever rising threat due to conflicts in Ukraine and the Middle-East.

Now they're reporting (supposedly) Atlassian-E-Mails containing URLs using, https://atlas-trk.prd.msg.ss-inf.net/f/a, which, in every sense of cyber security training success, is correct.

If I'm reading @Andy Heinzer's answer above correctly, this is a legit domain for Atlassian Cloud Services (such as Confluence). However, it would be great to have that confirmed for this type of e-mail before releasing it to our employees.

Sender-domain is id.atlassian.net.

Thanks heaps in advance!

Andy Heinzer

Hi @Raimo Neumann I reached out to my internal team about this. They have confirmed that this domain is owned and operated by Atlassian. This new address does not yet appear within the documented list of IP Address Ranges and Domains for Atlassian Cloud products, however I have also reached out to my documentation team to update that content.

Raimo Neumann

Thanks heaps for confirming @Andy Heinzer! 🙌🏼

Martin Kaul

sorry, I can't believe that atlas-trk.prd.msg.ss-inf.net is an Atlassian domain. It will be blocked by us. Why do not use a address atlassian.net or so...

Best regards

Martin

Andy Heinzer

Hi @Martin Kaul

We have recently updated the documentation in IP addresses and domains for Atlassian cloud products to include this domain. This is in fact a domain that Atlassian uses.

Jan Tymiński_1pw3uu

@Andy Heinzer looks like Atlassian is OK with proceeding with this domain.
I see it as similar move to what a company in Poland recently did.
Security people try their best to learn people to avoid weirdly looking domains by all means and here you come acting like it is perfectly fine to use a weirdly looking domain in production.

Has Atlassian thought about something like social responsibility?

I completely understand @Martin Kaul and if I would be the one to manage deny list of domains, this one would land there regardless of being legitimate.

Did the company consult that idea with internal security team?

Martin Kaul

Hi @Andy Heinzer

I agry to @Jan Tymiński

It is not the point that this address is a valid address from Atlassian. We sensitize our people not to click on cryptic links. When the domain is atlassian.com then its readable and understandable. But "atlas-trk.prd.msg.ss-inf.net"??? A potential hacker only needs to change one character of ss-inf.net for example to ss-int.net - and then the people click the link.

An other point is, that Atlassian is not the only company with Messages send to us. What should we do? Read URL documentation of all of our connected companies to get the list of all valid domains of the companies?

No, No, when Atlassian want to send us Messages with valid links, then do not use links with cryptic mysterious domains - use your valid and (important) readable company domain.

best regards

Martin

JB_bau4nn

I agree with the sentiments expressed here. We have e-mail rules that flag e-mails containing links that do not match the originating domain as spam -- especially clickable links. We furthermore train our user not to click any links or buttons that looks suspicious or otherwise do not pass the smell test. A button/link to "ss-info.net" coming from "atlassian.net" is a good example of what we mean by "does not pass the smell test". Why jump through hoops to make these e-mails look suspicious when it's otherwise so easy to make them be 100% squeaky clean legitimate?

Corey Burke

Adding to the sentiment here that it's not ok to use phishing-like domains. Please use atlassian.net.

Małgorzata Łopacińska

The access is not blocked . Our user got the phishing invitation from this Domain .

Andy Heinzer

@Małgorzata Łopacińska

Please forward any such emails to https://www.atlassian.com/trust/report-abuse

If someone has used our Cloud services to send spam/phishing this is the best way to let our anti-abuse team know about it and be able to take steps to suspend that site.

Brian Debler

To pile on the discussion here:
Using "/atlas-trk.prd.msg.ss-inf.net/" is a very poor choice for a domain. Atlassian REALLY needs to use a conventional domain associated with "atlassian.com" or another domain with Atlassian in it to insure we can trust its tools.

borgdrone7

So...

Not branded: No obvious connection to Atlassian or their products. Not even a *.atlassian.com CNAME.

Sketchy structure: atlas-trk.prd.msg.ss-inf.net feels like a burner domain from a shady email campaign or malware C2.

Breaks every security heuristic: Most secure email gateways, proxies, and endpoint filters will flag it — as they should.

Confuses your own users: If your legitimate link looks like phishing, you’ve failed at UX and trust.

I just spent an hour frantically trying to cleanup after clicking this link.

What a nightmare.

Brian Debler

Just to make sure your findings are the same as mine:

This very-questionable "atlas-trk.prd.msg.ss-inf.net" URL is LEGIT, right? These are actual emails from Atlassian?

Later emails I have gotten from Atlassian also have this URL source. I still have not actually clicked on one of these links, but when verifying their information through normal login, all of the facts checked out. In other words, these links SEEM to be legit as far as I can tell.

I am nagging about this on this thread to hopefully generate enough noise that Atlassian changes this URL to something far less easy to spoof.

I still CRINGE thinking about HOW EASY it would be to fake this thing. The original domain is "ss-inf.net", right? Seeing that typed out really make it scream "HACKER".

Jan Tymiński_1pw3uu

Atlassian claimed this is legit.

I don't know what to say...

Brian Debler

Thanks. It is good to have another source of confirmation for this.

Airtrade IT Services

Hi Atlassian team,

We’ve received multiple reports from employees that recent Jira notification emails are being flagged as suspicious or even phishing/spearphishing attempts. The concern revolves around the use of the tracking domain atlas-trk.prd.msg.ss-inf.net, which is unfamiliar and not clearly associated with Atlassian.

In the current threat landscape, where attackers are increasingly infiltrating organizations via convincing email spoofing and credential phishing, using obscure or third-party domains like this, especially without clear communication or branding, is asking for trouble. Even though the intention might be to track click behavior (which we understand as a common practice), doing so through a non-Atlassian domain undermines trust and triggers security controls.

We strongly urge Atlassian to reconsider this implementation. Tracking is fine, but it should happen via recognizable, trusted Atlassian-owned domains. Otherwise, these messages are likely to be blocked, reported, or ignored, defeating their purpose and creating unnecessary risk.

Looking forward to your response and clarification.

Kind regards,

Remco

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-service-management-cloud

jira-service-management