Como uma equipe de produto deve implementar o DMARC na Cloudflare com segurança?

Separe o DNS da Cloudflare da configuração de remetentes

A Cloudflare pode operar o DNS autoritativo enquanto outro provedor submete e assina os e-mails da aplicação. Registre essas fronteiras antes de editar qualquer coisa. A zona publica a política DMARC em TXT; cada provedor de e-mail controla seu return path, o domínio de assinatura e o seletor DKIM, a verificação e, às vezes, os relatórios; a aplicação controla tenant, classe de mensagem, destinatário, template, endereço From visível e caminho de provedor. Um registro DNS válido não conserta um remetente não autorizado, uma assinatura DKIM ausente, um return path não alinhado nem um valor From de outro tenant. Faça o inventário dos sistemas de produção, staging, suporte, cobrança, identidade, monitoramento, CRM, marketing e e-mail humano por domínio From visível. Atribua a cada um um responsável e um contato para rollback, e classifique as fontes desconhecidas nos relatórios antes de aumentar a aplicação da política.

Consulte o nome de política que os receptores avaliam

Para e-mails de alerts@notify.example.test, comece pelo TXT em _dmarc.notify.example.test. Não publique a política por engano no host do site, no servidor de e-mail (MX), no seletor DKIM ou no nome do return path. A descoberta de DMARC atual pode selecionar uma política organizacional ou de sufixo público aplicável quando o domínio do autor não tem um registro válido; por isso, registre tanto o nome consultado quanto o domínio de política selecionado. Consulte as respostas autoritativas e recursivas existentes antes de abrir a Cloudflare. Vários registros de política no mesmo nome, sintaxe de tags malformada ou um CNAME conflitante podem tornar o resultado inutilizável. Capture o conteúdo antigo, o TTL, a saída do resolvedor, o responsável e o valor esperado após a mudança, para que o rollback seja exato e não reconstruído durante um incidente.

Crie um único registro TXT revisado na Cloudflare

Abra a conta e a zona corretas da Cloudflare, vá em DNS Records, escolha Add record e selecione TXT. Use _dmarc como nome relativo para uma política no apex ou o rótulo _dmarc exato para o subdomínio pretendido. Insira um único valor revisado, sem aspas inconsistentes; a Cloudflare documenta que adiciona aspas delimitadoras ao novo conteúdo TXT salvo sem elas. Escolha um TTL coerente com a implantação e a recuperação, adicione uma referência de mudança que preserve a privacidade, se for o caso, e salve somente depois de conferir zona, nome, valor antigo e valor novo. Políticas em TXT são dados DNS, não rotas web com proxy. Se um parceiro de hospedagem ou outro provedor autoritativo gerencia a zona, faça a mudança lá em vez de presumir que o painel da Cloudflare é autoritativo.

Monte o valor DMARC a partir de decisões explícitas

Um registro na fase de observação pode começar com v=DMARC1; p=none e uma URI de relatórios agregados aprovada, mas isso é um exemplo, não um valor universal. Mantenha a versão em primeiro lugar, defina deliberadamente a política solicitada e autorize cada destino de relatórios. Revise a política de subdomínio, o modo de alinhamento, a porcentagem e as tags de relatório somente quando houver um requisito documentado e uma interpretação atual do padrão. Não copie um exemplo de fornecedor que contenha a caixa postal rua de outra pessoa nem pule para p=reject só porque a sintaxe valida. Um registro válido expressa o tratamento solicitado ao receptor; ele não comprova que o SPF ou o DKIM autenticam, que algum identificador autenticado se alinha ao domínio From, que todos os caminhos de envio legítimos foram inventariados nem que alguma mensagem chegou a uma caixa de entrada.

Verifique o alinhamento de SPF e DKIM em mensagens reais

Envie exemplos controlados de cada caminho da aplicação para destinatários cujos cabeçalhos brutos você possa inspecionar. Registre From visível, SMTP MAIL FROM, IP de envio, domínio d= e seletor DKIM, Authentication-Results, identificador do provedor, classe de mensagem, ambiente e horário. O DMARC pode passar por meio de SPF autenticado e alinhado ou de uma assinatura DKIM verificada e alinhada. O SPF avalia uma identidade SMTP e pode mudar com o encaminhamento; o DKIM verifica uma assinatura sobre um conteúdo selecionado. Nenhum dos dois substitui a autorização na aplicação. Teste o alinhamento relaxed ou strict de forma deliberada, incluindo subdomínios e rotas de failover. Aceitação pela API do provedor, aceitação pelo servidor de destino, aprovação no DMARC, chegada à caixa de entrada e engajamento são observações diferentes. Mantenha esses estados separados para que uma chamada de API bem-sucedida ou um indicador verde de política nunca seja promovido a evidência de entrega mais forte.

Valide o DNS e os relatórios fora do painel

