O cliente solicita a recuperação de senha e não encontra a mensagem. A aplicação registrou o envio e o serviço de email mostra delivered. O problema de entregabilidade continua aberto: esse estado confirma que o servidor destinatário aceitou a mensagem, mas não informa se o email foi para a caixa de entrada, para outra aba ou para o spam.

Na Promovaweb, eu uso o serviço de email da Cloudflare para mensagens transacionais e mantenho a newsletter na AWS. Cada fluxo precisa ser acompanhado pelo domínio, pela autenticação e pelos logs, sem tratar o botão “enviar” como confirmação de leitura.

Direto ao ponto

A investigação segue o percurso da mensagem. O log da aplicação confirma a chamada ao serviço e a resposta do servidor destinatário mostra aceitação ou rejeição. Se houve aceitação, os cabeçalhos, a reputação e o posicionamento na caixa postal indicam a próxima leitura.

No DNS, SPF declara as origens autorizadas e DKIM publica a chave usada para conferir a assinatura. DMARC relaciona essa autenticação ao domínio visível e informa como tratar falhas. BIMI pode exibir o logo em provedores compatíveis, mas não coloca a mensagem na caixa de entrada.

A aplicação precisa registrar o primeiro envio

Comece pelo evento que deveria gerar a mensagem. No fluxo de recuperação de senha, associe o identificador da solicitação ao template, ao destinatário e à resposta devolvida pelo serviço de email. Não grave a senha, o token completo nem conteúdo sensível no log.

Uma resposta aceita pelo serviço mostra que a aplicação atravessou a primeira etapa. Uma falha de autenticação na API ou no SMTP termina ali. Corrija credenciais e configuração sem procurar o email no spam, pois ele ainda não chegou ao servidor destinatário.

Quando existe nova tentativa, preserve o mesmo identificador funcional e registre cada chamada. Isso permite descobrir se o cliente recebeu duas mensagens depois que a primeira resposta demorou. Para recuperação de senha, o sistema também precisa definir qual token continua válido. Num backend como o Supabase, confira essa validade no serviço de autenticação, além do estado de envio.

O template também participa da investigação: confira se o remetente e os links correspondem ao que o cliente espera receber. Uma mensagem aceita pelo servidor ainda pode apresentar um endereço quebrado. O artigo sobre criação de templates com React Email acompanha a conferência do HTML, do botão e da saída plain text.

A entregabilidade continua depois da aceitação

O serviço de envio tenta entregar a mensagem ao servidor responsável pelo domínio do destinatário. A resposta pode indicar aceitação, rejeição temporária ou rejeição permanente. Leia o código e o texto devolvidos, pois “falhou” sozinho não diferencia endereço inexistente de política de autenticação.

No envio pelo Email Service da Cloudflare, delivery failed registra uma falha de entrega, enquanto rejected indica destinatário na lista de supressão. Esse segundo estado não significa que o servidor destinatário recusou a mensagem. A documentação dos logs distingue esses estados de delivered.

Delivered confirma a aceitação pelo servidor destinatário. Se o cliente não encontra a mensagem, procure nas outras abas e no spam, depois envie um teste equivalente para um endereço controlado. O serviço de envio não enxerga necessariamente a pasta escolhida pelo provedor.

Um bounce permanente exige retirar ou corrigir o endereço conforme a resposta recebida. Repetir mensagens para caixas inexistentes piora a qualidade do fluxo e aumenta o volume de falhas associado ao remetente.

O DNS mostra se o domínio autorizou o envio

SPF fica num registro TXT e autoriza servidores a usar o domínio do remetente de envelope, informado no comando MAIL FROM. Esse domínio pode diferir do remetente visível na mensagem, conforme a especificação SPF. Ao adicionar um serviço, confira a política desse domínio e mantenha um único registro SPF nele.

DKIM adiciona uma assinatura ao cabeçalho. O destinatário consulta a chave pública no DNS e confere se a assinatura corresponde à mensagem. Cada serviço costuma fornecer um seletor e os registros que devem ser publicados.

