Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Custom Domains in Cloud - Our Approach

Hi everyone,

Thank you for your engagement on our last update. Based on your feedback, we would like to provide more detail on the following topics:

  1. Security considerations underlying custom domains and how they contribute to the two-level domain requirement

  2. Support for URL redirects, which will provide more flexibility and address most limitations of the two-level domain

Security considerations underlying custom domains

The security of our customer’s data is always the top priority at Atlassian. When it comes to custom domains, having a two-level domain plays a critical role in making our solution resilient to potential man-in-the-middle (MITM) attacks.

Atlassian’s platform is designed to be open and allow all Atlassian accounts to collaborate across our products and the organizations using them. Therefore, our approach to custom domains needed to be secure, while supporting our multi-tenant SaaS architecture and global user accounts. This means we prioritized capabilities to detect, contain, and control individual user authentication sessions. By detecting threats using a more “prescriptive” URL structure, including reserved keywords, we fortify our threat detection efforts.

We understand the concerns about the convenience tradeoff of the two-level domain requirement, but security of customer data is our highest priority.

Support for URL redirects

To ensure customers have full flexibility, we support URL redirects, which allow you to create links with a shorter, fully customizable base URL. In this case, you can utilize a redirect to redirect your users to the secure URL.

Screenshot 2023-05-15 at 10.07.48 PM.png





Short URL

(URL Redirect)

The link your customers will visit, the one you will use in marketing material for your Help Center.

Secure URL

(Custom domains)

The link your customers will see in their browser after they arrive.

Thank you for your patience and partnership. We continue to look for ways to improve Atlassian admin and end user usability without compromising security.

Stay tuned as we prepare to begin our early access program for custom domains. We remain on track for delivery this year.



Can you clarify what specific MITM attack scenarios you're trying to mitigate?  

Like # people like this

The security of our users is our highest priority. Redirecting to a different URL is a red flag and should not be something we train our users to find acceptable. is not more secure than

This is not a matter of convenience. This is a matter of usability. We can do a redirect now via hundreds of third-party or internal redirection setups.

The limitation of approved keywords is out of touch with the real world uses of your product and does not align with customer expectations.

Like # people like this
Alex Cumberland
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
May 15, 2023

I am wondering the same thing as @Adrian Smith ... how is one https more secure over another https ???

Also if this is the big solution that has taken a decade to come up with then why would we be so vocal about the situation if all we had to do was set up a cloud account and use redirect via any one of the third-party or internal redirection setups.   All you are doing is coming with what we could already do but you are adding another domain level.   So really what is the point ??

Like # people like this
Luke Liu
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
May 15, 2023

@Boris Berenberg - Modus Create Supporting custom domains introduces third-party traffic controls between users and Atlassian servers. A malicious admin could potentially phish for a user's authentication token and use it to access all products and contents that the global user account has access to. 

@Adrian Smith The URL is more secure as it narrows the scope of threat detection, so that the system could detect potential threats (such as invalid certificate) quickly and accurately, and auto initiate containment and controls. We continue to look for ways to enhance the system performance but for the current release we opted to introduce these experience constraints. 

Like # people like this

If we wanted to use a redirect for custom domains, we would not need to wait till Atlassian has implemented it. It's like using a url shorten.

The short domain is also not used in the emails notifications, etc.

The urls based on the custom domains (server oder data center version) are shared across organisations and customers, the user experience isn't great if you're simply redirected. This means that you have to communicate that the users was redirected to new domain. You have to have a banner to communicate the behaviour. No, thanks!

The solutions with secure domain looks like a shortcut to simplify the logging and monitoring by only tracking requests based the keywords. With such well-known keywords and this monitoring behaviour, you open the door for more misuse than if have a proper monitoring. This seems to me more insecure than a proper monitoring.

Overall the value of this combination of redirect + custom domain solution is quite limited.

Like # people like this

@Luke Liu If this method is needed for appropriate detection of invalid certificates, you may want to update your method for detecting invalid certificates.

Like # people like this

I am not sure I understand how a reserved keyword in the domain will impact the admins ability to phish or not phish a user.

Can Atlassian point to any known or documented attack on any other SaaS product that this mechanism explicitly prevents?

Can Atlassian point to any other SaaS product which has implemented this restriction?

Like # people like this

Still nothing about custom http root paths such as /jira with any number of subdomains.

I do not see how having more subdomain keywords makes it easier to detect certificate forgery. If the certificate is different, it is different, the number of subdomains is irrelevant.

If you want to prevent against a malicious administrator, you could either sell a DNS service the user must point to, not allow one or zero level subdomains if the instances have any global accounts associated with them (aside from the creator), lock the instance if the server detects any DNS change at all, or simply allow companies to make their own risk management decisions.

Like # people like this

I am still not convinced by this explanation. How do other Cloud providers that allow what we all want here do? Aren't they secure? Do you mean limited subdomains is now the new best security practice? Something is wrong here IMHO... 

Like # people like this
David at David Simpson Apps
Marketplace Partner
Marketplace Partners provide apps and integrations available on the Atlassian Marketplace that extend the power of Atlassian products.
May 15, 2023


Like # people like this
Alex Cumberland
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
May 15, 2023

It almost sounds to me like someone in Marketing came up with the idea that more words in the URL must mean that we can charge more right ?

Is there a possibility that this "solution" is actually intended to deter their customers from using it so that Atlassian's domain will remain in an end user's address bar?

Like # people like this
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
May 15, 2023

@Luke Liu please provide some transparency to your customers with specifics on the claim of potential MITM attacks. If it is a critical role as you state, don't you think people deserve an explanation?

We all waited a long time to get this update and as usual it is sub-standard.

btw, the hostname in the 'secure URL' is a 4LD.

Like # people like this

Hej Atlassian,

