Microsoft Entra Application Proxy External URL Returns NXDOMAIN When Using a Custom Connector Group

The Default connector group is not required to initialize an msappproxy.net namespace; keep the application assigned to the intended custom group and open a Microsoft support case for the reproducible external-endpoint DNS publication failure.

Connector groups select which connectors handle traffic and can select an Application Proxy service region; Microsoft’s publishing procedure does not require first saving an application against Default. If groups do not exist, Default is merely the automatic assignment.^1^

What the results establish

The observations separate this from a backend or connector connectivity failure:

• Public DNS returns authoritative NXDOMAIN before traffic can reach Application Proxy or the connector.
• The custom connector is active and reaches the Node.js service.
• Once the external name exists, the application works through that same custom connector group.
• Saving once with Default causes the name to appear, after which returning to the custom group works.

Application Proxy is responsible for publishing the external cloud endpoint; the connector handles communication between that cloud service and the internal application.^2^ Consequently, connector-to-backend DNS, TCP 3000, Node.js, and authentication diagnostics do not explain a public authoritative NXDOMAIN.

Microsoft’s public troubleshooting guidance covers connector state, connector event logs, and application connectivity, but it does not document initial assignment to Default as a DNS provisioning step.^3^ A closely matching report exists for an Application Proxy URL remaining at NXDOMAIN, but it has no accepted or recommended resolution.^4^

Supported permanent path

1. Leave the app on the required custom connector group.
   Do not operationalize the Default-group round trip as a provisioning requirement; that behavior is undocumented.
2. Capture evidence before another configuration change:
   • UTC time when the application was created or saved.
   • Tenant region.
   • Enterprise application object ID and application ID.
   • External hostname and exact public-DNS response.
   • Custom connector-group name and configured optimization region.
   • A second test application showing:
     1. initial save directly to the custom group → NXDOMAIN;
     2. save to Default → hostname resolves;
     3. move back to custom → application remains functional.
   • Entra audit-log entries for each save operation.
   • Connector version and relevant Connector/Admin logs, even if they contain no error.
   Remove or redact tenant identifiers before posting this evidence publicly.
3. Test against more than one public resolver and retain the output:

      $name = "<external-hostname>.msappproxy.net"
   
      Resolve-DnsName $name -Server [IP Address] -DnsOnly -ErrorAction Continue
      Resolve-DnsName $name -Server [IP Address] -DnsOnly -ErrorAction Continue
      nslookup $name [IP Address]
   

   The expected healthy result is a public DNS chain ultimately resolving to an address. Application Proxy endpoints use chained CNAME records, so do not expect or configure a fixed IP address.^1^
4. Open a Microsoft Entra support request and ask for investigation of the tenant’s Application Proxy external-endpoint/DNS registration workflow. State explicitly:

   A newly published standard Application Proxy app saved directly to a custom connector group returns public authoritative NXDOMAIN. Saving the same app once with Default publishes the hostname; moving it back to the original custom group then works. Backend connectivity through that custom group is successful.

   Ask support to determine why the endpoint registration is not committed during the initial custom-group save and to correct the tenant/service-side provisioning state. The available public documentation does not expose a customer-side namespace reset or repair operation.

Conditional regional check

Only if this is actually a complex/wildcard application using a custom domain, verify the connector group’s optimized region and DNS target. Complex applications assigned outside the Default group’s region require the corresponding regional tenant-runtime suffix—for example, .eur.tenant.runtime.msappproxy.net or .nam.tenant.runtime.msappproxy.net.^5^

That rule does not provide a fix for the standard generated <hostname>.msappproxy.net URL described here. Region optimization is supported for custom connector groups, and assigning an app directly to such a group is documented behavior.^6^

References

1. Add an on-premises application for remote access through application proxy in Microsoft Entra ID
2. Microsoft Entra application proxy
3. Troubleshoot Application Proxy - Microsoft Entra ID
4. App Proxy External URL stuck at NXDOMAIN for 4+ days - tenant DNS ...
5. Understand complex applications in Microsoft Entra application proxy
6. Optimize traffic flow with Microsoft Entra application proxy