Configuração DKIM SPF DMARC para um Domínio

Configuração DKIM SPF DMARC para um domínio: um guia completo para autenticação de e-mail

O e-mail ainda é uma das partes mais vulneráveis de qualquer domínio, e um site pode ser bem construído e o servidor bem protegido. Se as mensagens enviadas em nome da empresa são fáceis de falsificar, os problemas começam rapidamente: campanhas de phishing, reclamações de usuários, perda de confiança e, no pior dos casos, pior entregabilidade para seus próprios e-mails. É por isso que Configuração DKIM SPF DMARC para domínionão é um “pequeno detalhe técnico” — é higiene básica da infraestrutura de e-mail e uma parte importante da autenticação de e-mail.

Se você já teve e-mails que foram parar no spam sem razão aparente, ou um cliente perguntar: “Você realmente enviou isso?” — já é hora de trabalhar na autenticação de domínio. E quanto mais cedo, melhor. Nesse sentido, o e-mail funciona muito como um site: sem atenção regular, até mesmo um sistema sólido começa a se comportar de maneira imprevisível. Muitas vezes falamos sobre isso no contexto de segurança do site: a proteção não é um plugin ou uma configuração, mas um conjunto de medidas que funcionam juntas. Se você está se perguntando como configurar SPF DKIM DMARC, a chave é tratá-los como um processo coordenado em vez de correções separadas.

O que são DKIM, SPF e DMARC e por que eles são importantes

DKIM, SPF e DMARC resolvem um problema semelhante, mas o fazem de maneiras diferentes. É importante não confundir seus papéis se você está planejando configuração de autenticação de e-mail para domínio.

SPF responde à pergunta: “Quais servidores estão realmente autorizados a enviar e-mails em nome deste domínio?” No DNS, você publica uma lista de remetentes aprovados, e o servidor de e-mail do destinatário a compara com o endereço IP real de onde a mensagem veio.

DKIM adiciona uma assinatura criptográfica à mensagem. O destinatário verifica se o e-mail foi realmente assinado pelo seu domínio e se foi alterado ao longo do caminho. Isso é mais do que apenas uma lista de permissões — é uma prova da identidade do remetente e da integridade da mensagem.

DMARC une SPF e DKIM em uma única política e informa aos sistemas de e-mail o que fazer se uma mensagem falhar nas verificações: entregá-la, enviá-la para quarentena ou rejeitá-la completamente. O DMARC também permite que você receba relatórios sobre quem está tentando enviar e-mails do seu domínio e como.

É por isso que esses mecanismos não se tratam apenas de prevenir e-mails falsificados. Eles afetam diretamente a entregabilidade. Os serviços de e-mail olham cada vez mais não apenas para o conteúdo de uma mensagem, mas para quão bem sua autenticação está configurada. Para um domínio comercial, isso é crítico: perder algumas mensagens é uma coisa, mas acabar repetidamente no spam para clientes, parceiros e serviços é algo completamente diferente.

Como DKIM, SPF e DMARC trabalham juntos

Cada protocolo é útil por si só, mas juntos criam um sistema de verificação muito mais confiável.

O SPF confirma que a mensagem veio de um servidor aprovado. Mas tem uma limitação: se o e-mail for encaminhado, o SPF pode “quebrar” porque o endereço IP do último remetente muda. O DKIM muitas vezes ajuda nesses casos porque a assinatura permanece válida mesmo após o encaminhamento, desde que a mensagem em si não tenha sido modificada.

O DMARC, por sua vez, verifica não apenas se SPF e DKIM existem, mas se estão alinhados com o domínio no campo From. Isso é importante. Uma mensagem pode estar tecnicamente assinada, mas o usuário vê um domínio completamente diferente no nome do remetente, e o DMARC ajuda a evitar essa confusão e bloqueia a falsificação óbvia.

