Como uma equipe de produto deve implementar o roteamento de e-mail da Cloudflare com segurança?

Defina a tarefa de entrada e o limite de responsabilidade

Comece registrando exatamente qual é a tarefa de entrada: quais domínios e partes locais devem aceitar e-mail, quem é responsável por cada destino, se uma mensagem deve ser encaminhada, processada por código ou descartada e por quanto tempo as evidências operacionais podem ser retidas. O Cloudflare Email Routing é uma camada de roteamento de entrada. Sozinho, ele não cria um ticket de suporte, não estabelece a identidade do remetente, não comprova que o e-mail encaminhado chegou a uma pessoa e não garante a chegada à caixa postal no destino. Mantenha esses estados posteriores da aplicação separados. Designe um responsável operacional para DNS, regras de roteamento, código do Worker, verificação de destinos, incidentes de segurança e rollback. Use aliases dedicados, como support@ ou invoices@, em vez de um catch-all durante o primeiro rollout. Uma rota estreita reduz a coleta acidental, torna os resultados dos testes interpretáveis e limita o impacto de um destino ou de um ramo do Worker configurado por engano.

Faça o onboarding do domínio sem tratar o DNS como uma etapa de instalação às cegas

A documentação atual do Email Service da Cloudflare diz que o domínio precisa usar o DNS da Cloudflare para o Email Routing. O fluxo de onboarding pode adicionar registros MX para o roteamento de entrada, além de registros TXT relacionados a SPF e DKIM descritos pelo produto. Revise os registros exatos propostos antes de aplicá-los. Primeiro, faça um inventário dos MX, SPF, DKIM e DMARC existentes, das caixas postais, dos serviços de encaminhamento, dos tokens de verificação e das delegações de subdomínio. Substituir registros MX muda o destino das novas sessões SMTP de entrada; portanto, combine uma janela de manutenção e guarde os valores anteriores como registro de rollback. Evite criar vários registros SPF TXT no mesmo nome de proprietário. Após a mudança, consulte resolvedores autoritativos e públicos e depois teste a entrega a partir de uma conta sem relação com o destino. Estimativas de propagação de DNS não provam que todos os remetentes já veem a mesma resposta, e um painel verde não comprova o encaminhamento de ponta a ponta.

Verifique os destinos antes de criar rotas ativas

A Cloudflare documenta os endereços de destino como recursos no nível da conta que precisam ser verificados antes de as regras de roteamento poderem usá-los. A etapa de verificação é um limite importante contra abuso: ela demonstra o controle da caixa postal naquele momento, mas não estabelece autorização de negócio contínua nem a composição correta da equipe. Registre no seu próprio sistema o responsável pela solicitação, a finalidade, a data de verificação e a data de revisão. Prefira um destino controlado pela equipe ao endereço pessoal de um funcionário. Remova rapidamente destinos de pessoas que saíram da empresa e verifique quais regras dependem de um endereço antes de excluí-lo, porque a Cloudflare documenta que excluir um destino desativa as rotas que o utilizam. Trate os e-mails de verificação como sensíveis para a segurança e nunca clique automaticamente neles nem os encaminhe para automações não confiáveis. Para mudanças em produção, exija a revisão de uma segunda pessoa no seu processo normal de infraestrutura, mesmo que o painel permita que um único operador salve a regra.

Crie regras explícitas e entenda a precedência

Uma regra de roteamento associa um padrão de e-mail a um destino verificado ou a um Worker. A Cloudflare documenta três ações: enviar para um e-mail, enviar para um Worker e descartar. Crie primeiro as rotas de parte local mais específicas, identifique o responsável nos registros de mudança e confirme que há apenas uma regra pretendida por padrão. A documentação avisa que, se várias regras usarem o mesmo padrão, apenas a regra listada primeiro processa o e-mail recebido. Não dependa da ordem visual como uma regra de negócio informal; elimine a ambiguidade. Mantenha as regras de descarte com justificativa bem restrita, porque o descarte é, intencionalmente, uma não entrega. Habilite o catch-all somente depois de listar suas consequências de privacidade, volume de spam, erros de digitação e armazenamento. Um catch-all pode coletar endereços que ninguém pretendia criar; por isso, ele deve ter um destino ou uma política de Worker dedicada, alertas e um caminho rápido de desativação, em vez de herdar silenciosamente uma caixa postal pessoal.