DMARC verifica o alinhamento entre o domínio visível no remetente e o domínio autenticado por SPF ou DKIM. A política pode começar em p=none para coleta de relatórios e avançar para quarentena ou rejeição depois que as origens legítimas estão identificadas.

Envie uma mensagem de teste para um endereço controlado por você e abra os cabeçalhos completos. Procure os resultados de SPF, DKIM e DMARC. Uma marca verde no painel do remetente não substitui o que o servidor destinatário registrou naquela mensagem.

Relatórios DMARC revelam origens esquecidas

Os relatórios agregados mostram quais servidores tentaram enviar pelo domínio e como passaram pelas verificações. Uma ferramenta antiga de suporte ou marketing pode continuar enviando depois que a configuração principal mudou.

Confronte cada origem com a lista de serviços autorizados: autentique as origens legítimas e investigue as não reconhecidas antes de ajustar a política do domínio.

Não avance imediatamente de observação para rejeição sem ler os relatórios. Uma origem legítima sem autenticação alinhada por SPF nem por DKIM pode ter mensagens rejeitadas quando a política endurece. Corrija os fluxos conhecidos e acompanhe o efeito.

Reclamações e bounces também afetam a reputação do domínio. Remova endereços inválidos e processe cancelamentos, pois a autenticação não compensa uma lista de envio mal cuidada.

BIMI identifica a marca em provedores compatíveis

BIMI publica uma referência ao logo para provedores que oferecem esse recurso. A configuração exige DMARC em quarentena ou rejeição, aplicado integralmente, e um SVG Tiny PS. Alguns destinos exigem certificado, como explica o guia de implementação do BIMI Group.

O logo não comprova entregabilidade. Ele pode aparecer apenas depois que autenticação, política e requisitos do provedor estão atendidos. Use BIMI como identificação visual, sem colocá-lo no lugar de SPF, DKIM ou DMARC.

Se a imagem não aparece, confira o registro, o arquivo e as exigências do destino. Não altere a política de email apenas para exibir o logo sem verificar o efeito sobre os envios legítimos.

A troca do serviço de envio

Na documentação consultada em 3 de outubro de 2026, o Email Sending da Cloudflare ainda aparece como beta. Ele recebe mensagens por binding de Workers, API REST ou SMTP autenticado e exige que o domínio use DNS da Cloudflare.

No vídeo, o painel do meu ambiente exibia um limite diário de 20 mil mensagens. Esse número pertence àquela configuração. A Cloudflare informa que limites variam com o histórico de envio e podem ser ajustados. Consulte a documentação atual de limites e o valor exibido no seu painel.

Ao trocar o serviço, confira as credenciais e os registros de autenticação fornecidos pelo novo provedor. A política SPF depende do domínio de envelope usado no envio. Confira também templates, callbacks e tratamento de bounce: manter o mesmo remetente visível não conserva automaticamente a reputação dos IPs de envio.

O artigo sobre serviços da Cloudflare sem prender a stack mostra como testar essa substituição por função. Para templates construídos com código, React Email na stack de Vibe Coding percorre a geração da mensagem.

Quando o log diz delivered e o cliente diz não recebi

Abra a execução da aplicação e confirme o destinatário. Localize a tentativa no serviço de email e leia a resposta do servidor. Depois examine os cabeçalhos de uma mensagem equivalente recebida num endereço de teste.

Se o servidor rejeitou, siga o código registrado. Se aceitou, peça ao cliente para procurar em spam e outras abas, sem afirmar que a mensagem chegou à caixa principal. Compare domínio, assunto e remetente com envios anteriores.

Confira os relatórios DMARC e o histórico de bounces. Observe se uma mudança de provedor, volume ou template coincide com o início das falhas. Use essa comparação para escolher a configuração que você vai alterar e conferir o efeito no próximo envio.

As ferramentas da Promovaweb apresentam as funções de email e automação usadas na stack. A Formação DevOps desenvolve DNS, publicação e observabilidade. Para configurar SPF, DKIM e DMARC no seu ambiente com orientação ao vivo, o Desenvolvimento Colaborativo da Dev Side Studio mantém você no editor e no terminal durante a execução.