Para simplificar: SPF é uma lista de convidados na entrada, DKIM é um selo no documento, e DMARC é a regra de segurança sobre o que fazer com visitantes que não têm nem um passe nem um selo. Uma medida sem as outras deixa uma lacuna.

É por isso que devem ser implementados juntos. Isso é especialmente importante para empresas que usam várias fontes de e-mail: sistemas de CRM, serviços de newsletter, plataformas de bilhetagem, formulários de contato, notificações transacionais. Se esses não estiverem alinhados, a infraestrutura de e-mail começa a se comportar como uma coleção de ilhas desconectadas.

Preparando para a configuração: domínio, DNS e serviço de e-mail

Antes de criar qualquer registro, você precisa entender quem exatamente envia e-mails em nome do domínio. Pode ser um serviço de e-mail, ou vários: e-mail corporativo, uma plataforma de envio, um sistema de notificações, um serviço SMTP separado para o site. Sem essa visão, você corre o risco de permitir demais ou, pelo contrário, bloquear acidentalmente um remetente necessário.

Você precisará de acesso ao painel DNS do domínio. Normalmente, essa é a interface do registrador, do seu provedor de hospedagem ou de um provedor de DNS separado. É importante saber exatamente onde os registros são editados: às vezes, uma pessoa procura o problema no serviço de e-mail, enquanto o registro na verdade está com outro provedor.

Outro passo essencial é coletar detalhes do provedor de e-mail. Normalmente, você precisará:

• dados SPF ou um registro SPF recomendado;
• uma chave DKIM ou instruções para gerar uma;
• o nome do seletor DKIM, se o provedor usar um;
• recomendações DMARC;
• uma lista de domínios e subdomínios usados para envio;
• uma compreensão de quais serviços enviam e-mails agora e quais serão adicionados depois.

Se você não estiver trabalhando com um novo domínio, é uma boa ideia revisar a configuração atual primeiro. Às vezes, o SPF já existe, mas ainda lista serviços antigos. Às vezes, o DKIM foi ativado em algum momento, mas o sistema de envio depois mudou para outro provedor. E às vezes, o DMARC está lá, mas apenas 'para mostrar', sem relatórios e sem uma política significativa, e é melhor pegar essas coisas antes de fazer alterações, não depois de reclamações de usuários.

Configurando SPF para o domínio

Um registro SPF é publicado no DNS como um registro TXT. Sua função é listar as fontes de envio aprovadas. A ideia básica é simples: você especifica quais serviços e servidores estão autorizados a enviar e-mails em nome do domínio, e tudo o mais é tratado como não autorizado.

Ao configurá-lo, lembre-se disto: um domínio deve ter um registro SPF. Não dois, não três — um. Se você adicionar vários registros TXT com SPF, muitos destinatários tratarão isso como um erro. Este é um dos problemas mais comuns no suporte à infraestrutura de e-mail, e configuração de autenticação de e-mail para domínio é especialmente sensível a detalhes aqui.

A lógica típica do SPF é construída em torno de mecanismos como include, ip4, ip6 e mx. Na prática, isso significa que você pode incluir um serviço de envio de terceiros, endereços IP específicos ou os servidores de e-mail do domínio. Mas há um porém: cada entrada adicional torna o registro mais longo e mais complexo.

Outro erro comum é ser muito amplo. Às vezes, as pessoas usam regras excessivamente permissivas apenas para 'evitar quebrar algo'. Como resultado, mais remetentes são permitidos do que o necessário. Isso é conveniente no início, mas pior para a segurança, e se proteger contra mensagens forjadas é importante para você, o SPF deve ser preciso, não apenas 'aproximadamente certo.'

Após publicar o registro, verifique se ele está realmente visível no DNS e corresponde às suas fontes de envio atuais. Se você enviar e-mails através de várias plataformas, verifique cada uma delas. Caso contrário, você pode facilmente acabar em uma situação onde os e-mails do CRM passam, mas as notificações do site não.