Use subendereçamento de forma deliberada

A Cloudflare documenta o plus addressing opcional, compatível com a RFC 5233. Quando habilitado, o e-mail para um endereço como user+detail@example.com pode corresponder à regra base user@example.com, preservando o detalhe no destinatário da mensagem exposto ao Worker e aos logs. Isso pode servir para tags de roteamento, identificadores de teste ou aliases por fluxo, mas o detalhe é um texto controlado pelo remetente. Não o trate como identidade autenticada de tenant, autorização ou segredo. Normalize e limite esse valor antes de usá-lo como chave de banco de dados, dimensão de métrica ou nome de fila. A Cloudflare também documenta que uma regra explícita para o subendereço completo tem precedência sobre a regra base. Teste tanto o caso explícito quanto o de fallback, para que uma regra específica criada depois não altere silenciosamente um fluxo existente. Evite colocar dados pessoais ou confidenciais em plus tags, porque eles podem aparecer em cabeçalhos, logs, mensagens encaminhadas, exportações de suporte e análises.

Escolha um Worker apenas para necessidades reais de processamento

Use o encaminhamento direto quando o requisito for simplesmente um endereço para uma caixa postal verificada. Encaminhe para um Worker quando precisar de ramificação controlada, inspeção de mensagens, armazenamento, rejeição, respostas ou vários encaminhamentos. O handler de e-mail da Cloudflare expõe o remetente e o destinatário do envelope, os cabeçalhos, um stream MIME bruto, seu tamanho e métodos para encaminhar, responder ou rejeitar. Mantenha o handler pequeno: valide primeiro a política de destinatários, aplique limites à mensagem e ao parsing, faça chamadas externas por filas com tempo limitado sempre que possível e defina o resultado para cada erro. Cabeçalhos, assuntos, nomes de exibição, anexos, links e delimitadores MIME são controlados pelo atacante. Por padrão, não registre em log corpos brutos nem endereços completos. Se o conteúdo precisar ser armazenado, criptografe-o, restrinja o acesso por tenant e por tarefa, defina a exclusão e verifique os anexos fora do caminho síncrono de roteamento. Uma exceção de parsing não pode cair em um encaminhamento ou uma resposta não intencional.

Implemente um único caminho de decisão explícito

Um handler seguro deve calcular uma ação aprovada antes de executar efeitos colaterais. Por exemplo, mapeie o destinatário exato do envelope para um fluxo configurado, rejeite destinatários desconhecidos, coloque em fila um registro de metadados limitado e só então encaminhe para um destino verificado selecionado na configuração. Nunca aceite um destino vindo de um cabeçalho, assunto, plus tag ou corpo da mensagem. Ao encaminhar para vários destinos, a documentação de limites da Cloudflare diz que um Worker deve chamar forward uma vez por destino verificado; decida se sucesso parcial é aceitável e registre cada tentativa separadamente. Use um identificador interno de correlação estável, e não o conteúdo do destinatário, nos logs. Se o handler puder responder, siga as restrições atuais de resposta da Cloudflare e adicione proteção contra loops. Uma resposta não é uma confirmação de uma equipe humana. Se for necessário um registro durável na aplicação, armazene o ticket ou o evento antes de enviar uma resposta automática e reconcilie falhas ambíguas, em vez de prometer que o trabalho foi criado.

Trate encaminhamentos e respostas como resultados com escopo de evidência

