Troubleshoot SendGrid API access through QuotaGuard
Start by identifying which connection failed. Your application first connects through the QuotaGuard proxy to the SendGrid HTTPS API. SendGrid then handles a separate email-delivery process. A successful API request does not establish delivery, and an undelivered email does not by itself indicate a proxy problem.
Use the checks below to narrow the issue without broadening access or exposing credentials.
Start with the observed result
| Observation | First place to investigate |
|---|---|
| Proxy connection, DNS, or TLS error | Runtime network access and proxy configuration |
| Proxy authentication failure | QuotaGuard proxy username, password, and connection URL |
| IP checker returns an unexpected address | The exact client, proxy settings, and bypass behavior |
| SendGrid rejects the request for an IP restriction | Assigned pair, SendGrid allowlist, and actual calling process |
| API authentication or permission error | SendGrid API key and required scope |
| Mail Send payload validation error | Request fields, data types, sender, and recipient configuration |
Sandbox returns HTTP 200 |
Validation succeeded; no delivery should occur |
Live request returns HTTP 202 |
Submission accepted; inspect the delivery pipeline |
| Some jobs work while others fail | Different workers, versions, runtimes, or network paths |
Status codes alone are not a complete diagnosis. Correlate a failure with the request time, the sanitized error category, the originating runtime, and SendGrid’s account-side information.
The IP check does not match the dashboard
Run the check from the actual sending runtime with explicit proxy configuration. Compare the result to both assigned QuotaGuard addresses.
Check these common causes:
- The secret is present but the HTTP client never uses it.
- A queue worker has a different environment from the web process.
- A second library opens the real SendGrid request.
- An ambient
NO_PROXYor client-specific bypass changes the route. - A new deployment has not restarted the relevant processes.
- The addresses copied into the expected-IP check belong to another subscription.
Do not add the unexpected address to SendGrid merely to make the test pass. Establish why the request used it first.
A successful IP check made by curl only proves curl’s egress configuration. Repeat the relevant check through the production client’s transport before concluding that the application uses the same route. QuotaGuard verification guidance
Only one QuotaGuard IP appears in repeated checks
Use the assigned pair from the dashboard as the source of truth. A short run can reuse connections or select the same proxy path repeatedly, so it may not show every possible assigned address.
Allow both assigned IPs. Do not manually select just the observed address or remove the other to simplify the list. A configuration that depends on seeing only one address can become intermittent when the outbound path changes.
SendGrid rejects an IP after the proxy check passes
Confirm that the SendGrid call uses the same client configuration as the IP check. The checker must not be a separate utility with settings the sending library ignores.
Then inspect:
- Both assigned addresses in SendGrid’s allowlist.
- The SendGrid account or subuser used by the failing key.
- The region and API endpoint configured by that client.
- Every process that can send email, including retries and scheduled jobs.
- Recent access attempts near the failure time.
SendGrid’s access-attempt view includes source IP and method information. Use it as evidence to identify the caller, not as a list to approve in bulk. SendGrid IP Access Management
The proxy rejects authentication or cannot be reached
Copy the full HTTP proxy URL from the correct QuotaGuard subscription. Check that it has not been truncated, URL-decoded incorrectly, or copied with surrounding whitespace.
Verify that the runtime permits an outbound connection to the proxy host and port. If the application runs behind a separate firewall or network policy, that policy still needs to permit the proxy connection.
Keep the proxy credentials separate from the SendGrid key. Replacing the proxy password with an API key cannot authenticate the proxy.
After rotating the QuotaGuard password, update every sending runtime that uses the connection. Restart or redeploy clients whose connection configuration was loaded only at process startup. Do not print the full URL while debugging.
A TLS verification error appears
Check the destination hostname, proxy URL, runtime trust store, and system time. The examples keep certificate verification enabled.
HTTPX with trust_env=False ignores ambient certificate configuration as well as ambient proxy settings. If your organization requires a custom CA bundle, provide an approved SSL context explicitly. Do not set verify=False or use curl’s insecure option as a production fix. HTTPX environment variables
The proxy URL scheme describes the client-to-proxy transport. It does not become https merely because the final destination is an HTTPS API. Use the exact QuotaGuard Static connection supplied for the account. HTTPX proxy transport explanation
SendGrid reports an API authentication or scope problem
Confirm that SENDGRID_API_KEY is set in the sending process and belongs to the intended SendGrid account. Check that it is current and has the operation’s required permissions.
For a mail-only worker, use the required Mail Send scope rather than assigning full account access. Adding more IPs does not repair a revoked key or a missing permission. SendGrid API keys
Avoid copying API keys into terminal commands, screenshots, tickets, or shared logs. If a credential has been exposed, rotate it through your normal security process and update all affected runtimes.
The sandbox check succeeds but no email arrives
That is the expected behavior. With mail_settings.sandbox_mode.enable set to true, SendGrid validates the request without delivery. There should not be Email Activity or Event Webhook events for that sandbox request. SendGrid sandbox mode
To evaluate delivery, obtain approval for one live recipient and submit a controlled non-sandbox message. Keep the subject and recipient clearly identifiable to the people reviewing the test.
Do not switch production traffic to live mode as a way to investigate a request-formatting problem.
The live request returns HTTP 202 but delivery is missing
Treat HTTP 202 as an accepted submission. Review SendGrid’s email activity and your event-processing information for the message. Check the configured sender, recipients, suppression behavior, and other delivery-side signals. Mail Send reference
QuotaGuard controls the application request’s egress path. It does not replace SendGrid’s delivery infrastructure or repair an email reputation problem. Keep API routing diagnostics separate from deliverability diagnostics so that a successful network path is not changed unnecessarily.
A request times out and the application wants to retry
First decide whether the request could already have reached SendGrid. A connection failure before a request is submitted and a lost response after submission have different duplicate-send risks.
The supplied examples make no automatic retry. In a production worker, use bounded retries and internal job tracking appropriate to your notification requirements. Record the uncertain state and inspect available evidence before replaying a live message. Do not assume a timed-out send was rejected.
For sustained failures, pause or slow the affected queue under your operational policy instead of repeatedly generating uncertain submissions.
The administrator cannot access the SendGrid UI
Your browser and application can have different outbound addresses. The QuotaGuard settings inside a worker do not route the administrator’s browser.
Use an already approved administrator network if available. If the account is locked out, contact SendGrid support using its account-recovery process. Avoid deleting the last working allowed address while attempting a repair. SendGrid lockout guidance
For prevention, document a stable administrator route before changing restrictions and verify it after the change. An open browser tab is not a substitute for an allowed future login path.
Collect a useful support bundle
Provide the following through your approved support channel:
- UTC timestamp and approximate duration of the failed attempt.
- Application platform and the specific process or worker.
- Language, HTTP client, and relevant package versions.
- Whether the failure was an IP check, sandbox request, or live request.
- Expected assigned IPs and observed source IP, where appropriate for the channel.
- HTTP status or sanitized error category.
- Whether both assigned addresses are allowed and administrator access still works.
- Recent deployment, secret rotation, or network-policy changes.
Do not include the proxy password, full credential-bearing connection URL, API key, authorization headers, message content, or unnecessary recipient data. If support needs a more detailed trace, agree on a restricted collection and redaction method first.
Download the reference examples · Integration overview