Configurando DKIM: gerando uma chave e publicando o registro DNS

DKIM funciona com um par de chaves: a chave privada fica com o remetente, e a chave pública é publicada no DNS, e quando uma mensagem é enviada, o servidor a assina com a chave privada. O destinatário pega a chave pública do DNS e verifica a assinatura. Se tudo corresponder, a mensagem é considerada autêntica.

DKIM geralmente é configurado através do serviço de e-mail. No painel do provedor, você seleciona o domínio, gera uma chave ou recebe configurações prontas, e então publica um registro TXT com a parte pública da chave. Um seletor é frequentemente incluído no registro — um nome especial que ajuda a distinguir uma chave da outra. Isso é especialmente útil se o domínio tiver vários sistemas de envio ou se você planeja rotacionar chaves.

Após publicar o registro DNS, você precisa habilitar a assinatura para mensagens de saída no próprio serviço, e sem isso, o registro DNS é inútil: a chave ficará na zona, mas os e-mails permanecerão não assinados. Do ponto de vista de solução de problemas, essa é uma armadilha comum: “O registro foi adicionado, mas o DKIM não funciona.” Na realidade, a assinatura simplesmente não foi habilitada do lado do remetente, então o configuração de autenticação de e-mail para domínio permanece incompleto.

Tecnicamente, é importante verificar:

• se o seletor corresponde entre o DNS e as configurações do serviço;
• se o registro TXT foi publicado corretamente;
• se a chave foi acidentalmente cortada ao ser colada;
• se todos os tipos de mensagens necessárias estão assinados, não apenas alguns deles;
• se a mensagem muda após a assinatura, por exemplo, devido a processamento extra por um serviço intermediário.

DKIM é especialmente útil para e-mails transacionais: confirmações de registro, redefinições de senha, notificações de pedidos. Essas mensagens precisam chegar de forma consistente. Se o site tiver uma estrutura bem organizada e um suporte sólido pós-lançamento, como suporte ao site após o lançamento, a autenticação de e-mail geralmente é uma das coisas que não é adiada “para depois.” E essa é a abordagem certa.

Configurando a política e relatórios DMARC

DMARC adiciona controle. Sem ele, você pode ver SPF e DKIM separadamente, mas não tem uma regra clara sobre o que fazer com mensagens suspeitas. Um registro DMARC também é publicado no DNS como um registro TXT, geralmente sob o subdomínio _dmarc.

No início, muitas pessoas escolhem uma política none. Este é um modo de monitoramento: as mensagens não são bloqueadas, mas o proprietário do domínio recebe relatórios e pode ver quem está enviando e-mails, se as verificações estão passando e onde estão as lacunas. É um primeiro passo sensato, especialmente se a infraestrutura for complexa e você não quiser cortar repentinamente mensagens legítimas.

Após um período de monitoramento, a política pode ser endurecida: a quarentena envia mensagens suspeitas para spam ou quarentena, enquanto a rejeição as bloqueia completamente. Qual opção escolher depende de quão madura é a sua configuração de e-mail e de quão confiante você está de que todas as fontes legítimas já estão contabilizadas.

Nos relatórios DMARC, é útil olhar não apenas para erros, mas também para fontes de envio inesperadas, e às vezes serviços antigos, plataformas de teste ou integrações esquecidas aparecem lá. Essa é uma boa oportunidade para limpar as coisas.

Se você está implementando DMARC para um domínio corporativo, vale a pena verificar se processos importantes dependem de serviços de terceiros. Por exemplo, se o site usa ativamente formulários e notificações por e-mail, e a estrutura do site é construída de uma maneira que as mensagens passam por vários módulos, ajuda alinhar cada ponto de envio com antecedência. Também cobrimos questões relacionadas no tópico de estrutura de site corporativo: quanto mais clara a arquitetura, menos surpresas no nível do e-mail e mais suave a configuração da autenticação de e-mail.

