Zendesk Public IP addresses Follow

Zendesk maintains this list of public IP addresses to allow customers to provide whitelist rules for access to their internal resources by Zendesk servers.

This is not a definitive source, and addresses will change over time as Zendesk expands into new localities. As some of these changes reflect a change in strategy, there might not be advance notice when changes are made. Zendesk highly recommends that customers use some kind of authentication mechanism to determine whether inbound/outbound requests are valid, rather than using IP address.

Note: IP addresses are listed using Classless Inter-Domain Routing (CIDR) notation. You can convert IP addresses using this CIDR Utility Tool.

IP Addresses

LAST UPDATED: 2016-07-05

174.137.46.0/24
96.46.150.192/27
96.46.156.0/24
104.218.200.0/21
185.12.80.0/22
188.172.128.0/20
192.161.144.0/20
216.198.0.0/18

52.192.205.30/32
52.193.22.204/32
52.37.220.11/32
52.27.183.82/32
52.37.212.231/32
52.203.58.200/32
52.203.0.71/32
52.21.112.236/32

Note: There may, from time-to-time, be new IP addresses added or removed. We will strive to keep this document updated with those changes, though it may be operationally necessary to add new IP addresses.

Need help? As this list may change from time to time, we invite you to submit a ticket to support@zendesk.com with any questions, comments, or concerns about new addresses that may not be documented here.

Outbound Email Servers are listed in our spf record, which we update as needed.
Our spf record can be read by these commands:

host -t TXT mail.zendesk.com

or

dig txt mail.zendesk.com

Have more questions? Submit a request

