Passwordless Email Code Delays and Missing Emails via Custom Provider (SendGrid)

Hi Auth0 Community,

We’re encountering issues with passwordless login (code-based) using a custom email provider (SendGrid via API) in our EU tenant.ifying_glass_tilted_right: First try searching for your answer.

:warning: Issue 1: Email Code Delivery Delays Leading to Expired Logins

  • Auth0 logs show the email code was “sent” (type: cls) at T₀.
  • SendGrid logs show the same message was processed ~2.5 minutes after T₀.
  • Emails arrive promptly after SendGrid processes them, but by that time, the one-time login code is already expired.
  • This delay happens even under low system load.
  • We’ve updated the passwordless code expiration time to mitigate the issue, but this seems like a workaround rather than a fix.

We suspect there may be queuing or throttling within Auth0 before the message is handed off to SendGrid.

:warning: Issue 2: Emails Marked as Sent by Auth0 but Missing in SendGrid

In a few instances:

  • Auth0 logs (type: cls) indicate that the code email was sent.
  • However, the corresponding email does not appear in SendGrid analytics (no processed, delivered, or bounced events).
  • The affected addresses are not suppressed, bounced, or invalid in SendGrid.
  • No email_sending_failed or fapi logs were present in Auth0 for those cases.

This suggests a possible silent failure or drop between Auth0 and SendGrid, despite the successful cls log entry.

:magnifying_glass_tilted_left: Summary of Actions Taken

  • Confirmed SendGrid API integration is active and responsive.
  • Checked for suppression/bounce issues — none found for affected recipients.
  • Verified that email_sending_failed logs are absent in these cases.
  • Increased the passwordless code TTL, which reduces the impact of delay but does not address root cause.

:person_raising_hand: Questions

  1. Could Auth0 be internally delaying or queuing emails before sending to SendGrid?
  2. Are there cases where an email could be marked as sent (cls) but never reach the email provider?
  3. Are there known issues or limitations when using SendGrid via API for passwordless code flows?
  4. Is there a way to enable more visibility into the email sending process (e.g., pre-send logs, retries, failures)?

I’d appreciate any insights or guidance to help me resolve this or improve reliability and observability of my passwordless login emails.

Thanks in advance!


Ilya

Hi @Ilya.dev

Welcome to the Auth0 Community!

I will be taking a look at the issue that you are having and will come back as soon as possible with more information!

Kind Regards,
Nik

Hey @nik.baleca

Thank you :raising_hands:

Hi again @Ilya.dev

From what I understand, you seem to be using the Custom Provider option for the email provider and not SendGrid, right?

The behaviour that you are describing seems to be just a delay between your Auth0 tenant and the SendGrid API, however, I am not sure what might be causing this issue.
Otherwise, if the email appears to have been sent via the Auth0 logs but SendGrid did not receive any request, it might be an issue with how you are making the request.
Also, for more information on more visibility during the process, you would need to console log within the action window to see if there are any problems detected by Auth0 if the SendGrid API does not show anything.

For further troubleshooting, if you are using a Custom Provider implementation with the SendGrid API, would you mind replying with the action code that you are using or send it to me via a DM so I can check it out and perform some tests on my end?

Kind Regards,
Nik

Hey @nik.baleca

I am using Sendgrid option, not custom provider. So I have no action code, I just provided API token. Looks like I don’t have any control how Auth0 makes requests.

Regards,
Ilya

Thanks for letting me know!

I will need some time to perform tests in my environment and I will let you know of the outcome and if I am able to replicate the behaviour you have stated above.

Kind Regards,
Nik

Hi @nik.baleca , do you have any update on the above? I have taken over this project from Ilya, and we keep running into this e-mail delay. We cannot really understand nor affect why these email OTPs are so slow to arrive, would greatly appreciate your input here.

Hi @mz-telgea

Welcome to the Auth0 Community!

I am sorry about the delayed update to the issue at hand, however, I needed some time to test this out in my environment and check out the issue internally regarding the matter.

As far as I have tested, I was not able to reproduce any of the issues mentioned above using my tenant unfortunately. I believe that the cause for the delayed OTPs is not necessarily caused by your SendGrid configuration or any other Auth0 settings. Most probably the cause might be related to the internal queue between Auth0’s service and the API call made to the SendGrid API for the email. Usually, these types of operations are quite fast and you should not encounter any specific delays, however, under some circumstances (spikes in traffic, API calls made by your application and tenant during the operation). The most common solution for this kind of behaviour would be as Ilya has done above, to increase the TTL for the code. Otherwise, if you are also using a custom domain, I would recommend checking the DNS configuration and see if there are any visible delays or validation errors that appear whenever an OTP email is being sent out.

Otherwise, for the other issue, where the emails appear as sent on Auth0’s side but are never received by the email provider:

  • A possible cause is that SendGrid sends a non-error response back to Auth0, in which case it will not display any logs. Regarding this, if there is any necessary troubleshooting to be performed, would be to use the Custom Email Provider instead of the SendGrid one. This can be done under the Dashboard → Branding → Email Provider → Custom Provider. You would need to implement your own call to the SendGrid API and wrap it under a try...catch block in order to log any possible responses from their end regarding the matter. You can review these logs under Monitoring → Action Logs.

If I can help with anything else regarding the matter of if you have any other questions, let me know!

Kind Regards,
Nik