Depois de salvar, consulte os servidores de nomes autoritativos da Cloudflare e vários resolvedores recursivos independentes pelo TXT no nome _dmarc exato. Armazene as respostas brutas, o domínio de política selecionado, o TTL, o resolvedor, o timestamp e o resultado do parser. Confirme que existe exatamente um registro utilizável, com v=DMARC1 em primeiro lugar, valores obrigatórios válidos e URIs de relatório aprovadas. Repita após a janela de cache esperada. Envie mensagens controladas novamente e inspecione os cabeçalhos do receptor. A Cloudflare documenta o DMARC Management como uma forma de ver as fontes de envio e os resultados agregados de SPF, DKIM e DMARC, mas os relatórios são observações atrasadas fornecidas pelos receptores, não um censo completo em tempo real. Correlacione-os com as evidências do provedor. Pause se houver divergência entre resolvedores, tráfego de baixa frequência ausente, fontes legítimas desconhecidas, mensagens controladas não alinhadas ou mudanças inesperadas no volume de relatórios.

Trate o DMARC Management da Cloudflare como uma mudança de DNS

A Cloudflare diz que ativar o DMARC Management pode sugerir a criação de um registro quando não existe nenhum ou adicionar um endereço de relatórios agregados da Cloudflare a uma tag rua existente. Revise essa mutação proposta como infraestrutura de produção: exporte o valor anterior, confirme que os destinos existentes continuam intencionais, verifique o escopo do domínio e preserve o rollback. A documentação de ativação também descreve o escopo atual restrito ao domínio apex e uma ressalva sobre registros SPF externos. Não conclua que o recurso pode reescrever com segurança um caminho SPF hospedado em outro lugar. Uma fonte ou IP listado não prova qual aplicação, tenant ou pessoa o autorizou, e a ausência de uma linha não prova que não existe tráfego. Use a visualização para coletar evidências, preservando as evidências do DNS autoritativo, das mensagens brutas, dos logs do provedor e da auditoria da aplicação.

Aumente a aplicação da política com evidências em etapas

Observe por tempo suficiente para cobrir todos os remetentes legítimos, classes de mensagem, padrões por dia da semana, jobs em lote, rotas de failover e fluxos de baixa frequência. Classifique as fontes como próprias, fornecedor aprovado, encaminhadas, desconhecidas ou abusivas. Corrija o alinhamento do tráfego legítimo antes de solicitar um tratamento mais rígido. Um critério de go/no-go deve incluir DNS válido, aprovação das mensagens controladas, cobertura alinhada aceitável, nenhuma fonte legítima desconhecida, responsável por incidentes, suporte preparado e rollback testado. Aumente a política somente por meio de uma mudança delimitada e aprovada, e monitore falhas de autenticação e de negócio. Reverta ou pause em caso de rejeição de mensagens legítimas, perda de relatórios, fontes inesperadas, inconsistência entre resolvedores, migração de provedor ou surpresas na herança de subdomínios. Sempre que possível, altere SPF, DKIM e DMARC separadamente, para que a atribuição de regressões continue clara.

Evite as falhas comuns de DMARC na Cloudflare

Falhas frequentes incluem editar a zona errada, publicar no nome _dmarc errado, deixar dois registros de política, adicionar aspas quebradas, substituir uma lista rua aprovada, presumir que as políticas do apex e do subdomínio são idênticas e usar p=reject antes que remetentes pouco frequentes apareçam. Outro erro é tratar o estado salvo ou detectado no painel como prova no nível da mensagem. Use diffs exatos, destinatários controlados, consultas independentes, cabeçalhos brutos e logs de incidente com escopo por destinatário. Mantenha endereços de clientes, corpos de mensagens, chaves de API e dados de relatórios sem limite fora de tickets e analytics. Se as respostas autoritativas e em cache continuarem inconsistentes além do planejado, se um remetente esperado estiver ausente ou se uma mensagem real falhar no alinhamento, pare e diagnostique separadamente delegação, cache, sintaxe do registro, inventário de remetentes, SPF e DKIM.

Como o SendHQ se encaixa

O limite seguro é independente de provedor: a aplicação autoriza uma mensagem, o provedor de envio a autentica, a Cloudflare publica ou analisa o estado do DNS e os destinatários avaliam a mensagem. Baseie-se na documentação oficial atual da Cloudflare, no padrão DMARC atual, nas respostas de DNS observadas e em evidências controladas de mensagens recebidas.

Perguntas frequentes

Fontes

• Manage DNS records — Cloudflare (em inglês)
• Cloudflare DNS record types — Cloudflare (em inglês)
• Cloudflare DMARC Management overview — Cloudflare (em inglês)
• Enable Cloudflare DMARC Management — Cloudflare (em inglês)
• Review Cloudflare DMARC statistics — Cloudflare (em inglês)
• RFC 9989: DMARC — RFC Editor (em inglês)
• RFC 7208: SPF — RFC Editor (em inglês)
• RFC 6376: DKIM — RFC Editor (em inglês)