Clerk is great for OAuth. Here's how to keep sign-up working when its email stops.

During heavy testing and verification of our auth and reset flows, Clerk decided to lock the SMS and email code mechanism for our production app. No sign-up codes, no password resets, no workspace invites.

Good thing Clerk has a way for super-admins to sign in once and get back into their development and production environments. But clearly, this is not a fun thing to let a client know about right before submitting to the OpenAI plugin store.

Written in October 2026. Clerk's features, plans and prices and Resend's API are described as they stood that month.

I still think Clerk is the right call for auth. I wrote about why in Clerk vs. rolling your own auth. This post is about the one piece you shouldn't let depend on Clerk alone: the emailed codes behind sign-up and password reset.

Why Clerk is great for OAuth

ecco, an agent work coordinator, is a shared task board for people and their AI agents. You can try it at heyecco.com. The agents, ChatGPT, Claude, Codex and Claude Code, connect over MCP, and every one of them signs in with OAuth.

That's a hard auth problem. Each agent client registers itself, sends the person to a consent screen, gets a token scoped to one workspace, and refreshes it for weeks. Clerk handles the whole authorization server:

• Client ID Metadata Documents and dynamic client registration, so a new agent client registers itself.
• PKCE, the protection that stops an intercepted code from being reused.
• A consent screen where the person picks read-only or write access.
• Refresh tokens, so agents stay connected without a person in the loop.

We wired agent OAuth into ecco in five days. Most of that was our side: binding each token to one agent identity and checking its scope on every call. The authorization server itself was configuration.

Case in point: when OpenAI's review asked for OAuth with PKCE and an RFC 9728 resource pointer, we already had both.

What happened during the OpenAI submission

OpenAI's plugin review needs a test account that signs in with a password and nothing else. No emailed code, no second factor. Reviewers reject accounts that need one.

So on October 1 we did what the review asked:

• created a dedicated reviewer account;
• turned off Clerk's Client Trust, the check that emails a code when someone signs in from a new device.

The next day we tightened a few settings: renamed the app in Clerk from a placeholder to "ecco", turned on strict enumeration protection, and added a terms-and-privacy checkbox at sign-up.

On October 3 at about 8:20 PM Eastern, a sign-in code to a test account never arrived. The Clerk dashboard showed a banner: email and SMS sending disabled for the app.

We checked everything on our side:

• DNS, mail and DKIM records for our domain: verified.
• Every email template: enabled and delivered by Clerk.
• The account: not locked, email verified.
• A direct API test: Clerk accepted the request and returned "unverified", then sent nothing.

Case in point:

• 1 security check turned off, at the review's request.
• 0 sign-in codes delivered after 8:20 PM on October 3.
• 0 explanations in the dashboard.

It was a lock on Clerk's side. I filed an appeal that night with the details above, including the security change we'd made for the review.

More than 36 hours later, Clerk support hadn't replied.

What the lock broke

A blocked email channel sounds small. It's the front door.

• Sign-up: new people can't verify their email, so they can't create an account.
• Password reset: the reset flow sends a code. No code, no reset.
• Invitations: a workspace owner can't add a teammate.

Clerk's one-time super-admin sign-in got us back in. But that exposed a larger issue: it was a one-time fix, not a permanent workaround. Every user who forgot a password, and every new sign-up, would hit the same wall.

There are two ways around it. Which one you get depends on your Clerk plan.

Option 1: send Clerk's emails through Resend (Clerk Pro)

Clerk has a setting on every email template: "Delivered by Clerk." Switch it off and Clerk stops sending that email. Instead, it fires a signed webhook, `email.created`, with the rendered message: recipient, subject, HTML body and plain-text body. Your server sends it through Resend from your own domain.

The catch: that switch is a Pro feature. As of October 2026, Clerk's Pro plan starts at $25 a month. On the free plan, the dashboard answers with "The Custom email templates feature is not available on your current plan for production instances."

We built this path before we hit that wall, so here it is.

1. Add your domain to Resend. Create a Resend account, add the domain you send from, and add the DNS records Resend gives you: a DKIM key and two CNAME records on subdomains. Your existing mail records stay untouched. Ours verified about four minutes after the records went in. Resend's guides cover adding a domain and what to check if it won't verify.

