Why your Auth0 emails are going to spam (and how to fix it)

Getting started with Auth0 for authentication is often a smooth process. That is, until you hit a common and frustrating snag: your users start reporting that verification codes, password reset links, and magic links are all landing in their spam folders. This is a problem that can grind your user onboarding to a halt and leave a terrible first impression.

This is more than a minor inconvenience; it's a critical failure in the user experience. When essential transactional emails are flagged as spam, it erodes trust in your application before a user has even logged in for the first time. I've seen this issue countless times, and thankfully, the fix is straightforward once you understand the root cause.

When you first start with Auth0, your emails are sent through their built-in email provider. This is designed for testing and getting started quickly, not for production traffic. These emails often come from a shared domain like auth0user.net, which immediately signals to mailbox providers that the email isn't truly from your brand.

The core issue here is shared reputation. Auth0's default provider uses a pool of shared IP addresses for all its customers. This means if other applications on the same infrastructure are sending low-quality mail, their poor reputation can negatively impact your deliverability. It's a classic case of "guilt by association."

This setup also creates problems with email authentication. Because the emails originate from Auth0's servers, not yours, achieving proper alignment for protocols like SPF, DKIM, and especially DMARC is difficult. Many users report their OTP emails go to spam due to DMARC issues. This misalignment is a major red flag for services like Gmail and Outlook.

While less common, sometimes the issue can also be that your own domain has been flagged or is on a blacklist (or blocklist) for other reasons. However, in the vast majority of cases where emails from Auth0 applications are marked as spam, the sending infrastructure is the primary culprit.

The single most effective way to solve this problem is to stop using the default provider and configure a custom email provider for your production environment. Auth0 fully supports this and, in fact, recommends it for any serious application.

Using a dedicated service like Amazon SES, SendGrid, or Postmark gives you complete control over your sending domain. You'll be building your own sender reputation, isolated from the activities of others. This is the foundation of good email deliverability.

The setup process is well-documented. You’ll choose an email service provider, add and verify your domain with them, and they will provide you with the necessary DNS records to publish. This usually involves adding SPF and DKIM records to your domain's DNS settings.

Once your DNS is configured, your provider will give you SMTP credentials or an API key. You then simply enter these details into the "Email Provider" section of your Auth0 dashboard. Auth0 will then route all its emails through your configured provider, correctly signed and authenticated from your domain.

To ensure your emails are trusted, you need three key DNS records. The first is SPF (Sender Policy Framework). This record is a list of all the servers and services authorized to send email on behalf of your domain. If you're using a custom provider, you'll add their specific value, like include:sendgrid.net, to your SPF record.

Next is DKIM (DomainKeys Identified Mail). Think of this as a digital signature for your emails. Your email provider signs each outgoing email with a private key, and receiving servers use a public key, which you publish in your DNS, to verify that signature. This proves the email is authentic and hasn't been tampered with.

v=spf1 include:mail.yourprovider.com ~all

k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com;

Suped DMARC monitor

Free forever, no credit card required

Get started for free

Trusted by teams securing millions of inboxes

Finally, there's DMARC (Domain-based Message Authentication, Reporting, and Conformance). This is a policy you publish that tells mailbox providers what to do if an email claiming to be from you fails SPF or DKIM checks. Critically, it also provides reporting so you can see who is sending mail using your domain. Always start with a p=none policy to monitor things before moving to p=quarantine or p=reject.

Implementing these three records is non-negotiable for modern email deliverability. They work together to build trust with providers like Gmail, Microsoft, and Yahoo, signaling that you are a legitimate sender and dramatically reducing the chances of your emails being flagged as suspicious.

If you're struggling with Auth0 emails going to spam, the path forward is clear. While the default email provider is convenient for initial development, it's the source of most production delivery issues. Shifting away from it is the first and most important step.

By switching to a dedicated custom email provider and correctly configuring SPF, DKIM, and DMARC, you take control of your own email reputation. This ensures your critical verification codes and password reset emails reliably reach your users' inboxes, providing a seamless and trustworthy experience right from the start.