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.

O template participa da investigação. Confira remetente, assunto, links e domínio usado nas URLs. Uma mensagem tecnicamente aceita ainda pode apresentar um endereço quebrado ou um remetente diferente do esperado pelo cliente.

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 Email Service da Cloudflare, estados como delivered, delivery failed e rejected descrevem partes desse percurso. A documentação dos logs explica o alcance de cada estado.

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 declara quais origens podem enviar pelo domínio. Quando você adiciona outro serviço, precisa atualizar a política sem criar múltiplos registros SPF separados para o mesmo domínio.

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.

Compare a origem com os serviços autorizados pela empresa. Se ela é legítima, configure a autenticação correta. Se não é reconhecida, investigue o uso do domínio e mantenha a política compatível com a proteção pretendida.

Não avance imediatamente de observação para rejeição sem ler os relatórios. Uma origem legítima fora do SPF ou sem DKIM alinhado pode perder mensagens quando a política endurece. Corrija os fluxos conhecidos e acompanhe o efeito.

Reclamações e bounces completam essa leitura. Remova endereços inválidos e respeite cancelamentos. Um domínio autenticado continua acumulando reputação a partir do comportamento real de envio.

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 e um SVG no formato aceito. Alguns destinos exigem certificado e outras condições.

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.

O Email Service muda o provedor, não a identidade

O Email Sending da Cloudflare estava em beta na documentação consultada para esta publicação. Ele recebe mensagens por binding de Workers, API REST ou SMTP autenticado e exige que o domínio use DNS da Cloudflare.

No ambiente mostrado por mim, o painel 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.

Trocar o serviço exige novas credenciais, outra chave DKIM e atualização do SPF. Templates, callbacks e tratamento de bounce também precisam ser conferidos. O domínio continua sendo a referência visível, enquanto IP e infraestrutura de envio mudam.

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. Essa sequência produz uma hipótese que pode ser testada 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.

Entregabilidade não termina no envio nem num único selo de autenticação. A investigação atravessa aplicação, serviço, servidor destinatário e caixa postal. Quando cada etapa deixa um registro, você descobre onde a mensagem parou e corrige o componente correspondente.