Table of Contents

Troubleshooting DeskDirector Connection Issues

Niamh Ferns Updated by Niamh Ferns

Service IP Addresses

Connection issues from DeskDirector to your various services can be caused by firewall restrictions in your environment or an incorrectly configured proxy. Depending on your location, we would have built your instance on a server close to where you operate.

To figure out which you are on, you can open a console and use the following command:

ping <your subdomain here>.deskdirector.com

You will see an output that looks something like this:

C:\Users\Jane.Doe>ping customer.deskdirector.com

Pinging dd-au-1.deskdirector.com [4.191.174.158] with 32 bytes of data:

Please make sure you have whitelisted this IP in your company's firewall. This IP address can change from time to time, so if you notice a drop in connectivity, please confirm whether you have whitelisted the correct IP.

Troubleshooting Custom Domains

Please note that any DNS records you set up should be CNAME records pointing to your DeskDirector.com instance - do not point an A record to the IP.

Step 1: Confirm your .deskdirector.com domain resolves correctly

DeskDirector instances are hosted on regional infrastructure. Your .deskdirector.com domain should resolve to a DeskDirector-managed target (commonly a server CNAME or front-door endpoint).

Run a DNS lookup for your DeskDirector subdomain:

Windows (Command Prompt): nslookup yourcompany.deskdirector.com

macOS/Linux (Terminal): dig yourcompany.deskdirector.com

What to record
  • What record type you see (CNAME/A record)
  • The target it resolves to (e.g. a dd-xx-x.deskdirector.com hostname or a front-door style endpoint)

Step 2: Confirm your .deskdirector.com URL loads the login page

Open your .deskdirector.com URL in an incognito/private window:

  • Example: https://yourcompany.deskdirector.com

You should reach the DeskDirector login page (either directly or via your custom domain redirect if configured).

What to record
  • The exact URL you entered
  • The final page you land on
  • Any error message (e.g. DNS_PROBE_FINISHED_NXDOMAIN, 404, 502/503, This site can’t be reached)

Step 3: Confirm DNS propagation

Even if DNS looks correct from your location, DNS changes (or resolver issues) can affect some regions and not others. A propagation checker helps confirm whether failures are widespread or localized.

What to do

Use a public propagation tool such as: dnschecker.org

In the tool:

  1. Enter your domain (start with yourcompany.deskdirector.com)
  2. Select the record type you care about (commonly CNAME or A, depending on what you expect)
  3. Review results across multiple locations

If you use a custom domain, repeat the same test for support.yourcompany.com.

Step 4: Confirm you can sign in successfully

Attempt to sign in from your .deskdirector.com domain first.

Typical sign-in options vary by configuration, but commonly include:

  • Sign in with Microsoft
  • Email token / magic link (if enabled)
What to record
  • How far you get in the login process
  • Whether you reach the Admin Portal successfully
  • Any error text (copy/paste) or screenshots

Step 5: If you use a custom domain, confirm it resolves to your DeskDirector domain

DeskDirector custom domains typically require your custom domain to resolve to your .deskdirector.com domain (commonly via CNAME). This supports SSL certificate provisioning (e.g. Let’s Encrypt) and correct routing.

What to do

Run a DNS lookup on your custom domain: nslookup support.yourcompany.com

The custom domain should resolve (directly or indirectly) to your .deskdirector.com domain.

Step 6: If you use a custom domain, confirm the site loads and SSL is valid

Open your custom domain in a browser

  • Example: https://support.yourcompany.com
  • Does it load the DeskDirector login page?
  • Is the SSL certificate valid (no browser warning)?

Provide as much supporting evidence from the above steps to the DeskDirector support team.

How did we do?

Contact DeskDirector Support

Contact