Auth0 SPF and DKIM setup

What you are setting up

Auth0 (by Okta) is a customer identity platform, and its workflows send a steady trickle of high-stakes mail: verification emails, password change links and codes, MFA enrollment and verification codes, passwordless one-time codes, blocked-account and breached-password alerts, and organization invitations. Out of the box those go through Auth0's built-in email provider, which Auth0 describes as available by default but one that “does not support production use.” Its limits are spelled out: you cannot use custom templates, you cannot customize the From address, “all emails are sent from no-reply@auth0user.net,” you are capped at 10 emails per minute regardless of type, and a high bounce rate can get sending reduced or blocked. Auth0's instruction is direct: “To remove these limits and use emails in production, set up an external SMTP email provider.”

That is the whole story for authentication. Auth0 does not hand you an SPF include, a DKIM selector, or a verification TXT, because Auth0 never sends as your domain itself. A tenant has exactly one email provider, chosen from the supported integrations (Amazon SES, Azure Communication Services, Mailgun, Mandrill, Microsoft 365 Exchange Online, Resend, SendGrid, SparkPost), a plain SMTP server, or a custom Action that calls any API you like. Whichever you choose, the SPF and DKIM records are that provider's, published under your domain exactly as if you were using the provider directly, and Auth0 simply submits messages with a From address on that domain.

Publish SPF and DKIM

Do this in two halves, provider first. Authenticate your sending domain at the provider and publish the records it gives you; our per-vendor guides carry the exact shapes, and the three Auth0 users pick most often look like this:

SendGrid   (see /kb/source-configuration/twilio-sendgrid)
  CNAME  em1234.yourdomain.com          -> u1234567.wl123.sendgrid.net     (return-path, carries SPF)
  CNAME  s1._domainkey.yourdomain.com   -> s1.domainkey.u1234567.wl123.sendgrid.net
  CNAME  s2._domainkey.yourdomain.com   -> s2.domainkey.u1234567.wl123.sendgrid.net

Amazon SES (see /kb/source-configuration/amazon-ses)
  CNAME  <token>._domainkey.yourdomain.com -> <token>.dkim.amazonses.com   (three Easy DKIM tokens)
  MX     bounce.yourdomain.com          -> feedback-smtp.<region>.amazonses.com   (custom MAIL FROM)
  TXT    bounce.yourdomain.com          -> v=spf1 include:amazonses.com ~all

Mandrill   (see /kb/source-configuration/mandrill)
  CNAME  mte1._domainkey.yourdomain.com -> dkim1.mandrillapp.com
  CNAME  mte2._domainkey.yourdomain.com -> dkim2.mandrillapp.com
  TXT    _dmarc.yourdomain.com          -> v=DMARC1; p=none; ...   (Mandrill requires DMARC; no SPF include)

Those are the documented shapes, with placeholder identifiers; copy the real values from the provider's console. Each provider also has a prerequisite Auth0 calls out. SendGrid needs an API key created under Settings > API Keys with Restricted Access and Mail Send set to Full Access. Amazon SES needs the domain and the From address verified in SES, production access requested so you are out of the sandbox, and an IAM user allowed ses:SendRawEmail and ses:SendEmail. Mandrill needs an API key from its Settings page. A generic SMTP host must support SMTP AUTH with the LOGIN protocol over TLS 1.2 or higher with a publicly trusted certificate, and Auth0 recommends port 587 (465 for some providers, and avoid 25). For all of them, the provider must accept inbound connections from Auth0's published IP addresses.

Then the Auth0 half. In the Dashboard, go to Branding > Email Provider, turn on Use my own email provider, click the provider's logo, and fill in a From address plus the credentials: the API key for SendGrid or Mandrill; Access Key Id, Secret Access Key, and Region for SES; Host, Port, Username, and Password for SMTP. Click Save, then Send Test Email. The From address is the one fact that ties the halves together: it must sit on the domain you authenticated at the provider, and for SES it must itself be a verified identity or the send fails. Auth0 will also refuse to customize anything from an @auth0.com address (the tenant “sends only default emails, ignoring any customization”), and it rejects the placeholder domains people use in testing.

Add DMARC

With the provider authenticated and Auth0 sending on that domain, the DMARC record is the ordinary one at your root domain. Start in monitor-only mode:

Type:  TXT
Host:  _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Alignment comes from the provider's records, not from Auth0. On SendGrid the DKIM d= is your domain and the Return-Path host is your em subdomain; on SES the custom MAIL FROM domain gives you an aligned Return-Path and Easy DKIM signs with your domain; on Mandrill DKIM aligns and SPF aligns only if you set a custom return-path domain. In every case the header From that Auth0 stamps has to be on that same domain for any of it to count. Build the record with our DMARC builder, and progress past p=none once the reports show the Auth0 stream aligned.

The Auth0 gotcha

The From address is set in more than one place. The address you typed on the Email Provider screen is the default, but each email template under Branding > Email Templates carries its own From field, and the Passwordless OTP email is configured on the passwordless connection's settings page rather than with the other templates. Auth0's SendGrid guide adds that for passwordless the connection's From “must match the From email address value you're using for SendGrid.” A template whose From drifts to a different domain (an old brand, a personal address someone used while testing) is delivered happily by the provider, signed with the domain you authenticated, and fails DMARC on the header From. Because Auth0 mail is sent one message at a time in response to user actions, that failure shows up as a single user who never gets a reset link, not as a bounce storm. Audit every template's From once and after every rebrand.

Every tenant is its own decision, and the built-in provider is invisible to your DMARC reports. Development, staging, and production tenants each have their own Email Provider setting, and a tenant left on the default keeps sending from no-reply@auth0user.net: authenticated as that domain, never appearing under yours, and rate-limited to 10 messages a minute. That is fine for a dev tenant and a problem for a production one someone forgot to switch. Conversely, once you do connect a provider, the Auth0 mail merges into that provider's row in your reports, so an Auth0-only failure is easy to miss if the same SendGrid account also sends your newsletter. A dedicated subdomain such as auth.example.com for the identity mail, authenticated on its own at the provider, keeps the stream visible and lets you tighten it with a subdomain policy later.

Confirm it worked

• Send the test and check the provider, not just the inbox. Send Test Email should land within a few minutes; if it does not, Auth0 points you at its tenant logs first, and the provider's own activity view (SendGrid's Email Activity, the SES console) tells you whether the message was accepted or refused for an unverified sender.
• Trigger a real workflow and read the headers. Sign up a test user or request a password reset, open the message, and confirm the From is on your domain, the DKIM signature shows d=yourdomain.com with the provider's selector (s1 or s2 on SendGrid, an Easy DKIM token on SES, mte1 or mte2 on Mandrill), the Return-Path is on your domain, and the result is dmarc=pass. Our header analyzer reads it back plainly.
• Watch the reports. The Auth0 stream appears in your DMARC aggregate reports under the provider's infrastructure, aligned and passing; trustyourinbox labels it as SendGrid, Amazon SES, or Mandrill, because that is who delivered it. If your domain never shows that source at all, the tenant is still on the built-in provider.