Comments

  • 0

    Hi,

    I am not able to find the Subscribe button. Can someone please help me.

  • 0

    Hi Shaik!

    You'll find the Follow button at the top of the article:

    Screenshot

  • 0

    Hi! My domains are resolving to 185.12.82.1, shouldn't this be on the list?

  • 1

    Hi Emmanuel,

     

    The IP  185.12.82.1 is covered by the subnet of 185.12.80.0/22

     

    The subnet mask 255.255.255.252 equals  /22

    Hope this helps.

  • 1

    I noticed a new range was added here, but since there wasn't a post, I never got an email.

    So, I'm posting that the ranges 

          52.192.205.30/32

          52.193.22.204/32

          52.37.220.11/32

          52.27.183.82/32

          52.37.212.231/32

          52.203.58.200/32

          52.203.0.71/32

          52.21.112.236/32

    have been added

  • 1

    Thanks for doing the needful, Allen!

  • 1

    Thanks Allen! I didn't get any notifications either

    1 As these changes has security implications etc, I'd like an additional update from Zendesk confirming the validity of these these new ranges. Essentially, it wasn't clear to me if the article was updated based on Allen's information, or if the Zendesk ops team did an audit, and approved the update. Thanks!

    2 It's very nice we have a good community that helps pick up the slack here, but why is this change announcement once again initiated by a customer and not Zendesk?

    I don't know what services are offered from these new ranges, so I couldn't say what the potential effect of not whitelisting the new ranges are, but I would like to see some real improvements from Zendesk's side how these changes are communicated:

    • Have Zendesk announce and confirm any changes (=make the source of information clear)
    • Give us a heads up, so we have a chance to react (=in my case, we do change requests for firewall on certain fixed weekdays)

    Others has already voiced these kinds of concerns, but since nothing seem to have changed since the last time this happened, I ask that you please review and improve how you handle this product area.

    Edited by Joel Hellman
  • 0

    Agreed Joel.

    I happened to spot the change when looking up something unrelated in the community, and made my post in reaction to the post being updated [ostensibly by a Zendesk employee who knows]. Of course, that's not clear at all in my post

    In this case, I think it's a matter of the person updating the article not knowing the importance of making a "hey, I updated the body text of this article" post.

    I don't like to think about the failures our app might have if we were denying target notifications that we have Zendesk make to our app. I fully agree that getting advance notice would be even betterer.

     

  • 0

    Is it possible to get more clarity on the use of this new set of addresses especially since they appear to be AWS addresses as opposed to Zendesk's own data center?

  • 0

    Hey guys,

    Joy used to take care of this, but she has since left Zendesk. I'm going to do some digging around and see if I can find out who took this over when she left and give them your feedback!

  • 0

    Hi Brendan, We have updated the text of the article to reflect Zendesk's developing strategy. Thank-you for pointing this out to us.  

  • 1

    I can basically just copy/paste my reply in 2014 when you (= Zendesk) tried to fix this problem 'textual' as well.

    I just notice that a note has been added that the list shouldn't be considered exhaustive. For us that's quite a problem. We have clients using Zendesk that have a strict whitelisting policy, because of their business.

    We've experienced problems too in the past with this list not being up to date. Adding such a disclamer doesn't really help us.

    It seems there are many people that need a proper list that's up-to-date, and early warnings of changes in this list. We have clients that use IP whitelisting, and quite frankly they rather drop Zendesk, than their policy.

  • 1

    > "Zendesk highly recommends that customers use some kind of authentication mechanism to determine whether inbound/outbound requests are valid, rather than using IP address."

     

    Gladly!  If only we could :(  The Mobile SDK JWT Url request is sent without any option of authentication, so ip is currently the only way we can validate if the request is coming from you.

    Edited by Patrick McAndrew
  • 0

    Hi everyone,

    We recently released Zendesk App Framework v2. ZAF v2 introduces a new way of building Zendesk apps using iframes. As part of this new framework we have built a feature called Signed URLs which allows app developers who host apps on their own infrastructure to validate that an app request originates from a legitimate Zendesk instance. Using this feature would avoid the need to whitelist Zendesk IPs.

    Note: This feature is only available in ZAF v2.

    Cheers.

  • 0

    Interesting news Phil.

    Will there be a related API endpoint we can use to retrieve an up-to-date IP address range?  

  • 0

    Hey Allen,

    We don't currently have plans to provide a list of IPs through an API. We're trying to reduce the need for whitelisting - that's what we're trying to do with Signed URLs for apps.

    What's your use case for the IP list? Are you trying to validate requests coming from Apps? Targets?

    Thanks

    Edited by Joe
  • 0

    Thanks Joe

    In our integration with Zendesk, we use the API to auto-create a target for Zendesk to inform our app of events through a target. At the moment, we have to allow the Zendesk IP block as a form of authorization, much like Patrick a few posts above.

    It's a json call, and at the time we set this up, there was no password storage in Targets at all.  It looks something like this - http://zip.wtch.mn/3m3z0k3T413M

    If there's a way to set up token authentication here, with secure storage, I'd welcome a ticket so we can get that hammered out (we can post the results back here later).

    Thanks!

  • 1

    Do these ranges also cover zendesk chat?

  • 0

    Hi John- 

    The list of Zendesk Chat (formerly Zopim) IPs is not currently documented. In general, Chat will use the following IP range - 67.23.229.0 up to 24. We highly suggest a wildcard white-list based on hostname for *.zopim.com instead. It's definitely going to change from time to time, and resulting in the suggestion to use hostnames instead.

  • 0

    I'm demoing zendesk now and the Jira add-on will be critical to the demo.  I see the top block are all actually registered to Zendesk, and the bottom ones are not.  My zendesk demo server resolves to 192.161.156.x, which is in the 192.161.144.0/20 block.  My IT department is not going to be very happy to open any ports to their Jira server to such a large block of IPs.  (The /20 block is 4094 addresses, and the /18 block is over 16,000).  We also block overseas traffic.

    Is there a more restricted range that could be used for the Jira add-in?  Also, I see a lot of traffic here about people finding out addresses change only after things break.  Have ZDs change management practices improved?

  • 0

    Hi Patrick. I talked with the team and our policy is to recommend whitelisting this full list for the JIRA add-on. We do not have a more limited range for use with JIRA.

    We do update this list as changes occur, and you can follow the article to get notification emails when this happens. However, as stated in the second paragraph of this article, there may be situations where we are not able to provide advanced notice of such changes. I am sorry for any inconvenience this causes your team.

  • 1

    Hi, this is a totally unaccepted practice to do. To ask people to subscribe for an article so they to be informed when their integration could be broken, because an IP was be changed..... And you tell us that Zendesk can't think of a way where these IPs to be retrieved by an API call for example, instead monitoring our emails for a notification that a single or many IPs were changed or added or whatever.I just can't believe that such a big company, which you says you are cannot think of a way where this process to be automated and to stop asking people to monitor for emails which some times are not send and to do manually whitelisting each time when a change occurs. We are already enough busy to monitor the huge amount of suspended tickets, which again must be checked manually ... shame ...

  • 0

    I'm speaking with regards to the Jira Add on.

    If I understand correctly, my account's domain (support.acme.com) will be making the calls to the on premise Atlassian/Jira instance? If that is the case, than wouldn't I just need the IP(s) that my specific domain is hosted for the whitelist?

  • 0

    While that's technically true, it's common practice for a SaaS to claim a range of IPs, giving them the ability move data around inside there as they see fit.

    For instance, Apple only publishes 17.x.x.x, without any clue where within their global range the traffic might go to, or from.

    With all the pods ( and related supplemental services) zendesk is maintaining, the best I would expect to get is a relatively pruned list of IPs from Zendesk, and have it kept up to date.  Bonus points for allowing us to make an API call to get the current list. We'd script that in a daily update and be very happy campers.

Please sign in to leave a comment.

Powered by Zendesk