Como Configurar SPF, DKIM e DMARC no Cloudflare

Se você está tentando aprender como configurar SPF, DKIM e DMARC no Cloudflare, comece com um fato simples: o Cloudflare armazena os registros DNS, mas seu provedor de e-mail fornece os valores. Isso parece pequeno. Não é pequeno.

O Cloudflare é o lugar onde os registros residem, e isso significa que você editará entradas TXT ou CNAME em seu painel DNS. A string de inclusão SPF real, o seletor DKIM, a chave pública e a política DMARC vêm do serviço que envia seu e-mail, seja ele Google Workspace, Microsoft 365, SendGrid, Mailgun ou outra plataforma. Sem esses valores, você está apenas adivinhando.

1. Confirme o que o Cloudflare pode e não pode fazer pela autenticação de e-mail

O Cloudflare não inventa valores SPF, DKIM ou DMARC. Ele apenas os publica. Se seu provedor disser para adicionar um registro TXT para SPF, o Cloudflare pode hospedá-lo. Se o provedor lhe der um seletor DKIM e um alvo CNAME, o Cloudflare pode hospedar isso também. Mas ele não pode decidir quais servidores podem enviar e-mails para você.

Isso é importante porque as pessoas costumam abrir o Cloudflare primeiro e procurar um botão mágico. Não há nenhum. Você precisa do conteúdo exato do registro do seu remetente antes de tocar no DNS, ou corre o risco de publicar um registro que passa na verificação do painel e falha em uma caixa de entrada real.

2. Coleta os valores DNS da sua plataforma de envio de e-mail

Antes de editar qualquer coisa, colete três coisas da documentação do provedor. Primeiro, reúna os mecanismos de inclusão SPF e quaisquer endereços IP que o serviço deseja em seu registro SPF. Em segundo lugar, reúna os nomes dos seletores DKIM e os dados da chave pública, ou os alvos CNAME se o provedor usar DKIM baseado em CNAME. Por último, reúna a string da política DMARC, incluindo a política com a qual você planeja começar e quaisquer tags de relatório.

Anote os valores em um só lugar. Use os nomes exatos dos seletores. Se seu provedor lhe der dois seletores, não os renomeie porque parecem bagunçados. Se a documentação disser que o registro deve ser `_spf.example.net`, mantenha assim. Pequenos erros de formatação causam longas tardes.

Há um hábito útil aqui: capture o nome do remetente, o nome do host, o tipo de registro e a string de destino em uma tabela antes de fazer login no Cloudflare. Isso torna a fase de edição mais rápida e também evita o erro comum de colar o valor correto no campo de nome errado.

3. Adicione um registro SPF no DNS do Cloudflare

No Cloudflare, abra o DNS e crie ou edite o registro TXT na raiz do domínio se seu provedor enviar e-mails do domínio raiz. Alguns serviços usam um subdomínio em vez disso, como `mail.example.com`, então use o nome do host que seu provedor especifica, não o que você assume. Um nome de host. Um registro.

Um registro SPF geralmente deve existir apenas uma vez para um nome de host. Esse é o ponto que as pessoas perdem. Se você já tem um registro SPF TXT, não crie um segundo registro SPF TXT ao lado dele. Mescle os remetentes autorizados em uma única string para que o servidor receptor veja uma política, não duas respostas concorrentes.

Um valor SPF típico inclui mecanismos como `include:` ou `ip4:`. Se seu serviço adicionar um segundo remetente mais tarde, atualize o registro existente em vez de adicionar outro. Um registro SPF duplicado pode causar um permerror, o que significa que os sistemas receptores podem tratar a verificação como falhada, mesmo que as partes individuais pareçam corretas.

Use o nome do registro que seu provedor lhe dá. Para o domínio raiz, o Cloudflare geralmente mostra `@` como o campo de nome. Para um subdomínio, insira esse rótulo exato. Não adicione aspas ao redor do valor, a menos que seu provedor lhe diga explicitamente para fazê-lo. O Cloudflare armazena o texto como conteúdo DNS simples.

