GitHub

Nenhum tutorial sobre Cloudflare Email Routing começa explicando o que o serviço não faz. Eles mostram a configuração em cinco passos, confirmam que o email chegou no destino, e encerram. O que fica de fora são os casos em que o forwarding começa a rejeitar mensagens legítimas, o catch-all vira uma torneira de spam, ou o Worker derruba email de cliente porque uma linha de código lançou uma exceção. Esses casos existem, são previsíveis, e vale saber deles antes de colocar o serviço em produção para algo crítico.

Envio pelo domínio não existe aqui

O ponto mais importante, e o mais frequentemente mal compreendido: o Email Routing recebe email. Só. Não há como enviar uma mensagem a partir de voce@seudominio.com usando esse serviço. Quando você configura o forwarding e alguém te manda um email para contato@seudominio.com, você recebe no Gmail. Quando você responde nesse Gmail, o remetente que o destinatário vê é o seu endereço Gmail — não o alias do seu domínio.

Para enviar email pelo próprio domínio você precisa de um serviço separado: Resend, SendGrid, Mailgun, Amazon SES, Postmark, Brevo. Cada um desses vai exigir registros DNS próprios — SPF e DKIM específicos para o provedor escolhido. O Cloudflare configura automaticamente registros SPF para o recebimento, mas não tem nada a ver com os registros que um provider de envio vai precisar. Quem mistura os dois fluxos na mesma configuração DNS acaba com erros de autenticação em ambos os sentidos.

O problema de entregabilidade com forwarding e DMARC

Quando o Cloudflare encaminha um email, ele retransmite a mensagem a partir dos próprios servidores — não dos servidores originais do remetente. Isso cria uma fricção com o DMARC que afeta casos específicos mas importantes.

Se o remetente original tem uma política DMARC com p=reject — comum em bancos, grandes empresas, provedores de email como Gmail e Outlook — e o email é encaminhado pelo Cloudflare, o servidor de destino final recebe uma mensagem cujo header From: mostra o domínio do remetente original, mas cujo IP de envio pertence ao Cloudflare. O alinhamento DMARC falha porque o SPF verifica o IP de envio (Cloudflare) contra o domínio no From: (o banco, a empresa), e eles não se alinham.

O Cloudflare usa ARC (Authenticated Received Chain) ao encaminhar, que preserva as informações de autenticação do hop original. Isso melhora a situação para provedores que entendem e respeitam ARC — Microsoft, Google incluídos. Mas não é universal. Alguns servidores de email corporativo com políticas mais rígidas ainda rejeitam o email encaminhado mesmo com ARC. O resultado prático: você pode perder emails legítimos enviados por domínios com p=reject estrito, e o Cloudflare não tem controle sobre a política de recebimento do servidor de destino.

Não há solução completa para isso dentro do Email Routing. Quem precisa de garantia de entrega para todos os remetentes possíveis precisa de uma solução com caixa de entrada própria — Google Workspace, Fastmail, Microsoft 365.

Catch-all e o spam que vem junto

Habilitar o catch-all *@seudominio.com é útil: qualquer endereço que você der em formulários, newsletters e eventos cai no mesmo inbox sem precisar criar aliases antecipadamente. O problema é que spammers varrem domínios tentando entregar email para endereços aleatórios. Com catch-all ativo, cada tentativa chega no seu inbox.

Um domínio com alguma exposição na web pode receber centenas de emails por dia para endereços que nunca existiram — info@, admin@, noreply@, sales@, variações aleatórias. Todos chegam. O Gmail tem filtros de spam, mas o volume cria ruído.

A mitigação dentro do próprio Email Routing é rotear o catch-all para um Email Worker em vez de direto para um endereço de destino. O Worker pode checar se o endereço de destino é um dos aliases legítimos que você definiu, rejeitar tudo o que não bater, e encaminhar só o restante. Você mantém a flexibilidade do catch-all sem aceitar todo o lixo.

O Worker que derruba email em produção

Email Workers têm um comportamento que pega os desenvolvedores desprevenidos: se o Worker lança uma exceção não capturada, a mensagem é rejeitada com um erro 5xx. Não há retry, não há fila, não há dead-letter. O email some.

Imagine um Worker que faz POST para uma API externa para criar um ticket de suporte. A API externa está fora do ar. O Worker lança um erro de network. O email do cliente que estava solicitando suporte é rejeitado — e você nunca fica sabendo, a não ser que o cliente tente de novo e reclame.

O padrão correto é envolver toda a lógica de processamento num try/catch e, no catch, chamar message.forward() para um endereço de triagem manual. O email não é perdido, e você pode processar o que falhou depois que o serviço externo voltar. Sem esse fallback, qualquer falha transitória em qualquer dependência do Worker se torna perda de email.

O que muda quando você passa dos casos básicos

Forwarding simples de alguns aliases para endereços Gmail ou Fastmail funciona de forma confiável e sem surpresas. Os problemas aparecem quando você adiciona dependências: Workers com chamadas externas que podem falhar, catch-all sem filtragem, cenários com remetentes que têm DMARC restrito. Nesses casos o serviço ainda é útil, mas exige que você entenda as superfícies de falha e construa as mitigações correspondentes.

O Cloudflare não documenta de forma proeminente esses casos porque a maioria dos usuários não vai encontrá-los. Mas para times que dependem do email de forma mais séria — suporte a clientes, comunicação operacional, integração com parceiros que usam políticas DMARC rígidas — vale fazer testes antes de migrar, especialmente verificando o comportamento com remetentes de grandes provedores corporativos.

As limitações do Cloudflare Email Routing que o tutorial não menciona

Envio pelo domínio não existe aqui

O problema de entregabilidade com forwarding e DMARC

Catch-all e o spam que vem junto

O Worker que derruba email em produção

O que muda quando você passa dos casos básicos

Leia também