Uma chamada de método bem-sucedida no Worker é evidência sobre a operação da plataforma, não sobre o resultado final para o usuário. O SMTP define a transferência entre sistemas, enquanto filtragem posterior, encaminhamento, quarentena, regras de caixa postal e leitura humana ficam fora desse salto. Modele separadamente estados como recebido pela Cloudflare, Worker invocado, ação tentada, aceito pelo servidor de destino, atrasado ou com falha e registro criado na aplicação. Não rotule todos eles como entregue. Mantenha logs estruturados e com privacidade minimizada, com a identidade da regra, a revisão do Worker, a ação, o timestamp, o identificador de correlação e um resultado resumido; armazene endereços completos ou conteúdo somente quando uma necessidade operacional documentada justificar. Crie alertas para falhas de invocação, rejeições por tamanho, volume anormal no catch-all, padrões repetidos de remetentes, falhas de destino e mudanças bruscas de tráfego. Envie amostras contínuas de mensagens de teste controladas, mas nunca use conteúdo real de clientes como fixture de observabilidade.

Respeite os limites e os modos de falha atuais da plataforma

Atualmente, a Cloudflare documenta limites do Email Routing que incluem 200 regras de roteamento por domínio, 200 endereços de destino por conta, um limite de 25 MiB para o tamanho de mensagens de entrada e os limites padrão de CPU e memória dos Workers para mensagens roteadas por Worker. Trate esses valores como documentação atual do provedor, não como constantes permanentes. Leia a página de limites em vigor durante o planejamento e crie alertas bem antes de se aproximar de um teto. Mensagens MIME grandes podem esgotar a memória ou a CPU mesmo abaixo do limite de tamanho bruto da plataforma, se forem decodificadas sem cuidado. Faça streaming ou rejeite conteúdo desnecessário, limite a quantidade de anexos e coloque o parsing caro atrás de trabalho assíncrono limitado. Segundo a documentação de roteamento da Cloudflare, renomear um Worker pode quebrar seu vínculo de roteamento; por isso, inclua a inspeção das rotas na verificação do deploy. Invocações com falha devem ficar visíveis nos logs dos Workers, mas os logs sozinhos não permitem reprocessamento. Decida se o remetente deve tentar novamente via SMTP, se um operador pode reprocessar com segurança um job da aplicação e como evitar registros duplicados nas etapas posteriores.

Teste o rollout e o rollback como uma única mudança

Crie primeiro uma rota de staging ou de baixo risco. Envie mensagens controladas a partir de uma conta diferente do destino verificado, cobrindo texto simples, conteúdo multipart, anexos esperados, plus addressing, partes locais desconhecidas e entradas deliberadamente malformadas dentro de limites seguros. Verifique as respostas DNS, a configuração do painel, a revisão do Worker, o resultado do encaminhamento, o registro nas etapas posteriores e o comportamento de privacidade. Depois, teste os caminhos negativos: destino não verificado, regra desativada, exceção no Worker, mensagem grande demais, entrega repetida e uma regra que, de outra forma, cairia no catch-all. Registre a evidência esperada para cada etapa. Antes de ampliar o tráfego, ensaie desativar a regra, restaurar os registros MX anteriores se necessário, desvincular o Worker e comunicar e-mails atrasados ou rejeitados. Faça rollback em caso de perda de roteamento sem explicação, exposição entre tenants, vazamento de conteúdo, respostas inesperadas, armazenamento sem limite ou falha persistente do Worker. Preserve snapshots de configuração e resultados de testes sem reter o conteúdo das mensagens por mais tempo que o necessário.

Como o SendHQ se encaixa

O SendHQ oferece suporte a e-mail de entrada. Este guia aborda o Cloudflare Email Routing; siga a documentação de cada serviço para sua própria configuração e seus limites.

Perguntas frequentes

Fontes

• Route emails — Cloudflare (em inglês)
• Email routing rules and addresses — Cloudflare (em inglês)
• Workers API for routed email — Cloudflare (em inglês)
• Cloudflare Email Service limits — Cloudflare (em inglês)
• RFC 5321: Simple Mail Transfer Protocol — RFC Editor (em inglês)
• RFC 5233: Sieve Email Filtering: Subaddress Extension — RFC Editor (em inglês)