4. Publique registros DKIM TXT ou CNAME no Cloudflare

DKIM é onde o seletor importa. O provedor pode lhe dar um registro TXT como `selector1._domainkey` com uma longa chave pública, ou pode lhe dar um registro CNAME que aponta para outro nome de host. O Cloudflare suporta ambos, mas o tipo deve corresponder ao que o provedor diz. Um valor TXT em um campo CNAME não ajudará você.

Muitos serviços usam dois seletores. Isso é normal. O Google Workspace frequentemente usa duas chaves durante a rotação, e outros provedores fazem algo semelhante para que uma chave possa ser substituída sem interromper a entrega. Se o remetente lhe der `s1` e `s2`, publique ambos os registros. Se um segundo remetente usar uma família de seletores diferente, mantenha esses registros separados também. Os nomes podem parecer repetitivos; os registros não são redundantes.

Digite o nome do host DKIM exatamente como fornecido. Se o provedor lhe disser para criar `selector1._domainkey.example.com`, use esse rótulo completo no Cloudflare. Se o provedor der um alvo CNAME, cole o destino exatamente como escrito. O Cloudflare não precisa de uma tradução. Ele precisa de precisão.

Para equipes seguindo configuração DKIM SPF DMARC para transacionais, a mesma regra se aplica mesmo quando o volume de e-mails é pequeno: o seletor no DNS deve corresponder ao seletor no cabeçalho da mensagem. Se eles diferirem, o DKIM falha. Sem drama, apenas falha.

5. Crie um registro DMARC em _dmarc

DMARC pertence a `_dmarc.seudominio.com`. No Cloudflare, crie um registro TXT com esse nome exato. O valor começa com `v=DMARC1`, depois adiciona sua política e tags opcionais. Uma política inicial comum é `p=none`, porque permite que você colete relatórios antes de bloquear qualquer coisa. Esse é o ponto de partida menos agressivo.

Se sua organização estiver pronta para receber relatórios, adicione a tag `rua` com o endereço de relatório agregado e, se necessário, a tag `ruf` para relatórios forenses. Use um endereço que alguém realmente monitore. Uma caixa de correio inativa não é uma estratégia. É uma armadilha.

Uma regra prática ajuda aqui: comece com uma política DMARC que corresponda à sua tolerância atual para falsos positivos, depois a aperte mais tarde, após saber que os remetentes legítimos estão alinhados. Se você se mover muito rápido, pode bloquear faturas, alertas ou redefinições de senha. Isso é notado imediatamente.

O Cloudflare armazenará o registro TXT DMARC como qualquer outra entrada de texto, mas os detalhes importam. O nome do registro deve ser `_dmarc`, não `dmarc`, não `_dmarc1`, e não o domínio raiz. A string da política deve seguir a sintaxe que seu provedor espera. Se sua plataforma de e-mail sugerir tags como `sp`, `adkim` ou `aspf`, adicione-as apenas quando entender o efeito.

6. Verifique as configurações de DNS específicas do Cloudflare que podem bloquear a validação

O Cloudflare tem uma configuração que causa mais confusão do que deveria: proxy. Registros de autenticação de e-mail não devem ser proxyados. SPF, DKIM e DMARC vivem no DNS, não atrás da nuvem laranja. Se você acidentalmente proxyar um nome de host relacionado a e-mail, estará misturando regras de tráfego da web com registros DNS de e-mail.

Nomes de registros são outro ponto comum de falha. Um seletor DKIM que deveria ser `selector1._domainkey` pode ser inserido como `selector1._domainkey.` com um ponto solto, ou como `selector1 domainkey` com um espaço copiado de uma página de provedor. O Cloudflare aceita muitas entradas de DNS, mas os sistemas receptores são menos tolerantes do que a interface.

Registros antigos também podem interferir. Se um antigo registro SPF TXT permanecer ao lado do novo, ou se um CNAME DKIM obsoleto ainda apontar para um serviço aposentado, a validação pode falhar de maneiras que parecem aleatórias. Remova a entrada morta somente após confirmar que não é mais necessária. Isso mantém o remetente ativo intacto.

