Cara suas perguntas me fizeram chegar no problema mas de qualquer forma vou responder todas até pra chegarmos numa solução mais específica:

"Foi analisado os logs do resend? Esta dando algum erro?" R: Analisei o log do resend e não tem nada, nenhum erro lá, é como se ele nem tivesse chegado a ser enviado pra lá.

"(como @Ytu sabiamente apontou) O domínio de produção está verificado? (lembrando que o domínio delivered@resend.dev é só para testes)" R: O domínio está configurado corretamente e eu alterei esse cara aí pro domínio correto.

"O token de acesso do resend esta com permissão para o domínio em questão e para a função de envio?" R: Sim, tudo configurado conforme a documentação do resend e o domínio também está configurado corretamente para comunicar com o resend.

"O NextAuth tem a própria abstração de envio de email de validação, se você estiver fazendo através dele, pode ter faltado um configuração de url de envio para a produção (tem um exemplo nas docs do Resend)" R: Estou fazendo por fora, no momento de armazenar os dados do usuário no banco eu também gero o token que será enviado por email e faço a requisição da rota "/api/send".

"[Improvável] Se estiver disparando o email atráves de um api route do Next usando Server Components, lembre de que a rota deve ser informada por completo, incluindo o host (Ex: https://myapp.vercel.app/email/verification)" R: Estou passando a rota completa, pego a env NEXT_PUBLIC_URL juntamente com a /api/send no momento do fetch.

"[Improvável] O email pode estar caindo em spam ou na pasta de promoções (aconteceu comigo :c)" R: Ele nem está sendo disparado.

"Foi analisado os logs da vercel? Esta dando algum erro?" R: Analisando esse carinha aqui, eu recebi o seguinte erro [POST] /api/send reason=EDGE_FUNCTION_INVOCATION_FAILED, status=500, user_error=true

LucasHangano passado

Show de bola, nesse caso um try/catch fazendo o console.log do erro pode resolver o mistério. A vercel mostra o console.log nos logs deles na plataforma.

A única resposta que ainda me deixou em dúvida foi a respeito do host usado na requisição do api route do next. Você disse que esta usando - corretamente - a variável NEXT_PUBLIC_URL, mas o protocolo (http ou https) esta sendo corretamente definido também? Isso foi um erro que cometi nas minhas primeiras tentativas de implementação, pois em dev seria http, mas em prod precisa ser https (usei o NODE_ENV para decidir nesse caso).

meopedevtsano passado
Opa, a parte do NEXT_PUBLIC_URL a versão de produção possui uma branch específica e um .env específico que sobe junto com o deploy na vercel, essa tá configurada com https apontando já pra url do domínio configurado na plataforma, até o momento não achei uma solução pro problema, já tentei outras abordagens utilizando serveless function mas sem sucesso...
LucasHangano passado
Caso ainda precise de apoio, a unica forma que vejo de seguirmos adiante seria com exemplos do código usado mesmo. Fico a disposição.
meopedevtsano passado
Depois de uns dias de luta, não consegui resolver aí mudei o cenário inteiro. Dando uma pesquisada acabei encontrando o Clerk https://clerk.com/ Eles proveem todo um sistema de autenticação com fatores de verificação nativamente e é super simples de implementar, tanto que na plataforma deles tem um vídeo mostrando como fazer a implementação num projeto em 2 minutos, sem falar que eles possuem um plano gratuito que aceita até 5k cadastros na base. Acabou que migramos toda a parte de sign-in/sign-up pro Clark e refatoramos algumas funções de protected routes.
LucasHangano passado
Já ouvi ótimos comentários do Clerk, acredito que tenha feito uma boa escolha. Você comentou que esse projeto tem back e front separados, mesmo assim eu recomendo o Supabase como opção para esses casos também, ele abstrai (além de várias outras coisas) o processo de autenticação.
meopedevtsano passado
Opa, valeu demais pelo feedback, é muito bom saber que o Clerk foi uma boa escolha kk Depois vou dar uma olhada no supabase. E novamente muito obrigado pelas dicas e pelo apoio.