login.microsoftonline.com returns HTTP 404 (empty body) to server-side token requests from one web host

Escalate this as a Microsoft Entra gateway/network-path incident using the affected host’s public egress IP; there is no documented self-service IP-block removal mechanism, and moving the site to a different egress IP is the practical workaround while Microsoft investigates.

The token endpoint should return a structured JSON response—including for protocol or credential errors—not an empty 404. Microsoft documents throttling as HTTP 429 with Retry-After, so this does not match normal Entra rate limiting.^1^^2^

Immediate action

1. Ask the hosting provider for a different outbound public IP
   • Request migration to another host/node, a dedicated egress IP, or another hosting region/provider.
   • The important change is the outbound source IP/path, not the WordPress site address.
   • Re-run the WP Mail SMTP authorization only after the egress IP changes; authorization codes are short-lived and should not be reused.
   The closest matching Microsoft Q&A report has the same server-specific empty 404 and x-ms-gateway-slice=estsfd. Microsoft moderators identified gateway-level filtering, IP reputation restrictions, routing issues, and environment-specific connectivity as possible contributors, but the thread does not publish a confirmed cause or removal procedure.^3^
2. Open a Microsoft Entra technical support request
   • Microsoft Entra admin center → Diagnose and solve problems → Self-Service Support → Create a support request.
   • The requester generally needs at least the Service Support Administrator role.
   • If there is no Azure support relationship, use Microsoft Support for business.^4^
   Route the case to Microsoft Entra ID / Microsoft identity platform, not Microsoft Graph or WordPress support.

Evidence to attach

Provide one compact diagnostic package:

• Affected public IPv4 and IPv6 egress addresses, supplied privately in the support case.
• UTC timestamps for several failures.
• Full response status and headers from:
  • GET /common/v2.0/.well-known/openid-configuration
  • a deliberately invalid POST /common/oauth2/v2.0/token
• Explicitly note:
  • empty response body;
  • x-ms-gateway-slice: estsfd;
  • whether x-ms-request-id, x-ms-ests-server, traceparent, and Date are absent or present;
  • Microsoft TLS certificate observed;
  • the same endpoints succeed through another network;
  • Graph remains reachable from the affected host;
  • IPv4, IPv6, multiple resolved addresses, direct cURL, time, and proxy checks have already been completed.
• Hosting provider ASN, datacenter/region, and confirmation of whether outbound NAT is shared.
• A sanitized verbose cURL trace. Remove authorization codes, client secrets, cookies, and tokens before uploading it.

Ask Microsoft specifically to check whether requests from that egress IP/ASN are being rejected at the ESTS front door before an authentication-backend request ID is created.

What not to change

Do not rotate credentials, alter Graph permissions, repeat admin consent, or change the redirect URI solely for this symptom. Those settings can cause OAuth JSON errors, but they do not explain why the public OIDC metadata endpoint also returns an empty 404 from only one host. The metadata URL you tested is a documented Microsoft Entra endpoint.^5^

Do not implement aggressive retries. A genuine rate limit is signaled by HTTP 429 and Retry-After; repeated requests could create a separate throttling problem.^6^

References

1. Microsoft identity platform and OAuth 2.0 authorization code flow
2. Increase the resilience of authentication and authorization in client applications you develop
3. OAuth token requests from server consistently return HTTP 404 at the ...
4. Find help and get support for Microsoft Entra
5. Troubleshoot access token signature validation errors
6. Understanding client and server throttling in MSAL.NET