Muita gente assume que ter email no próprio domínio exige pagar pelo Google Workspace ou Microsoft 365. Não exige — pelo menos se o que você precisa é receber email em contato@seudominio.com e ter isso entregue num inbox que você já usa. O Cloudflare Email Routing faz exatamente isso, de graça, em menos de dez minutos de configuração. O problema aparece quando alguém trata esse escopo restrito como ponto de partida para construir algo maior sem entender o que o serviço deliberadamente não faz.
O que o Email Routing faz, sem adornos
O serviço recebe email endereçado ao seu domínio e o encaminha: para um ou mais endereços de email verificados, ou para um Email Worker que você escreve. Só isso. Não há webmail, não há caixa de entrada própria, não há protocolo IMAP ou SMTP de saída. O email chega nos servidores do Cloudflare, é roteado conforme as regras que você configurou, e segue em frente.
As regras funcionam de dois modos. Você define endereços específicos — hello@seudominio.com vai para seu@gmail.com, suporte@seudominio.com vai para outro endereço — ou configura um catch-all com *@seudominio.com que captura tudo o que não bate em nenhuma regra específica. Os endereços de destino precisam ser verificados: o Cloudflare envia um link de confirmação para cada endereço antes de aceitar ele como destino válido. Simples, sem surpresas.
O limite de tamanho por mensagem é 25MB — alinhado com o que a maioria dos provedores aceita. Não há limite documentado de volume de mensagens para o plano gratuito, embora isso possa mudar conforme o serviço evolui.
O requisito que pega as pessoas de surpresa
Para usar o Email Routing, seu domínio precisa usar os nameservers do Cloudflare. Não basta apontar registros MX para os servidores deles enquanto mantém outro provedor de DNS. Você precisa delegar o domínio inteiro para o Cloudflare. Quando você ativa o Email Routing no painel, o Cloudflare adiciona automaticamente os registros MX apontando para os servidores de recebimento deles, e gerencia isso como parte da zona DNS.
Isso é relevante porque muitas equipes chegam ao Cloudflare pela CDN ou pelo WAF, com o domínio já delegado. Para elas, o Email Routing é trivial de ativar. Quem só usa o Cloudflare como proxy reverso para algumas subdomains enquanto mantém o DNS em outro lugar vai precisar migrar a zona inteira — uma decisão maior do que parece quando há registros críticos espalhados por anos de configuração acumulada.
Quem não quer ou não pode mover os nameservers tem alternativas. O Improvmx, por exemplo, funciona com qualquer provedor de DNS: você adiciona um registro TXT para verificação e dois registros MX, e pronto. O custo é flexibilidade programática — o Improvmx não tem nada equivalente aos Email Workers.
O que você não vai conseguir fazer com isso
Responder um email a partir de contato@seudominio.com não é possível via Email Routing. Quando você recebe uma mensagem encaminhada e clica em "responder" no seu Gmail, o remetente aparece como seu endereço Gmail — não como o alias do seu domínio. Para enviar email a partir do próprio domínio, você precisa de um serviço separado: Resend, SendGrid, Mailgun, Amazon SES, Postmark. O Email Routing não tem nenhuma relação com o fluxo de saída.
Isso não é uma limitação técnica acidental. O Cloudflare separou deliberadamente os problemas: recebimento de email é uma coisa, envio é outra, e os dois têm requisitos de infraestrutura muito diferentes. Faz sentido arquiteturalmente — mas quem não lê a documentação antes de configurar vai perder tempo tentando descobrir por que não consegue enviar.
Outro ponto que surpreende: o serviço de message.reply() disponível nos Email Workers — para respostas programáticas — não envia pelo seu domínio. A resposta sai de um endereço noreply@cloudflare.com. Se você quer respostas automáticas que pareçam vir de suporte@seudominio.com, precisa integrar com um provider de SMTP outbound.
A configuração que funciona para a maioria dos casos
O setup mais comum para times pequenos ou projetos pessoais: dois ou três endereços específicos encaminhados para o inbox pessoal do responsável, mais um catch-all apontando para o mesmo lugar ou para um endereço dedicado a triagem. Leva menos de dez minutos, funciona de forma confiável, e elimina a necessidade de pagar pelo Google Workspace só para ter um endereço com o domínio da empresa.
Para uso mais sofisticado — criar tickets automaticamente a partir de emails de suporte, parsear anexos, filtrar spam antes de encaminhar — a integração com Workers é o caminho. O email chega no Worker como um objeto com message.from, message.to, message.headers, e message.raw (um ReadableStream com a mensagem RFC 2822 completa). Você decide o que fazer: encaminhar, rejeitar com motivo, ou processar e integrar com outros serviços. Esse fluxo merece um post separado.
O que um líder técnico precisa decidir antes de ativar
A questão não é se o Email Routing é bom — é se ele resolve o problema que você tem. Se o domínio já está no Cloudflare, se você só precisa receber email, e se o time entende que envio vai exigir um serviço separado, a resposta é sim sem reservas. Grátis, confiável, programável via Workers quando necessário.
Se o domínio não está no Cloudflare e você não quer mover os nameservers, o Improvmx resolve o forwarding simples sem essa exigência. Se você precisa de algo mais completo — webmail, IMAP, envio pelo próprio domínio — o Google Workspace a R$30/mês por usuário continua sendo a opção mais rápida de colocar em produção sem dívida de configuração.
O risco concreto de não entender o escopo: alguém configura o Email Routing, assume que está "com o email do domínio funcionando", e só descobre que não consegue enviar quando tenta mandar uma proposta para um cliente a partir do endereço da empresa.
Leia também
- As limitações do Cloudflare Email Routing que o tutorial não menciona
- Email Routing vs Improvmx vs Forward Email: comparação honesta
- Cloudflare DNS: infraestrutura de rede que vai muito além de resolver nomes
- Cloudflare Load Balancing e Geo Steering: quando o DNS vira camada de tráfego inteligente
- DNSSEC com Cloudflare: o que protege, o que não protege e como ativar sem problemas
- DNS proxied vs DNS only: o que muda e quando cada modo faz sentido