Using a 1st level custom domain is a widespread industry best practice, and an enterprise feature offered by almost every SaaS vendor. If you are going to challenge that with the claim that this is an insecure practice, you better be able to produce credible evidence of that claim.

Where is the research paper listing how this industry practice should be voided? Where are the talks on conferences, the peer reviews by other major vendors, the discussion groups, the acknowledgments of your breakthrough discovery?

Either you produce evidence, or you should stop bullshitting your customers by making a fool of yourself in front of an entire industry.

Like # people like this

OK we're out. 

That's all nonsense. Bullshit. Rubbish. How come a fixed subdomain is safer than a user-chosen subdomain?? How come big companies fully support customer's domains without restrictions and you don't?? How come a redirection is safer than a direct access to the site!!!

You're making weird statements about security, MITM attacks and apocalypse, and providing no evidence or even explaining what you're trying to avoid. Invalid certificates? Don't you know how to detect a valid certificate? If I can forge a certificate, I guess I might be able to forge a certificate. Even more, I can forge a certificate and rule the world!!

Please stop fooling us and implement what we customers need and asked for.

All the rest is rubbish.

If you don't have the ability to implement this, or if the initial arquitecture of the app is not suitable for this (which, in the end, I think it is where all this issue boils down to), just acknowledge it, we'll take no revenge, but please stop this nonsense.

Like # people like this

I don't know Rick, it seems fake

Like # people like this

I was upset about this before, but this response was a total slap in the face. 

My first thought when reading this was the same as Aniceto's. We're out.

I didn't want to go through the trouble of moving but I really don't want to support a company like this. 


I think this community has shown a lot of patience and probably would have responded a lot better to a hard truths than to have lies like this presented as fact. 

Like # people like this

And this update comes a month and a half after the below update that was on April 4. I think these guys are messing with us. The above is another whole article giving no new information. 


 Update Apr 4

To reiterate an earlier comment, thank you all for your engagement and feedback. 

We know how important it is for you to have a clear and detailed understanding of the technical reasons behind the constraints and how they enhance your security experience with custom domains. We will come back with a separate update addressing this soon, and will provide more details on the optional URL redirect feature. 

Like # people like this
Craig Castle-Mead
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
May 16, 2023

@Luke Liu  - I’m with everybody else on this thread. Your response here shows you’ve blatantly ignored all the customer feedback (“Don’t F*** the customer”, yeah?) and tried to justify why with some un-quantified BS that doesn’t seem to be an issue for any other SaaS vendor on the market that supports exactly what your customer base is expecting Atlassian to deliver on.

Back up your statement with peer validated reasoning, or, build what we’ve been waiting for for 11 years (and your marketing team put up on a slide as “coming soon” at Barcelona summit in 2017 or 2018…)


Like # people like this
Dave Meyer
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
May 16, 2023

Hi everyone,

Thank you, as always, for your candid feedback. We truly do value it.

As the Head of Product for our enterprise cloud product development, I stand by both our implementation approach for custom domains and our communications around it.

On the implementation: we believe the current approach meets the needs and provides value to a large number of customers looking for a custom domains solution and offers a level of customization that very few SaaS collaboration products match. We're intentional about balancing security, customization, and the open collaboration that makes Atlassian products unique.

On the communication: I believe one would be be hard-pressed to find a single feature for Atlassian where we have provided more frequent and regular updates over the last two years than custom domains. Between Community posts and updates on the ticket, we are making a good-faith effort to be transparent about security risks without being irresponsible. We also attempt to provide clear and concise updates while still communicating valuable details.

Finally, comments that cross the line into personal criticism of Atlassian staff will not be tolerated. This has no place in our community.


Like # people like this

Are you planning to change to something like Or are you imposing this unnecessary change on your customers?

Dave Meyer
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
May 16, 2023

@Jahaziel Calderon this is an optional new feature. No customer will be required to change anything.

Currently, Atlassian cloud product URLs take the form of where the subdomain is selected by the customer.

When custom domains are available, customers will be able to configure a URL for their cloud product of the form subdomain.keyword.rooturl.tld, where the subodomain, rooturl, and tld (top-level domain) are all completely customizable and the keyword is chosen from a list of options from Atlassian.

@Luke Liu you almost had me! Yes, if a malicious admin sets up a way to phish for user accounts they get credentials to access other Atlassian products from other companies. That's a dangerous thing you should definitely protect against.

However, first and foremost, this shows what a terrible idea the Global User Account system is. It's no inconvenience to anyone to create a new account for every Jira instance they need to access. In fact, I think a lot of your customers don't even want to allow just anyone to access their Jira, they only want their own employees on it, with their corporate email, not a personal account. Global User Accounts are a serious threat to you applications' security. You've backed yourself into a corner with it, and now you think custom domains are the security issue to solve when it's really this.

Secondly, what's to stop anyone from creating a fake Jira login page, host it at any domain at all, and phish for credentials? This is simply not something you can protect against in this way. Implement the industry standard protections against phishing if you haven't already, and stop fooling yourself into thinking that this will stop anything at all.

Like # people like this

@Dave Meyer  No wonder this project is so botched. You missed the point @Jahaziel Calderon was making. 

Are you going to be applying this same terrible structure to your own URL's that you are forcing on anyone who wants a custom domain.

so will now be


This is extremely embarrassing for Atlassian and i'm so glad I don't have to put my name on something like this.

Like # people like this

Extracted from your comment above:

On the communication: I believe one would be be hard-pressed to find a single feature for Atlassian where we have provided more frequent and regular updates over the last two years than


The bigger question here is why after all these years, you still needed two years of "providing updates" that offer very little information and upset the user base with the bit of information that is given. 

Like # people like this


Log in or Sign up to comment
AUG Leaders

Atlassian Community Events