GitHub

Autenticação de email tem três camadas — SPF, DKIM e DMARC — e um erro frequente de quem usa o Cloudflare Email Routing é assumir que ativar o serviço resolve as três de uma vez. O Cloudflare configura o SPF para recebimento automaticamente, trata o DKIM via ARC nos emails encaminhados, e não configura DMARC para você. Se você usa um provider de envio separado, o SPF e o DKIM desse provider precisam ser adicionados manualmente. Confundir esses papéis leva a email rejeitado — às vezes o seu próprio.

O que o SPF faz e o que o Cloudflare adiciona

SPF (Sender Policy Framework) é um registro TXT na sua zona DNS que lista os servidores autorizados a enviar email pelo seu domínio. Quando um servidor recebedor aceita um email que diz ser do seudominio.com, ele consulta o SPF do seudominio.com para verificar se o IP que está enviando está na lista.

Quando você ativa o Email Routing, o Cloudflare adiciona automaticamente um include:_spf.mx.cloudflare.net ao SPF do seu domínio. Isso autoriza os servidores do Cloudflare a receber email pelo seu domínio — o que faz sentido, porque eles são os servidores que vão aceitar as mensagens entrantes antes de fazer o forwarding.

O ponto que exige atenção: se você também usa um provider de envio outbound — Resend, SendGrid, Amazon SES, Mailgun — esse provider tem servidores próprios que precisam aparecer no seu SPF. O registro SPF final precisa incluir tanto o Cloudflare quanto o provider de envio. Um exemplo com Resend:

v=spf1 include:_spf.mx.cloudflare.net include:amazonses.com ~all

O SPF tem um limite de 10 lookups DNS por avaliação. Cada include: conta como um lookup e pode desencadear mais lookups recursivos. Com muitos providers somados, é possível estourar esse limite — o que faz o SPF falhar para todos os remetentes, não só para alguns. Ferramentas como MXToolbox e dmarcian têm validadores que contam os lookups e alertam antes que isso vire problema.

DKIM no recebimento e no envio

DKIM (DomainKeys Identified Mail) funciona via criptografia assimétrica: o servidor de envio assina o email com uma chave privada, e o servidor receptor verifica a assinatura contra a chave pública publicada como registro TXT no DNS do domínio remetente.

Para emails recebidos e encaminhados pelo Email Routing, o Cloudflare usa ARC (Authenticated Received Chain). ARC é um conjunto de headers que registra a cadeia de autenticação do email à medida que ele passa por intermediários — no caso, o servidor do Cloudflare. Quando o Cloudflare encaminha um email, ele adiciona headers ARC que dizem ao servidor receptor final: "recebi este email, a assinatura DKIM original era válida no momento que chegou aqui, e estou ressignando para preservar essa informação". O Cloudflare re-assina com sua própria chave DKIM ao encaminhar.

Para emails enviados pelo seu provider outbound, o DKIM funciona de forma diferente. O Resend, o SES, ou qualquer outro provider de envio vai pedir que você adicione um ou mais registros TXT na sua zona DNS com a chave pública DKIM deles. Você adiciona esses registros no painel do Cloudflare, e o provider usa a chave privada correspondente para assinar os emails que saem pelo seu domínio. O Cloudflare não gera nem gerencia essa chave — você só hospeda o registro TXT que o provider criou.

DMARC: o que configurar e em que ordem

DMARC (Domain-based Message Authentication, Reporting and Conformance) fica num registro TXT em _dmarc.seudominio.com e define o que os servidores receptores devem fazer quando um email falha SPF e DKIM simultaneamente. Também define onde enviar relatórios de autenticação.

O Cloudflare não configura DMARC para você. Você cria o registro manualmente. Um registro inicial razoável:

v=DMARC1; p=none; rua=mailto:dmarc@seudominio.com; ruf=mailto:dmarc@seudominio.com; pct=100

p=none significa "monitorar, não rejeitar". Os relatórios chegam nos endereços definidos em rua (relatórios agregados diários) e ruf (relatórios forenses por falha). Esses relatórios em formato XML mostram quais IPs estão enviando email pelo seu domínio e qual é o resultado SPF/DKIM de cada um.

A sequência correta é essa: ativar p=none primeiro, aguardar pelo menos uma semana de relatórios, verificar que todos os remetentes legítimos — o provider de envio, os servidores de formulários, as ferramentas de marketing — aparecem como alinhados no SPF ou DKIM. Só depois de confirmar esse alinhamento você move para p=quarantine (emails suspeitos vão para spam) e eventualmente p=reject (emails suspeitos são recusados na recepção).

Ativar p=reject antes de adicionar os registros SPF e DKIM do provider de envio é o erro mais comum. O resultado: seus próprios emails começam a ser rejeitados pelos servidores de destino porque saem pelo Resend ou SES mas o SPF ainda não inclui esses servidores, ou o registro DKIM ainda não foi adicionado. O DMARC falha, e com p=reject o email é recusado — silenciosamente do ponto de vista do remetente.

O que verificar antes de mudar a política DMARC

Antes de mover de p=none para qualquer política mais restritiva, vale checar três coisas nos relatórios agregados: se o Cloudflare aparece como alinhado no SPF para os emails entrantes que você encaminha para contas próprias, se o provider de envio aparece como alinhado no DKIM para os emails que saem, e se não há IPs inesperados enviando email pelo seu domínio — o que indicaria uma configuração de outro serviço que você não mapeou ou um uso indevido.

Ferramentas como dmarcian, Postmark (que tem um analisador de DMARC gratuito), e MXToolbox facilitam a leitura dos relatórios XML. Vale o tempo investido. Um domínio com DMARC configurado corretamente tem menos chance de ter emails forjados aceitos pelos destinatários — e menos chance de ter email legítimo rejeitado por falha de configuração.

SPF, DKIM e DMARC com Email Routing: o que o Cloudflare configura e o que você ainda precisa fazer

O que o SPF faz e o que o Cloudflare adiciona

DKIM no recebimento e no envio

DMARC: o que configurar e em que ordem

O que verificar antes de mudar a política DMARC

Leia também