Verificação e solução de problemas após a implementação

Após a configuração, não confie na sensação de que "parece funcionar". A verificação deve ser deliberada e metódica.

Primeiro, certifique-se de que o registro SPF está visível no DNS e contém apenas fontes atuais. Em seguida, envie uma mensagem de teste e verifique os cabeçalhos do lado do destinatário: eles geralmente mostram se o SPF passou, se há uma assinatura DKIM e se o DMARC foi acionado.

Se a mensagem falhar na verificação, procure a causa passo a passo:

1. os registros DNS estão inseridos corretamente;
2. tempo suficiente passou para a propagação do DNS;
3. o domínio no campo De corresponde ao domínio de assinatura;
4. a mensagem está sendo assinada pelo serviço que você espera;
5. um sistema intermediário está modificando a mensagem após a assinatura.

É muito útil testar não apenas uma mensagem, mas vários cenários: um formulário no site, um e-mail de CRM, uma notificação de registro, um boletim enviado por meio de um serviço de marketing por e-mail. Às vezes, o problema aparece em apenas um canal enquanto os outros parecem perfeitos.

Também vale a pena verificar como os registros DNS estão sendo interpretados. Os erros podem ser triviais: um espaço extra, a citação errada, um seletor incorreto, múltiplos registros SPF em vez de um. Pequenos detalhes como esses podem arruinar o resultado, mesmo quando tudo parece correto à primeira vista.

Perguntas comuns e recomendações para manter a configuração saudável

O que você deve fazer se seu serviço de e-mail mudar? Primeiro, adicione o novo remetente ao SPF, configure o DKIM com o novo provedor, teste o envio e só então desative o antigo, e você não pode simplesmente "trocar" de serviços e esperar que os registros antigos deixem de importar por conta própria. A infraestrutura de e-mail gosta de precisão, e configuração de autenticação de e-mail para domínio requer uma sequência.

E se várias mensagens forem enviadas, e algumas vierem do site enquanto outras vierem de uma plataforma externa? Então é importante fazer uma lista completa de todos os remetentes. Para um site, isso pode incluir um plugin SMTP, um sistema de notificações, um serviço de mala direta e até mesmo uma ferramenta de formulário de contato separada. Quanto mais clara a lista, mais fácil é manter o SPF e o DMARC sem conflitos.

As configurações precisam de verificações regulares? Sim. Especialmente se você mudou de hospedagem, transferiu o domínio, conectou um novo CRM ou atualizou seu sistema de mala direta. Às vezes, os registros DNS permanecem desatualizados simplesmente porque ninguém se lembra mais deles. E registros esquecidos são frequentemente uma fonte oculta de erros.

Se você não tem certeza de que sua configuração atual de envio de e-mail é transparente, faz sentido analisá-la como um todo: quem envia, quem assina, onde os registros estão armazenados e quem é responsável pelas mudanças. Em projetos mais complexos, isso se torna parte do suporte geral e da arquitetura técnica, não uma "tarefa de TI" de cinco minutos.

E mais uma dica prática: não se apresse em habilitar uma política de rejeição rigorosa se o domínio for antigo e tiver muitos remetentes não relacionados. Primeiro colete os dados, ative a geração de relatórios, remova o que for desnecessário e só então aperte gradualmente a política, pois na autenticação de e-mails, apressar-se quase sempre leva ao bloqueio do e-mail que você realmente precisa.

Se você deseja um domínio que não apenas pareça bom na barra de endereços, mas também passe nas verificações de e-mail com confiança, SPF, DKIM e DMARC devem ser tratados como uma parte obrigatória do projeto. Isso não é uma medida decorativa — é uma forma de proteger sua marca, construir confiança e tornar a entrega de e-mails previsível. E a previsibilidade, como a prática mostra, vale mais do que qualquer configuração chamativa, mas frágil.