Se você também está trabalhando na configuração de autenticação de email para email transacional, este é o momento de verificar cada host de envio listado pelo fornecedor. Um subdomínio esquecido pode fazer com que uma mensagem de suporte passe enquanto uma mensagem de recibo falha, e esse comportamento dividido é difícil de identificar até que um cliente reclame.

7. Verifique a propagação e a autenticação de email a partir do DNS gerenciado pelo Cloudflare

Após salvar os registros, aguarde a propagação do DNS. O tempo exato depende do seu TTL e do cache do resolvedor à sua frente, então não assuma que o registro está visível em todos os lugares no momento em que o Cloudflare diz que foi salvo. Verifique externamente com uma ferramenta de consulta DNS e confirme se cada nome de registro retorna o valor esperado.

Então, envie uma mensagem de teste real do serviço que usa os registros. Não teste de uma caixa de entrada aleatória que contorna seu fluxo normal de email. Abra os cabeçalhos da mensagem na caixa de entrada receptora e procure por SPF pass, DKIM pass e DMARC alignment pass. A mensagem ainda pode cair na pasta de spam por outros motivos, mas o resultado da autenticação deve lhe dizer se o lado do DNS está correto.

Uma verificação rápida é suficiente para a primeira passagem, mas uma segunda verificação de uma caixa de correio diferente lhe dá um sinal melhor. Um teste no Gmail e um teste no Microsoft 365 podem se comportar de maneira diferente se um resolvedor vê o registro antigo brevemente enquanto outro vê o novo. Isso não é raro. Acontece.

Se a entregabilidade faz parte do mesmo projeto, combine este trabalho com as melhores práticas de entregabilidade de email. A autenticação não é toda a história, mas é a parte que permite que os receptores decidam se seu domínio está falando por si mesmo.

8. Atualize os registros quando seu provedor de email mudar

As configurações de email mudam. Um provedor rotaciona chaves DKIM, uma plataforma de marketing é adicionada ou um serviço de transação é movido após uma migração. Quando isso acontece, atualize os registros DNS no Cloudflare antes de mudar o tráfego, não depois. Essa ordem evita que você tenha um dia de assinaturas quebradas.

A rotação de DKIM é geralmente a mudança mais limpa. O provedor lhe dá um novo seletor e chave, você publica isso no Cloudflare e aguarda até que o novo seletor valide antes de aposentar o antigo. Mantenha ambos ativos durante a transição se o provedor suportar. Dois seletores são mais fáceis do que uma interrupção.

As mudanças de SPF são um pouco mais delicadas porque o registro deve permanecer dentro dos limites de tamanho e consulta TXT do DNS estabelecidos pelo padrão SPF. Se um novo remetente se juntar à pilha, adicione seu mecanismo de inclusão ao registro SPF existente em vez de empilhar outro registro ao lado. Se você estiver próximo do limite de consulta, reduza inclusões desnecessárias onde possível e confirme a orientação atual do provedor.

Para equipes que enviam através de vários serviços, a manutenção fica mais fácil se uma pessoa for responsável pela lista de remetentes autorizados. Essa lista deve nomear o serviço, o nome do host, o seletor DKIM e a data da última alteração. Uma tabela simples mantém as edições do Cloudflare consistentes, e a consistência é mais importante do que a esperteza.

Se o gerenciamento de retornos e as mudanças de remetente fazem parte do mesmo projeto de caixa de entrada, a mesma disciplina ajuda com as melhores práticas de gerenciamento de retornos de email. Uma migração de provedor pode alterar tanto a autenticação quanto o comportamento de erro no mesmo dia, e nenhum dos lados deve ser adivinhado.

A Cloudflare torna a parte de publicação simples, mas os registros ainda precisam de disciplina. Um remetente. Um registro SPF. Cada seletor DKIM no lugar certo. Um registro DMARC em `_dmarc`. Se você mantiver esses quatro pontos em ordem, o resto é principalmente paciência, algumas verificações de cabeçalho e a disposição de atualizar o DNS antes que a próxima mudança de plataforma chegue.