2. Give the server two settings. An API key with sending access only, and a from address on your verified domain. The key lives in your host's secret settings, never in the repository. Resend's API keys guide shows where to set both.

3. Subscribe Clerk's webhook to `email.created`. In Clerk's dashboard, open the webhook endpoint your app already uses and add the event.

4. Handle the event. Our handler does four things:

• Verifies the webhook signature, as it already did for every Clerk event.
• Sends only events marked `delivered_by_clerk: false`, so an email Clerk still sends never goes out twice.
• Uses the webhook's message ID as Resend's idempotency key. If Clerk retries a delivery, Resend recognizes it and doesn't send a second code.
• Records the webhook receipt in the same database transaction. If Resend is down, the transaction rolls back, our endpoint answers with an error, and Clerk retries later.

One rule we didn't bend: a verification email is a one-time code, so the body never touches our logs. Failures log the provider's status code and nothing else.

5. Switch the templates (this is the Pro step). Turn off "Delivered by Clerk" on the emails that matter: the verification code, the password-reset code and invitations. Clerk's email and SMS templates guide describes the setting and the webhook it sends instead.

6. Test the real flow. Request a password reset for a real account and confirm the code arrives from your domain. Then sign up fresh with an email address.

The handler is about 130 lines, with tests for the duplicate, retry and logging cases. It's deployed and our domain is verified in Resend. It sits idle until the templates are switched over.

Option 2: GitHub and Google sign-in (free plan)

The free plan allows up to three social connections. For a developer or technical audience, GitHub and Google sign-in should cover about 90% of your potential user base. Neither one needs an emailed code: GitHub or Google has already verified the address. Clerk's own guide to taking an app to production walks through the same screens.

1. Create a GitHub OAuth app. In GitHub, go to Settings, Developer settings, OAuth Apps, then New OAuth App. Set the callback URL to Clerk's: `https://clerk.<your-domain>/v1/oauth_callback`. Leave wildcard matching and device flow off. Clerk's GitHub connection guide has the full steps.

2. Create Google credentials. In production, Clerk's Google sign-in needs your own Google OAuth client. We found this the hard way: the Google button we'd been showing new users failed until we created one. Clerk's Google connection guide covers the Google Cloud side.

3. Paste both into Clerk. Under SSO connections, choose custom credentials for GitHub and for Google, paste each client ID and secret, and turn them on.

4. Turn off email sign-up. Under User & authentication, switch off sign-up with email, and switch off email code and email link sign-in. If those switches are locked, it's because strict enumeration protection is on. Drop it to bulk protection first.

5. Keep password sign-in for accounts you already have. We left sign-in with email and password on. Existing accounts keep working, and so does the test account OpenAI's reviewers use. Turn off Device Trust too, or a password sign-in from a new device asks for an emailed code that never comes.

6. Test in a private window. The sign-up page should show only GitHub and Google. A password sign-in should go straight in.

What you give up: a person without a GitHub or Google account can't sign up, and anyone who signs in with a password can't reset it until email works again.

Why splitting the jobs is more resilient

Identity and delivery are separate jobs. Clerk proves who someone is and issues each agent's token. Email delivery is a different job. A problem in one shouldn't take down the other.

There's more than one way in. With GitHub and Google next to email and password, one locked channel no longer closes the front door.

You own your sending reputation (Pro). With Resend, codes come from your own domain with your own DKIM key. If deliverability drops, you can see why in Resend's logs instead of guessing.

Retries are safe by design (Pro). Clerk retries a failed webhook on a schedule for days. The idempotency key means a retry can't double-send a code, and the rolled-back receipt means a failed send isn't marked done.

Clerk keeps doing what it's best at. We didn't leave Clerk. OAuth for agents, sessions, organizations and consent all stay where they were.

If I set up auth for a new app tomorrow, I'd use Clerk for authentication and agent OAuth, and turn on GitHub and Google sign-in on day one. If the budget allows Pro, I'd wire email through Resend as well. Clerk's email worked fine for weeks. The one time it stopped, sign-up and password reset stopped with it, right before a store submission, and nobody could tell us why.